Re: [systemd-devel] Issues with parallelised early boot
On 01/12/2022 17:50, Michal Koutný wrote: Perhaps a slightly different angle -- is the graphics driver necessary to mount the main root FS? (IIUC, you can enter the passphrase even without it? Then you could build a smaller initrd and load the driver later (when visual artifacts won't be hopefully distracting)) It's not strictly necessary for me, but it's nice to have graphics initialised as early as possible and there really shouldn't be any technical obstacles to doing so. Besides, that would only kick the can down the road: the problem of re-triggering the udev rule remains. (Sorry for the duplicate, Michal, not very used to mailing lists :))
Re: [systemd-devel] Issues with parallelised early boot
Hello Naïm. On Sat, Nov 26, 2022 at 01:59:53PM +0100, Naïm Favier wrote: > 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. Perhaps a slightly different angle -- is the graphics driver necessary to mount the main root FS? (IIUC, you can enter the passphrase even without it? Then you could build a smaller initrd and load the driver later (when visual artifacts won't be hopefully distracting)) Michal signature.asc Description: Digital signature
Re: [systemd-devel] Error while trying to boot kernel
Hi. On Sat, Nov 26, 2022 at 11:37:09PM +0200, Nikolay Borisov wrote: > 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. Why do you conclude it's SIGTERM? > [9.047894] Kernel panic - not syncing: Attempted to kill init! > exitcode=0x7f00 This looks loke PID1 exited on its own volition with exit value 127. I am not able to attribute it to anything in systemd. Is the re-execed binary (/[usr/]lib/systemd) systemd at all? (Perhaps it failed to find an executable at some stage, hence 127) HTH, Michal signature.asc Description: Digital signature
Re: [systemd-devel] systemctl hangs with 249.7 systemd in yocto Honister release
Hello Heyi. On Tue, Nov 29, 2022 at 12:44:12PM +0800, Heyi Guo wrote: > Is there any known issue which will cause this problem? Or do you have any > suggestion on how to debug? As written in the report, it looks like dbus-daemon or PID1 itself not responding. Some insights may be obtained by looking at /proc/1/stack and /proc/$pid_of_dbus/stack (as root). HTH, Michal signature.asc Description: Digital signature
