https://bugzilla.suse.com/show_bug.cgi?id=1224404 Fabian Vogt changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on|1219180 | See Also| |https://bugzilla.suse.com/s | |how_bug.cgi?id=1219180 -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1224404 https://bugzilla.suse.com/show_bug.cgi?id=1224404#c1 Antonio Feijoo changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |antonio.feijoo@suse.com --- Comment #1 from Antonio Feijoo --- (In reply to Fabian Vogt from comment #0)

+++ This bug was initially created as a clone of Bug #1219180 +++

Unless the initrd is built with the platform native DRM driver (e.g. virtio_gpu), there is no graphical output during boot. This also means that entering a passphrase for unlocking the root fs is not possible.

Thanks for finding this. It took me some time to reproduce it, because using Leap as host the boot hangs forever (I don't know since when, I have an old vm with snapshot 20231122 and it works), but I could reproduce it with Tumbleweed. FTR:

qemu-system-aarch64 -M virt -cpu cortex-a72 -m 2048 -serial stdio -device virtio-gpu-pci -device qemu-xhci -device usb-kbd -bios /usr/share/qemu/aavmf-aarch64-code.bin -drive if=none,file=$PWD/MicroOS.aarch64-16.0.0-kvm-and-xen-sdboot-Snapshot20240517.qcow2,id=hd0 -device virtio-blk-device,drive=hd0

(In reply to Fabian Vogt from comment #0)

The original bug report has some more details, but the summary is that efifb or other builtin drivers don't work with virtio-gpu-pci. To get any display output at all, the virtio-gpu module is needed. From a dracut PoV, the crypt module should probably pull in drm if virtio-gpu is detected?

I would expand this requirement to when a dracut module needs systemd-ask-password, not only to the crypt module. But, there is a problem with the second part. Nowadays, current upstream admins do not like to pull things based on which kernel modules are loaded on the running systemd. See: - https://github.com/dracutdevs/dracut/pull/2412#discussion_r1239313722 - https://github.com/dracut-ng/dracut-ng/issues/236 -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1224404 https://bugzilla.suse.com/show_bug.cgi?id=1224404#c3 --- Comment #3 from Fabian Vogt --- (In reply to Antonio Feijoo from comment #2)

(In reply to Antonio Feijoo from comment #1)

...

(In reply to Fabian Vogt from comment #0) But, there is a problem with the second part. Nowadays, current upstream admins do not like to pull things based on which kernel modules are loaded on the running systemd. See: - https://github.com/dracutdevs/dracut/pull/2412#discussion_r1239313722 - https://github.com/dracut-ng/dracut-ng/issues/236

Yeah, reading /proc/modules is wrong. Making decisions based on plugged hardware through modalias would be fine though.

Related to this, would it make sense to always add drm in aarch64 unconditionally? Before joining SUSE I used to work with custom boards to be used within satellite transceivers without any display, the only way to interact with them was via serial port or network, so in that case including drm would be useless, but harmless I guess?

Depends on the size IMO. On x86 at least DRM pulls in a huge mess^W mass of kernel modules and firmware. nvidia alone needs ~60MiB... -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1224404 https://bugzilla.suse.com/show_bug.cgi?id=1224404#c5 --- Comment #5 from Antonio Feijoo --- (In reply to Antonio Feijoo from comment #4)

Upstream PR: https://github.com/dracut-ng/dracut-ng/pull/317

It'd need to be adapted to the current version we have in our openSUSE fork, adding a similar check to the crypt module.

Already accepted. Would we need to backport this to another codestream other than Factory? -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1224404 https://bugzilla.suse.com/show_bug.cgi?id=1224404#c7 Antonio Feijoo changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Antonio Feijoo --- (In reply to Fabian Vogt from comment #0)

Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=aarch64&distri=microos&flavor=MicroOS-Image-sdboot&machine=aarch64&test=microos-wizard&version=Tumbleweed)

Fix included since snapshot 20240531, the openQA test no longer fails at ansible/steps/31. -- You are receiving this mail because: You are on the CC list for the bug.