You are not logged in.
Yes, I don't understand why something solid, fundamental, stable, that has been used for years, suddenly needs to be changed.
@Altoid:
Why do you think you need to run Excalibur on your 32-bit machine?
Actually for testing purposes and because my parents use it. But also so that the kernel and packages are up to date and receive the latest security updates.
@Altoid:
Maybe the gods are telling you something?
Yes, probably. ;-)
@Altoid:
Do think about keeping Daedalus running in your rig, maybe with a backported kernel (ask here before) if you can be sure it will help you in any way.
Like I said: with a grain of salt.
Well, I never really thought about a backported kernel and didn't really know what you could do with it. But this tip isn't so bad. I read a little about it online and it doesn't seem that difficult. What about security updates?
The main computer I use is 64-bit. What is the best thing to do in this situation? Should I also rely on backported kernels or look for another Linux system, or will I unfortunately have to accept usrmerge at some point in the future?
@fsmithred:
It still says you're missing non-free firmware. Do you know which firmware package you need? If you're going to use a devuan kernel, you can install the non-free stuff. If you use the libre kernel, you can't use the non-free stuff.
If the system doesn't work without the non-free stuff then you can't use the libre kernel.
If the system does work without the non-free stuff, you can ignore the warnings.
If I stay under Daedalus and allow all non-free firmware, then no errors occur.
The system actually works quite well, despite the errors displayed.
@Altoid:
Excalibur is a usrmerge'd installation, no way around that.
But if Daedalus is no longer supported, we'll all have to bite the bullet and switch to systems with usrmerge, right? Or are there still alternatives?
The Sources.list is set to Daedalus.
Kernel is: 6.1.0-41-686
The error messages looked like this:
INIT: version 3.06 booting
INIT: No inittab.d directory found
Using makefile-style concurrent boot in runlevel S.
Starting hot-plug envents dispatcher: udevd.
Synthesizing the initial hotplug events (subsystem)...done.
Synthesizing the initial hotplug events (devices)...done.
Waiting for /dev to be fully populated...[ 14.954343] radeon: firmware: failed to load radeon/R520_cp.bin (-2)
[ 14.954357] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
[ 14.954300] radeon firmware: failed to load radeon/R520_cp.bin (-2)
[ 14.954396] [drm:r100_cp_init.cold [radeon]] *ERROR* Failed to load firmware!
[ 14.954557] radeon: failed initializing CP (-2)
[ 14.954564] radeon: Disabling GPU acceleration
done.I have now installed the Linux-libre kernel. I am still using Daedalus in Sources.list.
The kernel is: 6.12.58-gnu.
Now the error messages look like this:
INIT: version 3.06 booting
INIT: No inittab.d directory found
Using makefile-style concurrent boot in runlevel S.
Starting hot-plug envents dispatcher: udevd.
Synthesizing the initial hotplug events (subsystem)...done.
Synthesizing the initial hotplug events (devices)...done.
Waiting for /dev to be fully populated...[ 12.726339] Error: Driver ´pcspkr´ is already registered, aborting...
[ 12.741657] Missing Free firmware (non-Free firmware loading is disabled)
[ 12.741741] radeon_cp: Failed to load firmware "/*(DEBLOBBED)*/"
[ 12.741748] [drm:r100_cp_init] [radeon]] *ERROR* Failed to load firmware!
[ 12.741883] radeon: failed initializing CP (-2).
[ 12.741891] radeon: Disabling GPU acceleration
done.@Altoid:
Yes, I understand. I agree with you that usrmerge is just another step toward undermining the Linux system. First SystemD, then usrmerge, and then something else that will completely destroy Linux. I also read online that they introduced it so that SystemD would have even more control. It also destabilizes the system.
Unfortunately, the big companies dictate the standard, and other Linux systems adopt it and make it their standard, which is really sad. But who can resist these changes for long? Sooner or later, everyone will adopt these standards. What will we do then? Are there any alternative systems left that don't use usrmerge? There were more opponents of SystemD, but with usrmerge, everyone agrees. That's strange.
@greenjeans
My laptop is an older AMD, and it will indeed run almost fine with free firmware as will most i've tried in Daedalus, but there are some small boot errors like yours and my machine will not suspend properly without the firmware-amd-graphics package.
In Excalibur in tests so far on my old lappy, it has worse errors if I don't have that firmware package as I couldn't get past lightdm without it.
But Excalibur is only available for 64-bit computers. Which kernel did you use on your old AMD laptop? Or did you manage to get Excalibur to run on 32-bit as well?
@fsmithred
Does the Linux-libre kernel require usrmerge? Do you know anything about this?
And: If I stick with Daedalus and install Linux-libre, and then try to upgrade to Excalibur without usrmerge, will it work?
Why is everyone suddenly switching to usrmerge? It reminds me of SystemD. Someone makes it the default and everyone jumps on the bandwagon.
So, I've now deleted everything and reinstalled Daedalus. No non-free firmware was installed during the installation. All xserver-xorg drivers were installed automatically. Free firmware was also automatically selected.
I'm using Openbox as my desktop environment. The GDBus error is gone. The ALSA error is also gone. But it keeps asking for non-free firmware for the graphics card.
The kernel is Daedalus 6.1.0-40. But everything is actually running smoothly. If I switch to the Linux Libre kernel, the errors will probably be the same. I might do that later today.
These are the errors it's showing me now during the boot process:
INIT: version 3.06 booting
INIT: No inittab.d directory found
Using makefile-style concurrent boot in runlevel S.
Starting hot-plug envents dispatcher: udevd.
Synthesizing the initial hotplug events (subsystem)...done.
Synthesizing the initial hotplug events (devices)...done.
Waiting for /dev to be fully populated...[ 14.954343] radeon: firmware: failed to load radeon/R520_cp.bin (-2)
[ 14.954357] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
[ 14.954300] radeon firmware: failed to load radeon/R520_cp.bin (-2)
[ 14.954396] [drm:r100_cp_init.cold [radeon]] *ERROR* Failed to load firmware!
[ 14.954557] radeon: failed initializing CP (-2)
[ 14.954564] radeon: Disabling GPU acceleration
done.
.
.
.And further down at the bottom there is this message:
Setting up ALSA...warning: ´alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore´ failed with error message ´alsa-lib main.c
or: failed to import hw:29 use case configuration -2´...
done.It's strange, though, that the drivers for this graphics card are found in the proprietary firmware. I always thought Radeon was more open source than NVIDIA.
I've tried many things. I set the sources.list to "main". I completely removed all the firmware, including the xserver-xorg-video drivers. I also uninstalled udev, eudev, and lightdm. Afterward, I installed udev, eudev,..., and the xorg drivers again.
I went to GitHub and replaced the contents of the file /usr/lib/udev/rules.d/90-alsa-restore.rules.
I thought Radeon graphics cards were open source. But I can't fix the graphics card error. It always displays the error during boot and asks for non-free firmware.
During the boot process, alsa-restore displays the following:
/value pair in file /usr/lib/udev/rules.d/90-alsa-restore.rules on line 3, starting at character 73 (´,´)I examined the line described at: https://dev1galaxy.org/viewtopic.php?pid=58587#p58587. I replaced the "c" with a "p". No success.
But the alsa-restore error doesn't really bother me, since the sound works. Even if I delete the contents of the file /usr/lib/udev/rules.d/90-alsa-restore.rules, the sound still works and no message appears during the boot process.
The GDBus error is still there. I thought it would disappear if I used startx. But it's still there.
Despite all the errors, everything actually works quite well. The graphics resolution is the same as with Daedalus. The sound works. But it's still annoying to see the errors and constantly to click away the GDBus error on the start screen.
@fsmithred:
So, unfortunately, I removed the Daedalus kernel. That's why I can't test it anymore.
I'm now using the other kernel from Linux-libre. The non-LTS version: 6.17.7-gnu
Nevertheless, the errors during the boot process are the same.
Starting hot-plug events dispatcher: udevd[ 10.468515] udevd[350]: invalid key /value pair in file /usr/lib/udev/rules.d/90-alsa-restore.rules on line 3, starting at character 73 (´,´)
.
Synthesizing the initial hotplug events (subsystem)...done.
Synthesizing the initial hotplug events (devices)...done.
Waiting for /dev to be fully populated...[ 13.205434] Error: Driver ´pcspkr´ is already registered, aborting...
[ 13.592463] udevd[353]: Unknown key identifier ´zoon´
[ 13.942533] Missing Free firmware (non-Free firmware loading is disabled)
[ 13.942632] radeon_cp: Failed to load firmware "/*(DEBLOBBED)*/"
[ 13.942639] [drm:r100_cp_init] [radeon] *Error* Failed to load firmware!
[ 13.942778] radeon: failed initializing CP (-2)
[ 13.942787] radeon: Disabling GPU acceleration
done.Well. I'll reinstall the system soon, when I have enough time, and then see if the errors reappear.
@fsmithred
I followed your instructions and then the directions on FSFLA and Devuan. I was able to successfully install the Linux-libre kernel.
I opted for the LTS version and have now installed version 6.12.57-gnu.
I was pleased that it worked. The Excalibur installation was also successful.
However, after booting the system, I saw errors, and when I logged in, the screen displayed "GDBus.Error".
I was able to photograph the following errors during boot:
INIT: version 3.14 booting
INIT: No inittab.d directory found
Using makefile-style concurrent boot in runlevel S.
Starting hot-plug events dispatcher: udevd[ 10.992891] udevd[357]: GOTO ´alsa_restore_std´ has no matching label in: ´/usr/lib/udev/rules.d/90-alsa-restore.rules´
[ 10.993027] udevd[357]: GOTO ´alsa_restore_std´ has no matching label in: ´/usr/lib/udev/rules.d/90-alsa-restore.rules´
.
Synthesizing the initial hotplug events (subsystems)...done.
Synthesizing the initial hotplug events (devices)...done.
Waiting for /dev to be fully populated...([ 14.667087]: Missing Free Firmware (non-Free firmware loading is disabled)
[ 14.667182] radeon_cp: Failed to load firmware "/*(DEBLOBBED)*/"
[ 14.667189] [drm:r100_cp_init [radeon]] *ERROR* Failed to load firmware
[ 14.667321] radeon: failed initializing CP (-2).
[ 14.667331] radeon: Disabling GPU acceleration
[ 14.848947] Error: Driver ´pcspkr´ is already registered, aborting...
[ 20.710713] udevd[361]: Unknown key identifier ´zoom´
done.These were the errors. After logging into lightdm, I got to the start screen and saw the following message:
GDBus.Error:org.freedesktop.ConsoleKit.Manager.Error.General: Unable to lookup session information for process '2284'This number at the end changes constantly after the boot process when I log in again and get to the start screen.
And Daedalus didn't have these errors. Everything worked fine.
I checked and all Linux firmware is installed, including the non-free firmware. I deleted it and reinstalled it. But unfortunately, all without success.
It's a Lenovo T60 laptop. Graphics card is: AMD/ATI RV515/M54 [Mobility Radeon X1400]
If I choose the non-LTS kernel in Linux-libre, the errors will probably still occur, since it's an older system. And the Linux-libre-lts couldn't find any matching kernel headers.
Are these errors occurring because Linux-libre doesn't support non-free firmware? How can these errors be corrected? Is there even a way to do this?
The Linux distributions I described above, and Refracta as well, largely use linux-libre. So they won't provide the solution either, will they?
So, can I simply integrate a linux-libre kernel into Devuan, Daedalus, or Excalibur? Do I just need to follow the steps on the website fsfla.org to get a working system? Or is there anything else I need to do?
And what will the sources.list look like? Will I receive updates from Devuan, for example, and kernel updates specifically from linux-libre?
And is linux-libre systemd-free?
Sounds like a lot of work.
Or I could just stick with Daedalus, which is Bookworm and will probably be supported until 2028.
I've been looking around on Distrowatch. The following systems might be options:
1. Gnuinos. Based on Devuan and uses the Linux-libre kernel.
2. Refracta. Based on Debian, Devuan = systemd-free.
3. Fluxuan Linux. Based on Devuan.
4. Loc-OS. Based on antiX, Debian. Also systemd-free.
5. Adélie Linux.
So I should follow the instructions from Devuan - Upgrade to Excalibur: https://www.devuan.org/os/documentation … -excalibur
So you've installed usrmerge and changed the sources.list to Excalibur. And now I have to install the linux-libre kernel first and only then follow the other steps in the Devuan upgrade installation instructions?
I'll test it out. If that doesn't work, I'll take a closer look at the systems from Distrowatch.
Thanks.
But what's strange is the following:
The release notes state:
## Getting Devuan 6 Excalibur
Devuan 6 Excalibur is available for i386, amd64, armel, armhf, arm64, ppc64el and riscv64 architectures. However, the i386 packages do not include a linux-image. See https://www.debian.org/releases/stable/ … t-for-i386 for details.
When I go to install Excalibur on Devuan, it says: Supported architectures: amd64.
And Excalibur is based on Trixie from Debian. Trixie Debian no longer supports 32-bit architectures. So why does Devuan then state that Excalibur is available for i386?
Hello!
I was just about to upgrade my current 32-bit Daedalus system to Excalibur. While reading through the release notes, I came across the following problem.
It says:
Reduced support for i386
## Getting Devuan 6 Excalibur
Devuan 6 Excalibur is available for i386, amd64, armel, armhf, arm64, ppc64el and
riscv64 architectures. However, the i386 packages don't include a linux-image. See
https://www.debian.org/releases/stable/ … t-for-i386
for details.
Then I clicked on the link and it says the following:
5.1.2. Reduced support for i386
From trixie, i386 is no longer supported as a regular architecture: there is no official kernel and no Debian installer for i386 systems. Fewer packages are available for i386 because many projects no longer support it. The architecture’s sole remaining purpose is to support running legacy code, for example, by way of multiarch or a chroot on a 64-bit (amd64) system.
The i386 architecture is now only intended to be used on a 64-bit (amd64) CPU. Its instruction set requirements include SSE2 support, so it will not run successfully on most of the 32-bit CPU types that were supported by Debian 12.
Users running i386 systems should not upgrade to trixie. Instead, Debian recommends either reinstalling them as amd64, where possible, or retiring the hardware. Cross-grading without a reinstall is a technically possible, but risky, alternative.
Now I'm wondering if I should even bother with an upgrade if it's hardly supported, or not supported at all? And whether the system will still run smoothly after the upgrade?
Until now, TPM was turned off by default.
Apparently the developers decided to fix this.On my laptop I enabled TPM in the BIOS, the messages disappeared, nothing bad happened yet. smile
Okay. :-)
We are forced to enable Intel TPM.
But why is that?
If you don’t want to enable it in the BIOS, you can simply turn off messages during boot.
In/etc/default/grubchange
quiet splashto
quiet loglevel=0 splashand run
update-grubhttps://linuxconfig.org/introduction-to … log-levels
Okay, thanks for the advice to simply hide the notifications.
But I'll rather leave the notifications to stay informed ;-)
I think that ima: error, has something to do with your systems sensors (TPM chip) for Trusted Platform Modules (etc)
that could be due to bios version, firmware updates (search that topic here at Dev1 for apt source list, it changed with Devuan Daedalus)
You may be able to switch it off in bios, but maybe required for M$Win OS's validity!
Maybe my PC doesn't have any TPM chips, I don't know. I looked in the bios and didn't find anything about TPM there.
Apparently TPM is only responsible for signing or something. So it's not really that important for a working old system.
When upgrading from Chimaera to Daedalus, I adapted my sources.list accordingly as prescribed by entering "contrib non-free non-free-firmware" after each line.
To the graphics driver:
I initially opted for the free graphics driver. However, I have since realized that the font is not displayed so well on some websites. So I decided to install the Nvidia driver. "nvidia-detect" showed that I should install the driver: "nvidia-tesla-470-driver". The installation was actually problem-free, but in the end there was an error because "nvidia-persistenced" could not be installed. Even after restarting the computer, this remained unsuccessful. So I decided to uninstall this service from nvidia. This was crowned with success, because the "nvidia-persistenced - Service" could be deleted without any problems. Now Nvidia works without any problems.
Another problem that did not exist under Chimaera:
When starting the computer, the following is now written in several lines:
ima: error communicating to tpm chip
ima: error communicating to tpm chip
ima: error communicating to tpm chip
ima: error communicating to tpm chip
ima: error communicating to tpm chipWhat is this error and how can I fix it? I did not have such an error under Chimaera.
That is because I reused the "Deep Sea" icon set from Chimaera with the "Sapphire" theme. wink
Oh, I see. ;-)
All the previous customized Devuan themes including icons will still be available.
That's good news. :-)
Grub, by default, no longer looks for other operating systems....
I know that.
But what about the new Grub, which is in a new directory and has a new name. Does it recognize other operating systems by default?
Yes, there is a Daedalus "Sapphire" theme and it is in the repos. It should be the default with an Xfce install.
I have now looked at lxappearance and obconf and indeed there is a theme there, that is called Clearlooks-Phenix-Sapphire. But the theme looks slightly different from the conventional Clearlooks theme. But under icons there is no Sapphire theme.
That being said . . . beginning with Excalibur there will no longer be custom theming unless someone steps up to do it. The previous themes will remain in the repos/git until they no longer function properly with gtk3 "advances".
And if there are no more user-defined themes in the future, then all we have left is Clearlooks ;-)
So, I have already updated two computers from "chimaera" to "daedalus". There were actually no problems. Only I had problems with the Nvidia driver. In the end I decided to use the free driver after the installation, because sooner or later it would happen anyway. So far everything is running smoothly.
But there were some things that seemed strange to me and others:
During the update, a reference to "eudev" appeared. The names currently used are no longer used. Instead of "enp0s3" it will become "eth0" again. I had always had the old names and they are much easier to remember and read.
Shortly before finishing the installation, another message about "grub" appeared. The old path to grub is: /etc/default/grub. Now, however, the file is to be given a completely new directory and the name is also quite strange. New directory and name: /tmp/grub.eT2LnZEMv6. Who always comes up with such strange changes and names? The old names are much more logical. In any case, I left the old file and did not install the new one from the package maintainer.
I bet that in the newer "Excalibur" version of Devuan, this will go back to the old name, like the "eudev" thing.
Comparison between Chimaera and Daedalus:
If the Lan cable is not plugged into the PC, Chimaera starts just as quickly as if it were connected with a Lan cable. Daedalus, on the other hand, starts up extremely slowly without a LAN cable. It takes a few minutes for the system to boot up. It was similar with Beowulf.
All the previous versions always had newer themes and icons after the update. Daedalus has nothing of the sort. Somehow Daedalus doesn't really seem to be finished.
Also, the other operating systems were not recognized after installation. This was also the case with Arch Linux. But this could be solved quickly.
I have now taken a closer look at jgmenu. It seems to work fine. I installed jgmenu from Daedalus packages on Chimaera. After a few tries, I managed to get it to look good by my standards. Actually I wanted to make it even better, but somehow it didn't quite work out yet. In that area obmenu was already much easier.
I have a submenu, but how can I actually make another submenu from the submenu?
I used now the old XML obmenu file parallel with jgmenu. Jgmenu is anchored in the Tint2 bar. What else I noticed is that jgmenu can also read the XML file without any problem and can also display it just like obmenu. I like that jgmenu has a search function integrated. That is already very practical. I have set it so that jgmenu uses the same optics settings of obconf and tint2.
...and I shouldn't have said anything. I just tried it on chimaera, and it didn't work due to a missing dependency --> python-glade2.
I use obmenu-generator and/or jgmenu on Openbox. Sorry for the interruption. I'll bow out of the discussion now...
Ah good to know that it no longer works.
So I have now completely solved the UFW problem. After several different attempts in the virtual machine, I noticed the problem. Actually, the problem cause was constantly seen. First a pure Beowulf installation and then an upgrade to Chimaera or even a pure Chimaera installation, brought success. The culprit was nftables. A new, clean Chimaera installation does not contain nftables. Only when I completely removed nftables on my two laptops, the error messages disappeared immediately. UFW is now running fine, with no problems. There are no problems when booting.
I have never heard about Firehol. I will have a look at the links. Thanks pcalvert.
I also miss obmenu. Unfortunately, there isn't really an alternative in Devuan's packages. In the virtual machine I looked at jgmenu under Artix. At first glance, quite okay, but it is not as simple as obmenu. I will continue to use my XML file and modify it as needed and wait until a decent replacement comes along.
So actually I just wanted to get UFW running, and not mess around with nfttables. I have neither the desire nor the time to deal with it in detail. Nevertheless, thank you Marjorie for this tip. I'll keep it in mind and when the time is right, I'll take a closer look. May be that nfs settings don't seem so hard for others, but for newbies it's just different.
I made two attempts yesterday in a virtual machine. On the first attempt I installed Ascii. Then upgraded Ascii to Beowulf and then to Chimaera. Then activated UFW and when booting the system there were no errors, but then when I looked in the terminal to see if it remained activated, it finally did not. The terminal said inactive.
On the second try I reinstalled Chimaera completely. Activated UFW and restarted the virtual machine. When booting, there were no problems and when I looked in the terminal, it actually said active.
So probably I have to reinstall Devuan Chimaera for this to work. But that can not be that I now have to set up everything completely new after every new version in case there are problems. This can't be true, it takes a lot of time and is very stressful and annoying.
On my other laptop, where UFW is constantly disabled at startup, I removed Iptables completely with its dependencies. This laptop now has no internet connection. With the removal of Iptables was also removed Nftables, Connman internet service, UFW .... . I can't connect to the internet with it now. It looks like I have to reinstall Devuan completely. Or is there another step to establish an internet connection?
I have fixed the internet problem. I then started a trial. I installed Iptables, UFW, again. But after booting UFW was not activated. Then again removed Iptables, Nftables, UFW. This time installed only Nftables. After that UFW. UFW installed Iptables as a required package. After that UFW activated and after booting the laptop UFW was deactivated again. Through the links of Head_on_a_Stick I came to the Firwall Firewalld and its graphical interface Firewall-config. I could not start this firewall, it was always disabled. This firewall seems to be really only for SystemD. Could it perhaps be that Chimaera is no longer compatible with older hardware? My second laptop is a Dell. Although Beowulf was still running fine. Chimaera runs, but UFW seems to have problems with it.
On my first laptop, a Lenovo, UFW also has problems. It's strange that an upgrade from Beowulf to Chimaera suddenly causes problems on both devices.
I don't use {G,}UFW but that looks like an invalid configuration file, probably from the older version. Move the file and create a new configuration from scratch.
Unfortunately, I don't know what file exactly to move now and how to create something new.
My output in /var/log/boot looks like this:
Mon May 9 16:57:59 2022: [....] Starting Setting kernel variables: sysctl??7[ ok 8??.
Mon May 9 16:57:59 2022: [....] Setting up resolvconf.../etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /etc/resolvconf/run/resolv.conf
Mon May 9 16:57:59 2022: ??7[ ok 8??done.
Mon May 9 16:57:59 2022: [....] Starting firewall: ufw...Setting kernel variables (/etc/ufw/sysctl.conf)...??7[ ok 8??done.
Mon May 9 16:58:00 2022: [....] Configuring network interfaces...ifup: waiting for lock on /run/network/ifstate.eth0
Mon May 9 16:58:06 2022: ifup: interface eth0 already configured
Mon May 9 16:58:06 2022: ??7[ ok 8??done.
Mon May 9 16:58:06 2022: [....] Cleaning up temporary files...??7[ ok 8??.
Mon May 9 16:58:06 2022: [....] Setting up ALSA...??7[ ok 8??done.
Mon May 9 16:58:06 2022: [....] Setting sensors limits...??7[ ok 8??done.
Mon May 9 16:58:06 2022: [....] Setting up X socket directories... /tmp/.X11-unix /tmp/.ICE-unix??7[ ok 8??.
Mon May 9 16:58:06 2022: INIT: Entering runlevel: 2Are you using UFW in default mode or have you added rules?
Have you tried reinstalling ufw and iptables?
No, I have not added my own rules. I use the default setting with UFW. I have already uninstalled and reinstalled UFW several times with all its dependencies. But the error still persists. It is because of UFW that the errors appear. If I disable UFW, then there are no more error warnings. If I enable it, then the errors come again when I boot the laptop. After booting the laptop, however, UFW remains active.
Output:
root@Lenovo:~# ufw status
Status: activeroot@Lenovo:~# /usr/sbin/ufw status
Status: activeWhat output do you get if you run: sudo service ufw start
Output looks like this:
root@Lenovo:~# service ufw start
Starting firewall: ufw...Setting kernel variables (/etc/ufw/sysctl.conf)...Firewall already started, use 'force-reload'...done.On my other laptop, where UFW is constantly disabled at startup, I removed Iptables completely with its dependencies. This laptop now has no internet connection. With the removal of Iptables was also removed Nftables, Connman internet service, UFW .... . I can't connect to the internet with it now. It looks like I have to reinstall Devuan completely. Or is there another step to establish an internet connection?
Try removing and then re-adding the option to append to iptables.
Where exactly and where should I make a change? I have looked at all the files in the folders and got nowhere.
I might just have to migrate to biting the bullet and learning iptables and nftables.
That way you have less overhead and less to worry about.
Yes, you seem to be right. But unfortunately it is not that easy. Until it is, I will rather switch to another Linux than deal with Iptables and Nftables.
I hope that the bug will eventually go away after all. I mean, the other versions of Devuan had no problems with UFW.