Closed niklas88 closed 2 months ago
I think this might be related to this mkosi issue. There Debian didn't boot with virtio-scsi-pci
hanging at gpt-auto-root
. I also tried with a mkosi
built Fedora image and that actually hangs at gpt-auto-root
though weirdly enough this one doesn't boot in mkosi … qemu
either. Also I tested this on another Arch Linux system with the same results.
For Fedora I used the followign mkosi
command:
mkosi -d fedora -p kernel --autologin -o fedora.raw -f build
Ok, now I'm confused. With Fedora I was trying to debug and used the below modfied mkosi
command to get an unlocked root account so the emergency shell would work but with that it just booted all the way to the shell:
mkosi -d fedora -p kernel --autologin -o fedora --root-password='hashed:' -f build
systemd-vmspawn -i fedora.raw
The same didn't help with Arch Linux though.
This should be fixed by #33697 please let us know if you can still see the issue with vmspawn from git main
systemd version the issue has been seen with
256
Used distribution
Arch Linux
Linux kernel version used
6.9.5-arch1-1
CPU architectures issue was seen on
x86_64
Component
systemd-vmspawn
Expected behaviour you didn't see
Got systemd-256 in Arch Linux and want to test mkosi + systemd-vmspawn using the "Example 1" from its man page. The image build works but then the boot inside
systemd-vmspawn
hangs. So I thought maybe the image is wrong and tried withmkosi --output image.raw qemu
but that works.Unexpected behaviour you saw
This first boots normally but then hangs indefinitely at:
Waited several minutes then killed it with ctrl+]*3
Steps to reproduce the problem
I built an Arch Linux image using
mkosi
and the exact command from thesystemd-vmspawn
Example 1I first though the image is bad so tried booting it with mkosi's QEMU support
I also tried `sudo systemd-vmspawn --image=image.raw`` with the same behavior.
Additional program output to the terminal or log subsystem illustrating the issue
No response