That does explain the error.

I will keep on testing then.

UPDATE: after a few more clocking sessions, the difference in start-up time may be even lesser: 6-7s with vdev vs 7-8s with eudev. Not something I would have noticed without a timer anyway.

I have now removed policykit-1-gnome (and a whole bunch of dependencies it had pulled) and installed lxpolkit instead, and it does the job just as well. I only had to check the box in the session configuration GUI to get it to autostart.

After a fresh VM install of the 2025-02-11 iso, I have clocked 6 seconds to get from the GRUB menu to the lxdm greeter. After doing apt install eudev, I was getting about 8 seconds. I had to stop testing there, because for some reason I could not revert to vdev, so I installed afresh and I am getting 6 seconds to login screen again, using vdev.

I can keep testing further, but for now I am not sure why  apt install vdev is not working. I am getting into a dependency trap, out of which the only way is to keep eudev and whatever can escape the trap.

UPDATE: I was eventually able to revert to vdev by using apt-get install vdev instead of apt install vdev, although the previous error may in fact have been caused by a network issue. Anyway, I have noticed that the keyboard layout used by the lxdm greeter is the one selected at install time if eudev is installed, while the default en-US is used when vdev is at work.

apt update works fine on the older system, but I am currently getting error messages complaining about GPG on the newer one.

UPDATE: problem gone after reboot, both systems are now updated and fully upgraded. The error I was getting was related to the content of /var/lib/apt/lists:

Splitting up /var/lib/apt/lists/packages.gnuinos.org_merged_dists_daedalus_InRelease into data and signature failed

DENOUEMENT: The lack of space that triggered the error was caused by a ridiculously undersized root partition. An easy thing to miss.

Some seem to believe that throwing ever more non-free microcode to solve a problem created by non-free microcode is a good idea. Others argue that there is indeed no basis to trust that the same people who produced insecure microcode in the first place are magically going to make it secure, since the newer microcode is as non-free as the older, and likewise unavailable for public scrutiny. Applying the appropriate mitigations, which does not involve injecting any extra non-free microcode, may thus sound like a better idea.

I also find a bit confusing that a software project called "libre*" would decide to distribute non-free bits. The libre bootloader controversy will probably ease in time and eventually become an archeological artefact. Meanwhile, GNU Boot offers a de-confusing option for those who are looking for a full commitment to software freedom.

Thanks for confirming. I thought the linux-libre kernel would most probably not load any of that anyway, but after the Debian policy change these matters have become a source of confusion.

And thank you for the new images.

The LO window also freezes here after 5-10 seconds when I try to open 3_new.odt. Older kernel (5.15) and later LO (24.8), same system memory (8 GiO). So the devil really is in the details of the odt.

If you could overcome the Table-in-a-Frame copying bug, you may still have a chance to recover its content: if I keep scrolling along for about 20+ seconds, the beast eventually get tamed and I am able to get a reasonably pliant document. I also get one core running at 100% once the window has frozen, but the situation is not much better after taming the beast. It is still a wild beast after all, even if a tamed one.

I believe the iso images needed some time off, so they decided to take brief offline holidays.

Anyway, I had already downloaded the latest (2024.06.01) iso the other week, so I can confirm that the XFCE-runit amd64 image rocks, as usual.

Updated summary of current results booting XFCE amd64 images from the USB flash drive on that workstation:

nvidia GPU plugged in - and set either as non-boot device or as primary VGA

• all images return:

$ lspci -k | grep -EA3 'VGA|3D|Display'
00:02.0 VGA compatible controller: Intel [...] Integrated Graphics Controller
	Kernel driver in use: i915
01:00.0 VGA compatible controller: NVIDIA [...]
	Kernel driver in use: nouveau	

• all gnuinos test images boot into tty1, no graphical session

• Devuan desktop-live boots into XFCE session OK, using whichever GPU is set as primary VGA

NB: it transpired that the Devuan desktop-live image is loading a bevy of nvidia firmware blobs to be used with that NV137 (GP107) GPU. Maybe gnuinos could try defaulting to llvmpipe instead?

nvidia GPU unplugged

• all images boot into XFCE session OK, kernel driver in use i915

Thank you. Still no luck with the eudev image, same situation as with vdev. The first line in the Xorg log that seems to indicate an error is the following one:

nvc0_screen_create:1072 - Base screen init failed: -19

EDIT: I am getting the same error log as that one, just substitute "crocus" for "iris": https://bugs.debian.org/cgi-bin/bugrepo … 867;msg=45. The live system sends me to a blinking cursor every so often, which makes it a bit tricky to type in commands.

After further testing, both runit and sysvinit XFCE images boot fine on the usual laptop with Intel GMA 3150.

They also boot fine into a VM on the desktop I am currently testing on (with Intel HD 4600 graphics), but from the USB flash drive I keep getting crocus_dri related errors in the Xorg log. I can start a session through tty, but no graphical session so far. Crocus mystery.

Anyway, elogind seems to be happy now, no error messages any more. 👍

Great, thank you! Both now boot fine into their respective DE/WM. I can also confirm that the xfce-runit image is booting fine, as expected.

It is just amazing to have so much choice on aging harware, in complete freedom.

Note how they do not call it "clean", but "green".