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.

As it stands now, udev seems to work correctly, so it's not a big deal.
The only "problem" here may be a few microseconds and a few kb of ram temporarily used when starting the "start-stop-daemon" binary itself. I was only pointing this out because I believe any unneccessary "extra layer", even one as simple as start-stop-daemon, should be justified, and, as you know it had already caused some problems in the past.

Again, right now everything seems to work correctly wrt udev, so no problems here.

This is not a grub problem - grub loads the kernel and the initrd into memory from "within" the iso when the iso itself is on an ntfs partition.
The problem appears later, I think, when initrd is parsing the "fromiso=/dev/sda3:/path/to.iso" kernel command line parameter. It tries to mount the iso but fails, because it can not mount ntfs filesystem.
Edit:The full grub entry looks like this (has been working since forever with debian,devuan, ubuntu with some changes):

menuentry 'Devuan Ascii 2.1 Live cd' {
        set root="hd0,3"
        set isofile="/devuan_ascii_2.1_amd64_desktop-live.iso"
        set gfxpayload=keep
        loopback loop ($root)$isofile
        linux   (loop)/live/vmlinuz boot=live username=devuan fromiso=/dev/sda3$isofile
        initrd  (loop)/live/initrd.img
    }

This seems to be an initrd problem, it might be necessary to regenerate it and include the ntfs modules. Here's why I think so:
1) Open/unpack the "devuan_beowulf_3.1.0_2020-11-30_amd64_desktop-live.iso" file.
2) Within it: go to "/live" directory.
3) There is a file "initrd.img"
4) Open/unpack this file (on ascii, use "unmkinitramfs" command)
5) Go to "/lib/modules/4.19.0-13-amd64/kernel/fs" within it.
6) Note there are directories like btrfs, ext4, fat, xfs, but there is no "ntfs" directory
7) Now, inspect the "devuan_ascii_2.1_amd64_desktop-live.iso", for example, and see that "ntfs" directory is there. (obviously the path is a bit different due to different kernel version, "/lib/modules/4.9.0-11-amd64/kernel/fs". That one loads the iso from ntfs partition just fine.

Also, when unpacking the initrd from ascii 2.1 live iso when using "unmkinitramfs", we get two directories - "early" and "main", "early" contains processor microcode, "main" contains the initrd tree itself. That means there are basically two (2) archives in the initrd itself.

Shouldn't the "beowulf-3.1" initrd also include processor microcode?
Note: I am using the ascii "unmkinitramfs" script to unpack a "beowulf" initrd, that may be a source of the problem.

Please doublecheck.

Again, it doesn't cause problems, it's simply not needed if udev has done all the work wrt detecting mouse/kbd/sound etc. As I've said, udev seems to be working correctly.
However acpi-fakekey may be needed on the live image itself, if perhaps, something fails on an unusual configuration. Having an extra layer of reliability is not a bad idea for livecd.
But perhaps you can exclude it from the system which will be installed to hdd itself.

Confirming: adding sleep 3 between start-stop-daemon and udevadm trigger --action=add allows to boot livecd with no problem.

Update:
The bug report contains a proposition to try to run start-stop-daemon without --background, but using --daemon argument. That means adding --daemon to the end of start-stop-daemon line, and it will be passed to eudev. I think I've tried that right before the beowulf release, but that didn't seem to work.

So what exactly is refracta-beta5 ?
There were so many of them I am getting confused.

I've already managed to build my own "beowulf live mate edition" iso using refractasnapshot.
It works and behaves the same as refracta/beowulf rc with regards to eudev/modules.

TLDR:
Udev works when started as udevd -d, but doesn't work when wrapped with start-stop-daemon.

In more detail:
When booting, take a look at the messages early on. When displaying "waiting for /dev to be fully populated" there's a message: settle: could not connect to daemon.
When booting to runlevel 1, and looking at the running processes we see udev isn't there. There's also an orphaned pid file left, as well as /run/omitsigs.... link to it.

It probably means that udevd dies/gets killed early on before it finishes detecting everything.

The simplest way to restart eudev is:

udevd -d
udevadm trigger --action=add

Doing service eudev stop is not needed because there is simply nothing to stop, it isn't there.
Doing service eudev restart doesn't help because even if does start the daemon (I am not sure it does), it doesn't call udevadm trigger --action=add.

After tinkering with init script a bit, I decided to replace the start-stop-daemon invocation of eudev with a simple udevd -d invocation. I've burnt a live cd with this version of eudev init script, and it seems to work flawlessly without any other workaround. (I am still testing this).

The start-stop-daemon is needed to grab udevd's pid and write a pid file. Also a link is placed to /run/sendsigs... to prevent sendsigs
from killing udev earlier than needed. As specified in the comments of eudev init script, this is related to debian #791944.
Take a look at this thread here:
https://bugs.debian.org/cgi-bin/bugrepo … bug=791944
It's also related to delays on shutdown when unmounting encrypted stuff.

All of this is probably unneccessary on the live cd, and even if it is, we can just try to manually grab the pid of udevd and create the pid file and sendsigs.omit link ourselves without using start-stop-daemon.

edit:typo