It is responsible for loading the module for use by the installed programs. Looks like there is some bug in the Devuan then if it installs and works fine in the MX. Both do not use the systemd garbage so have that in common but apparently not enough for the same package to work on both OSs.

Edit: Now there is thought now I think of it, does the package from Devuan install without errors on the MX or the other way around will the MX install on the Devuan. If they both use the same libraries/dependencies  they should be interchangeable.

Try the sudo rm /etc/init.d/fnfxd to remove the test for it being positive and allowing the removal without the update-rc.d being called to try and stop it. That package is junk there is no way it should fail trying to set the run level like it is doing here.

Does not show up here but I am running 64bit system and it is 32bit plus one version on the testing or excalibur the new stable to come in few months. The apt remove fnfxd or dpkg -r /var/cache/apt/archives/fnfxd_0.3-18_i386.deb should remove it. Using of course the sudo command in front to get root permissions if you do not have root user setup. Yes the init area is it looking carefully at the scripts that are run in the post install as this is where they likely fail. You can extract the file and start looking at them to see if you can find the spot where it fails.

Let it remove it make certain the toshiba_acpi is loaded then try again. If it does the same thing the package is broken and will not install on a system more than 9 years after the last update of it.

The apt-file is never installed by default but is a wonderful little tool for finding the package containing the file needed. When using modprobe the only time it produces output is when the module is not there to load. You use the lsmod command to see if it loaded, rmmod will remove loaded module.

root@9600k:~# lsmod |grep toshiba_acpi
root@9600k:~# modprobe toshiba_acp
modprobe: FATAL: Module toshiba_acp not found in directory /lib/modules/6.12.8-amd64
root@9600k:~# modprobe toshiba_acpi
root@9600k:~# lsmod |grep toshiba_acpi
toshiba_acpi           73728  0
sparse_keymap          12288  1 toshiba_acpi
battery                28672  1 toshiba_acpi
industrialio          139264  1 toshiba_acpi
rfkill                 40960  6 toshiba_acpi,bluetooth
video                  81920  2 toshiba_acpi,i915
wmi                    28672  4 video,toshiba_acpi,gigabyte_wmi,wmi_bmof
root@9600k:~# rmmod toshiba_acpi
root@9600k:~# lsmod |grep toshiba_acpi

Have you tried the install again with the module loaded?

Edit: while I think of it an article on making sure the module loads on boot.

https://www.cyberciti.biz/faq/linux-how … boot-time/

The CONFIG_ACPI_TOSHIBA=m should be the one. The m means that it is module, the y it is built into the kernel no need to load it with modprobe, n means no not built at all. Use modprobe toshiba_acpi it appears to be named as.

root@9600k:~# locate toshiba
/usr/lib/modules/6.12.8-amd64/kernel/drivers/platform/x86/toshiba-wmi.ko.xz
/usr/lib/modules/6.12.8-amd64/kernel/drivers/platform/x86/toshiba_acpi.ko.xz
/usr/lib/modules/6.12.8-amd64/kernel/drivers/platform/x86/toshiba_bluetooth.ko.xz
/usr/lib/modules/6.12.8-amd64/kernel/drivers/platform/x86/toshiba_haps.ko.xz

Yes they truly have gone downhill in that regards, though it is not the first time they have dropped an arch. With mostly the same reaction seen here every time as it happens. Same with the systemd garbage they foist onto their users forgetting the one tool for every action keep it simple *nix philosophy. While it expands ever more into every god damn part of the system with each release. So the Microsoft plants in Linux can slowly gain more control over ever f'n thing done on those systems. They don't even hide the agenda anymore and Debian still goes along with it. Here in a couple of days it will be four months (according to the Ubuntu changelog for the fix) since they ship a broken KDE that will not connect to a samba share at all. Despite the fix being in Ubuntu for all of those months and all it is, is a simple re-compile of the Ubuntu packages to fix it as they are binary compatible now that will install and work on a Debian based system. Having seen it in the past I have no doubt that they will ship those packages in that same broken state with Trixie when it goes out the door..

Ah I was wondering if you had done the copy the iso to the install drive many do and you did not. That is same error I got when trying to use the installer. Save yourself the wasted time and effort use an installer that works a Debian one. Then convert the install to Devuan using the instructions they give for doing it that work perfectly fine when starting with that as a base to get it on the box. There are very few changes made from a stock Debian to this operating system. The main one being removing the systemd infestation from it and installing sysvinit.

You would download the both and compare the files. All that matters is the system thought there was a change and displayed  the normal message for that change. You see it every time the . release updates go from the 12.7 to 12.8 for instance you get to see it. Now I scroll back the old version last update was in July of 2023 definitely a few version . changes in that period of time thus the reason for the message being displayed.

It is only or should only be displayed when the base-files package is updated and the information in the os-release file changes.

root@9600k:~# cat /etc/os-release 
PRETTY_NAME="Devuan GNU/Linux 6 (excalibur/ceres)"
NAME="Devuan GNU/Linux"
VERSION_ID="6"
VERSION="6 (excalibur/ceres)"
VERSION_CODENAME="excalibur ceres"
ID=devuan
ID_LIKE=debian
HOME_URL="https://www.devuan.org/"
SUPPORT_URL="https://devuan.org/os/community"
BUG_REPORT_URL="https://bugs.devuan.org/"
root@9600k:~# apt-file search /etc/os-release
base-files: /etc/os-release  
snip....

Check in your /var/log/apt/history.log to see if it (base-files) has been updated recently to tell if it should have displayed.

obviously never used a phone modem to connect to the internet. Those strange noises are the handshake as it is called when the machines negotiate the connection. A common sound heard in the old days before ethernet became the connection of choice and you had no choice but to use the telephone modem to connect. And got to connect at a whopping speed of ~4k/s for the fastest of them modems. See if one of them services have a test number to send to and of course get them to send another to confirm you can receive. If receiving then you can send.

I highly doubt that fax directory is in the path so will never be found.

zeus@9600k:~$ echo $PATH
/sbin:/home/zeus/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
root@9600k:~# echo $PATH
/root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Try.

ln -s /opt/epson/epson-pc-fax2 /usr/local/bin/epson-pc-fax2

To link it to a directory that should be in the path.  I think I have the link command correct, I have to look it up most times, if not try it the other way round.

Edit: can you link to the download page you got the file from so I can look at it, I do not seem to be able to find it.