Just tested a beowulf and a daedalus live images -
Tty autologin works on both of them - there's a working command line of ttys 1-6, already logged on.
Mc output is garbled on both of them, in tty, unlike on desktop, where it works.

So on excalibur it's the autologin on tty that doesn't work. Ideal is to keep same behaviour as previous versions, i.e. autologin.
But a working login prompt is infinitely better than a black screen that doesn't respond to anything.

@fsmithred, please clarify, were you able to reproduce the tty non-working console problem on your hardware?

The xfconf-query command did not work for me.

I have a feeling this problem may resolve itself on it's own (i.e. get fixed upstream) as we get closer to release.

But, for now: where exactly does xfce store the desktop background info? Is it a conf file, or some dconf/registry kind of thing?
Also, I think we should pay attention to "apply to all workspaces" checkbox in the desktop background selection screen.

Worst case, dirty and ugly but probably working hack: replace the file with the xfce default wallpaper with the devuan one :-)

Regarding daedalus - that's not an urgent problem or something. It's just that I was always able to find kernel headers of appropriate version in the live image, from jessie to chimaera, and also now on the excalibur preview. Just keep that in mind IF you're going to make a point release of daedalus for some more serious reason, try and make sure the kernel is of a version that has matching headers in the repos.

That may be a good idea. If you do, please report the results in this thread.

I was able to get to the command line by booting to runlevel 1, but not in any other way.

Grabbed the new iso.

The (null) plugin error does not happen anymore.

Managed to build zfs and import the pools - had to manually install the kernel headers of the appropriate version, they are available in the repo, but not listed in the requirements for zfs-dkms, I think, and they WERE required and thus got auto-installed in previous versions. This is quite a big test, if this worked, means system is in a good shape already.

Have no idea why the wallpaper get auto-covered with the default xfce one. I right clicked on desktop, and it shows all the devuan ones, and an appropriate dark-blue one is even selected/highlighted, but still the wallpaper gets auto-changed. If this is the biggest problem, I wouldn't worry about it too much until we're farther in the freeze-cycle.

The biggest "WTF" for me is:
Why the hell I don't have a command line in ctrl-alt-f1, and ctrl-alt-f2 up to ctrl-alt-f6 are black screens ?!

Using this iso:

6fe3b7ad120e7afdf49cb6bcbe21be0dc27bbe65835db7f063517655fed31817  devuan_excalibur_6.0-preview-2025-03-22_amd64_desktop-live.iso

Iso on hdd, grub entry to boot it:

menuentry "devuan_excalibur_6.0-preview-2025-03-22" 
{
    insmod part_gpt
    search --no-floppy --label linux_iso --set root
    set isofile="/devuan_excalibur_6.0-preview-2025-03-22_amd64_desktop-live.iso"
    loopback loop ($root)$isofile
    linux (loop)/live/vmlinuz boot=live fromiso=/dev/disk/by-label/linux_iso$isofile username=devuan apparmor=0
    initrd (loop)/live/initrd.img
}

Equivalent entries work well for all earlier devuan versions.

Just tested it and I do get the (null) plugin error initially. Have to click "remove", or click "quit". Clicking quit removes the panel, I then have to open terminal by right-clicking on desktop, and manually running the panel again.

If I log out and then back in through the lightdm login screen as "devuan" user, the error doesn't happen.

One time the screen froze, no mouse movement or anything, though I could see hdd still working. Only hard power off helped.

I only get Ctrl-Alt-F1 screen where I see the boot log, but no login prompt, and the Ctrl-Alt-F7 screen with X.
Ctrl-Alt-F{2,3,4,5,6} screens are not available. So there's no possibility to log in using just the console.

I had problems accessing deb.devuan.org, but that's probably a network problem, not a devuan one. Fixed by specifying us.deb.devuan.org in sources.list.

Couldn't build zfs packages in the live session, it tried to install zfs-initramfs, but couldn't, told me something like "running in live environment, file system is readonly, so can't modify initramfs".  And withoud that package, other packages do not install.
Again, probably not a devuan problem, but I could always build zfs packages in devuan live sessions before. Maybe will retry with "toram=1" to have a proper read-write root fs.

Other than that, video device works fine, network works fine, so it's usable.

That's it for the moment.

Well, that much is obvious indeed.

Let's mark this one solved.

It most certainly doesn't boot here without "apparmor=0". I just tried it again.

Irrelevant. Tried both. Makes no difference, unlike apparmor parameter.

If you'd like to kick the thread a little bit more, we can try and find the difference that makes the difference. On first glance:
1) You have gpt partition table, I have msdos.
2) I don't have tzdata param

But I consider this "solved" because a real live image, when burned to usb/dvd, will use apparmor=0 param. Thus I am replicating  a real live boot with this, and since it seems to work as intended, case should be closed for now.

Nice try. :-D

I boot from sdb by default (set in bios).
Thus hd1,9 becomes "the other hd". It works for all other distros, I've tested it extensively . Also, like I've said grub can get the the kernel and initrd from within the iso image.
I've tested also the "findiso=$isofile" option, which means, as far as I know, to look thru all partitions looking for iso with the given name.

Same happens if the partition is xfs.
The volume gets mounted, and then immediately unmounted.

Also: in the beginning, when udev runs detection, the font on-screen doesn't change after the resolution changes, this might indicate that there are problems with udev, if so, that could be the root cause.

LightDM can be a bit finicky.

Take a look at these bugs.

https://bugs.debian.org/cgi-bin/bugrepo … bug=636108
https://bugs.debian.org/cgi-bin/bugrepo … bug=752129

On my Beowulf main box, I had to create ~/.xsessionrc file that would source /etc/profile and ~/.profile to work around.

Also, lightdm is likely to just break and refuse to start if there's some gsettings conf value missing, or something equally unimportant and minor happens.

For a live cd, slim is probably better.

ps) When do we get a daedalus script for debootstrap?

edit: typo

I've tried patching it myself, but I am unable to boot with a modified initrd which I've reconstructed by myself.

Maybe you can suggest something?

I unpack the beowulf-live initrd with

unmkinitramfs initrd.img /path/to/extracted/initrd-tree

After I've applied some changes, how do I compress it in exactly the same format?
I've tried the following:

find . | cpio -H newc -o > ../initramfs.cpio
cat initramfs.cpio | gzip > initramfs.igz

But boot failed immediately and dropped me to the shell even though I've only added some debug prints.

Do I have to insert the initrd into the iso image itself, or can I simply modify grub entry to load the custom initrd and it should work?

That seems close to the target.
If I have some time and energy in the next few days, maybe I'll try looking into it more. It might be just a few lines of code needed to fix it.

For the moment, we can conclude that it's another feature that has been working for decades but has been cancelled by Debian.
Thus it doesn't block release of beowulf 3.1.