Congrats, greenjeans

Prospero, I've fixed the issue. I recommend you to upgrade the whole system allowing all the changes in /etc/init.d/ because sysvinit scripts have been migrated to pure openrc by building a new debhelper utility dh-openrc analogous to dh-runit. Hence, sysv-rc no longer exists in the repository. It wouldn't work with the shebang #!/sbin/openrc-run. In the same way, I also dropped bootlogd as I've not been able to get it working with openrc. Anyway, you can get the openrc log via:

# cat /var/log/rc.log

I'm doing the same with runit right now, i.e. migrating the initscripts to pure runit. And I'm planing to build a dh-s6 in order to provide a genuen image with Skarnet's s6 process supervision and initialization suite in the near future as well.

As always, thank you for your great help

# hwclock --set --date "2026-06-06 3:44"
# date --set "2026-06-06 3:44"

fake-hwclock is a service designed for boards that do not have a battery or a real hardware clock (such as the Raspberry Pi). What it does is save the time to a text file when the system is shut down and restore exactly that same time when it is switched on. Therefore, I guess that this is causing a conflict with the real clock and freezing the system in the past. I'll try to fix this issue..., maybe disabling fake-hwclock and moving hwclock.sh from the sysinit runlevel to the boot runlevel.

I added xfce-polkit to the iso image.

@prospero: I'm fixing the issue with LVM + Encryption

It's working for me:

https://www.genuen.org/videos/di_lvm.mkv

I've solved the issue: it seems that a prior input-only OS_SUBSYSTEM filter applied to zzz-udev-compat.act in the vdevd.1 profile left DRM without G:seat / E:ID_SEAT entries. Thanks

First of all, thank you so much for the kind words, for opening this new thread, and for your valuable feedback on the latest genuen iso. Your testing is essential to making this release stable.

I have been investigating the "blinking cursor" issue ((EE) No devices detected / no screens found) in Qemu/KVM, and I wanted to share my findings and what I have ruled out so far.

What I have verified:

    The bug is specific to the ISO environment: I have successfully upgraded older existing installations on physical machines with both UEFI and BIOS, and they boot and work perfectly. But, when booting the new live iso in Qemu and some physical machines, it indeed stalls at the blinking cursor right after loading the system services.

Technical details & What has been ruled out:

To isolate the issue, I have performed several tests on the live image configuration, ruling out the most obvious changes:

1) Not a Secure Boot / Kernel issue: I am aware that the custom genuen certificate (generated to bypass the MS-signed Debian certificate) has expired, and I haven't resigned the linux-libre kernel yet (as my initial Secure Boot attempts failed). However, this is 100% unrelated to this bug since Secure Boot is disabled in your VMs, the kernel boots perfectly, and services initialize normally before the crash. If it were a signature issue, UEFI would have blocked the boot way earlier.

2) Not a vdev or xlibre issue: I tried reverting vdev back to eudev, and swapping xlibre back to stock X11. The blinking cursor persisted. The issue does not stem from either of them.

3) Not the latest display tweaks: I tried completely removing the nouveau.modeset=1 kernel parameter and deleting a custom configuration file I added under /etc/X11/xorg.conf.d/. Surprisingly, the error remains. Most other recent changes are strictly constrained to vdev and libudev-compat on the one hand, and simple-netaid and avmix (formerly amixer-gtk) on the other hand (including their respective xfce-panel plugins).

4) List of Banned Packages Expansion: Another major change in this iso was tightening the package blacklist in Amprolla, strictly following the FSF's  https://libreplanet.org/wiki/list_of_so … Guidelines. While I don't think this should break Xorg directly, it is something to keep in mind regarding potential underlying dependency drops.

Current status:

This is quite mysterious, as the underlying system seems to be completely functional, but Xorg fails to detect the emulated virtual screens in Qemu.
I am still digging deeper into the ISO build configuration to find out why the virtual graphic drivers are failing to load on this specific build. In the meantime, if anyone can try booting the live image with the nomodeset kernel parameter added to GRUB, please let me know if it allows you to bypass the cursor.

Thank you all for your patience and support. I will keep you updated!

I managed booting genuen + vdev + seatd + xlibre without any display manager https://www.genuen.org/mirror/excalibur and the result is that coldplug input devices at server start do work (devices present before xlibre starts, or after restarting xlibre with the device already plugged in), but disconnect/reconnect or a newly plugged input/event* node won't respond until xlibre is restarted, unless a workaround is used -for example, adding myself to the input group, which isn't very convincing-; the best workaround I've found is to add startxfce4 to ~/.xinitrc and use exec startx instead. I have:

#!/bin/sh
exec /etc/X11/Xsession startxfce4

Btw, I'm curious to try chimera's turnstile, so I downloaded your iso. Thanks!

I updated the repo

Polkitd looks for authorisation rules in several directories, but cannot find them. Polkit simply reports that these optional directories are not present. But this is not a serious issue as long as it manages to load the basic rules.

Hmmm... ilargi means moon in basque