SEND Message #xxx from Imzadi Box to xxx@xxx.xxx - in transit
Hi,
I've moved my Synchronet installation of my BBS (Imzadi Box) from a i5-based Lenovo m92p Tiny to an old IGEL ThinClient, which uses a "VIA Nano U3100" CPU.
Basically everything is working (as expected, as it is Linux), I copied the system + sbbs over and reapplied GRUB to make the SSD bootable again (I changed the partition scheme and the GRUB implementation as the IGEL does not use UEFI).
The only problem I'm facing right now is that Synchronet cannot deliver Internet E-Mails via SMTP.
It is posting this message to my syslog:
Apr 27 11:26:39 box kernel: [159793.588139] traps: sbbs/sendMail[13754] trap invalid opcode ip:7faa23f5a9be sp:7faa0bff85a0 error:0 in libsbbs.so[7faa23af0000+50d000]
This now happens every time sbbs is started, so I cannot bring up my BBS at the moment.
I tried to re-compile SBBS (3.18b) by running "cleanall.sh" in /sbbs/repo/src and running
make RELEASE=1 SYMLINK=1 SBBSUSER=bbs SBBSGRUP=bbs SBBSDIR=/sbbs USE_DOSEMU=1 TAG=sbbs318b
in the directory with the GNUmakefile.
The files seem to be recompiled and as the symlinks are still in place, should also be found again.
But the error persists...
Do you have any idea?
Double check that your version information (logged and displayed from "System Information" menu in the terminal server) says that it was recompiled today.
It does sound like the binaries are possibly being built for the wrong platform, so if a cleanall.sh doesn't do it, I then try a fresh clone and build of the repo (into a new directory) - just to be sure.
Hallo dm,
Double check that your version information (logged and displayed from "System Information" menu in the terminal server) says that it was recompiled today.
It says so:
Synchronet BBS for Linux Version 3.18
Revision B Apr 27 2021 11:15 SMBLIB 2.61 GCC 8.3.0
Copyright 2020 Rob Swindell - http://www.synchro.net
JavaScript-C 1.8.5 2011-03-31
Linux 4.19.0-16-amd64 x86_64
It does sound like the binaries are possibly being built for the wrong platform, so if a cleanall.sh doesn't do it, I then try a fresh clone and build of the repo (into a new directory) - just to be sure.
Okay, I'll try that tomorrow.
Do you have a tip on how to merge the "new" and the "old" repo directories into a working SBBS installation?
Apr 27 11:26:39 box kernel: [159793.588139] traps: sbbs/sendMail[13754] trap invalid opcode ip:7faa23f5a9be sp:7faa0bff85a0 error:0 in libsbbs.so[7faa23af0000+50d000]
You can clone the repo anywhere you like. It doesn't *have* to be /sbbs/repo. But if you don't have any changes in your repo, you could simply rename the "repo" dir to "oldrepo" and then clone again using the steps here: https://wiki.synchro.net/howto:git#clone
But that'll upgrade you to v3.19a. Not sure if you're ready/wanting to do that yet.
Your welcome to try my docker image, I've been using SBBS under docker for over 12 months now and it makes for an easy update.
Hi dm,
You can clone the repo anywhere you like. It doesn't *have* to be /sbbs/repo. But if you don't have any changes in your repo, you could simply rename the "repo" dir to "oldrepo" and then clone again using the steps here: https://wiki.synchro.net/howto:git#clone
But that'll upgrade you to v3.19a. Not sure if you're ready/wanting to do that yet.
I cloned the repo according to the commands in the main GNUmakefile and switched to the 318b tag.
I just made the mistake to use "make install RELEASE=1 SYMLINK=1 SBBSUSER=bbs SBBSGRUP=bbs SBBSDIR=/sbbs USE_DOSEMU=1 TAG=sbbs318b" afterwards, which indeed recompiled everything but overwrote eg. the ctrl directory with the default settings files.
But thank you for your help, it is now working again!!
I guess that the problem with "cleanall.sh" is the following:
It is only deleting the resulting binary files, but leaves the cache files etc. that "configure" created in place!
This way, all the "findings" that configure ...well... "found" ... are still there and so maybe some CFLAGS etc. are not reconfigured.
Maybe the deletion of "configure" created files could be added to the "make clean" targets?
... and the old school way of breaking things :)
Sounds like you used the install/GNUmakefile. I did not suggest you do that. The "main GNUmakefile" is src/sbbs3/GNUmakefile and it won't overwrite anything in your ctrl directory.
Yeah, that can be done. It's the 3rd party libs (e.g. libmozjs) that use configure, not sbbs.
Hi dm,
Sounds like you used the install/GNUmakefile. I did not suggest you do that. The "main GNUmakefile" is src/sbbs3/GNUmakefile and it won't overwrite anything in your ctrl directory.
Oh, okay. Good to know for the future.
The problem is, that -for me!- the question which Makefile to use is not that obvious...
The next question for me is then:
When I update to the current "master git version", how would I build and "install" this new version without problems in the other directories?
Thank you!
Yeah, that can be done. It's the 3rd party libs (e.g. libmozjs) that use configure, not sbbs.
Then, are some compiler settings created by the make process and stored in the sbbs3 directory which aren't cleaned by cleanall.sh?
Hi,
Then, are some compiler settings created by the make process and stored in the sbbs3No. But they could be in the 3rdp directory.
directory which aren't cleaned by cleanall.sh?
But then the question remains:
What was the difference between the "simple" re-compiling after using cleanall.sh and the re-compiling from a fresh git checkout.
Is libsbbs.so using 3rd party parts where cleanall.sh is not really cleaning things?
Do you consider changing cleanall.sh?
| Sysop: | Coz |
|---|---|
| Location: | Anoka, MN |
| Users: | 2 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 06:15:54 |
| Calls: | 97 |
| Files: | 4,620 |
| Messages: | 216,803 |