[systemd-devel] Error while trying to boot kernel

2022-11-26 Thread Nikolay Borisov



Hello,

I'm trying to boot a custom kernel which is based off rhel9, the environment is 
a bit crazy.
I'm booting it inside qemu but I use ubuntu to create the initrd, as can be 
seen from the
attached log everything works up until switch root has to happen and then I get 
a
SIGTERM and booting dies. Kernel command line is:

systemd.log_level=debug systemd.log_target=console root=/dev/mapper/vhs-root 
rd.lvm.lv=vhs/root console=ttyS0

Systemd in initrd is:
systemd 249 (249.11-0ubuntu3.6)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL 
+ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP 
+LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD 
-XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified



initrd-switch-root.service: AssertPathExists=/etc/initrd-release succeeded.
Failed to read pids.max attribute of cgroup root, ignoring: No data available
initrd-switch-root.service: Passing 0 fds to service
initrd-switch-root.service: About to execute systemctl --no-block switch-root 
/sysroot
initrd-switch-root.service: Forked systemctl as 517
initrd-switch-root.service: Changed dead -> start
 Starting Switch Root...
Got cgroup empty notification for: 
/system.slice/initrd-udevadm-cleanup-db.service
initrd-switch-root.service: Executing: systemctl --no-block switch-root /sysroot
systemd-journald.service: Got notification message from PID 161 (FDSTORE=1)
systemd-journald.service: Added fd 11 (n/a) to fd store.
Bus private-bus-connection: changing state UNSET → OPENING
sd-bus: starting bus private-bus-connection on fds 15/15 (socket:[16383], 
socket:[16383])...
Bus private-bus-connection: changing state OPENING → AUTHENTICATING
Registering bus object implementation for path=/org/freedesktop/systemd1 
iface=org.freedesktop.systemd1.Manager
Registering bus object implementation for path=/org/freedesktop/systemd1/job 
iface=org.freedesktop.systemd1.Job
Registering bus object implementation for path=/org/freedesktop/systemd1/unit 
iface=org.freedesktop.systemd1.Unit
Registering bus object implementation for path=/org/freedesktop/systemd1/unit 
iface=org.freedesktop.systemd1.Automount
Registering bus object implementation for path=/org/freedesktop/systemd1/unit 
iface=org.freedesktop.systemd1.Device
Registering bus object implementation for path=/org/freedesktop/systemd1/unit 
iface=org.freedesktop.systemd1.Mount
Registering bus object implementation for path=/org/freedesktop/systemd1/unit 
iface=org.freedesktop.systemd1.Path
Registering bus object implementation for path=/org/freedesktop/systemd1/unit 
iface=org.freedesktop.systemd1.Scope
Registering bus object implementation for path=/org/freedesktop/systemd1/unit 
iface=org.freedesktop.systemd1.Service
Registering bus object implementation for path=/org/freedesktop/systemd1/unit 
iface=org.freedesktop.systemd1.Slice
Registering bus object implementation for path=/org/freedesktop/systemd1/unit 
iface=org.freedesktop.systemd1.Socket
Registering bus object implementation for path=/org/freedesktop/systemd1/unit 
iface=org.freedesktop.systemd1.Swap
Registering bus object implementation for path=/org/freedesktop/systemd1/unit 
iface=org.freedesktop.systemd1.Target
Registering bus object implementation for path=/org/freedesktop/systemd1/unit 
iface=org.freedesktop.systemd1.Timer
Registering bus object implementation for path=/org/freedesktop/LogControl1 
iface=org.freedesktop.LogControl1
Accepted new private connection.
Bus private-bus-connection: changing state AUTHENTICATING → RUNNING
Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 
path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager 
member=SwitchRoot cookie=1 reply_cookie=0 signature=ss error-name=n/a 
error-message=n/a
Sent message type=method_return sender=org.freedesktop.systemd1 destination=n/a 
path=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 signature=n/a 
error-name=n/a error-message=n/a
Serializing systemd-state to memfd.
Bus private-bus-connection: changing state RUNNING → CLOSING
Failed to send reloading signal: Connection reset by peer
-.mount: not serializing before switch-root
tmp.mount: not serializing before switch-root
sysroot.mount: not serializing before switch-root
sys-fs-fuse-connections.mount: not serializing before switch-root
Switching root.
systemd-journald.service: Releasing resources.
systemd-journald.service: Releasing all stored fds
Bus private-bus-connection: changing state CLOSING → CLOSED
[9.047894] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x7f00
[9.048468] CPU: 2 PID: 1 Comm: systemd ve: / Not tainted 
5.14.0-70.22.1.ovz9.17.8-default #9 ovz9.17.8
[9.049149] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.15.0-1 04/01/2014
[9.049905] Call Trace:
[9.050146]  dump_stack_lvl+0x45/0x59
[9.050412]  panic+0x10f/0x2c4
[9.050653]  do_exit.cold+0x67/0xad
[9.051256]  do_group_exit+0x39/0xb

[systemd-devel] Issues with parallelised early boot

2022-11-26 Thread Naïm Favier

When using systemd as PID 1 in the initrd, there is no sequencing between 
loading kernel modules
(systemd-modules-load.service) and starting udev (systemd-udevd.service).
I load my graphics driver (amdgpu) with systemd-modules-load, which takes about 
three seconds,
so it finishes loading after udev has started and picked up the initial events, 
and while the
LUKS passphrase prompt is waiting for my input.

At that point, the screen briefly flashes and two undesirable behaviours occur:

1. The font initially set by the 90-vconsole udev rule is reset to its default.
2. The lines previously written to the console are scrolled up a bit while the 
cursor stays floating
   in the middle of the screen. After typing my passphrase, output resumes at 
the cursor, leaving a gap.

If I restore the ordering by adding After=systemd-modules-load.service to 
systemd-udevd.service, both issues go away.
Hence my questions:

Is the lack of sequencing between those two units intentional/desirable? I 
suppose it is, but I thought I'd ask anyway.

If so, then 1 and 2 are bugs; how should I go about troubleshooting them? Are 
they bugs in Linux? AMDGPU?
Could systemd somehow be involved (at least for 2)? Any pointers appreciated.

Some context: , 


Thanks