We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initrds=
QemuFirmware=linux
main
Fedora 40
Arch
6.11.6-200.fc40.x86_64
x86_64
When using direct kernel boot (i.e. QemuFirmware=linux) any custom build initrds set with Initrd= are not picked up.
Initrd=
I have experienced this when working with mkosi-kernel which uses direct kernel boot extensively
No response
The are no warnings because mkosi still starts. However, the qemu cmdline does not contain any "-initrd foobar" flag: ‣ + /usr/bin/qemu-system-x86_64 -machine type=q35,memory-backend=mem -smp 2 -m 4096M -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0,id=rng-device0 -device virtio-balloon,free-page-reporting=on -no-user-config -object memory-backend-memfd,id=mem,size=4096M,share=on -nic user,model=virtio-net-pci -accel kvm -device vhost-vsock-pci,guest-cid=253982209,vhostfd=4 -cpu max -nographic -nodefaults -chardev stdio,mux=on,id=console,signal=off -device virtio-serial-pci,id=mkosi-virtio-serial-pci -device virtconsole,chardev=console -mon console -kernel /home/septatrix/Documents/university/semester13/LKP/Lab/mkosi-kernel/mkosi.output/image.vmlinuz -chardev socket,id=sock-b35e25b2ec774548a9d5fa4389c4ae,path=/tmp/mkosi-virtiofsd-7928yvv_/sock-b35e25b2ec774548a9d5fa4389c4ae -device vhost-user-fs-pci,queue-size=1024,chardev=sock-b35e25b2ec774548a9d5fa4389c4ae,tag=root -chardev socket,id=sock-35ae7bf19ecb4b18a8a723b32fe2e1,path=/tmp/mkosi-virtiofsd-k4vh_7y9/sock-35ae7bf19ecb4b18a8a723b32fe2e1 -device vhost-user-fs-pci,queue-size=1024,chardev=sock-35ae7bf19ecb4b18a8a723b32fe2e1,tag=share -device virtio-scsi-pci,id=mkosi -drive if=none,id=scratch,file=/var/tmp/mkosi-scratch-lkzo39b9,format=raw,discard=on,cache.writeback=on,cache.direct=on,cache.no-flush=yes,aio=io_uring -device virtio-blk-pci,drive=scratch -smbios type=11,value=io.systemd.credential.binary:firstboot.locale=Qy5VVEYtOA== -smbios type=11,value=io.systemd.credential.binary:firstboot.timezone=RXVyb3BlL0Jlcmxpbg== -smbios type=11,value=io.systemd.credential.binary:ssh.authorized_keys.root=c3NoLXJzYSBBQUFBQjNOemFDMXljMkVBQUFBREFRQUJBQUFCQVFDdXRWbWo5OXFVOVVMVWpIYVpmczNOVk53OXRFNWNoc0tmUUpUZ0s5SU9EdGt0aTYxTzZQNXpHRTZMWDh4bm5CWmhqSU5HV0gzYjlMbkh4QUNYVEYycksrTUFSSlpGV1BaZWlQRUNISHVnekJFVFYxMEMzTTRjZmcrdy9ZdlhmLzAvampDdEw4akFmOGdTSzVUaENRNERJOENBUCsraGFyN2hhUGxFSG45YXphWDJPYVJFSDU5aUZ0ZjFEdmkybjJ5TkdibGhKbityRVpMMThYVDFDTnZsMG91TVlRMndPaWdsY3IyL0N5amlkVDZSdU91Ky9zbE83bHRDV05YejdxcVJtNDRZbTBHYU9VekxUV09BSXkxOGx2YWphdEUyN1N4YlJHVnZqaTY2aytvZ2RPRmxKUHl5dlhrckExaS96ZXl6WjMxcTRzQ0FhMmIvUnZQMHRSeUg= -smbios type=11,value=io.systemd.credential.binary:fstab.extra=c2hhcmUgL3Jvb3Qvc2hhcmUgdmlydGlvZnMgeC1pbml0cmQubW91bnQK -smbios type=11,value=io.systemd.credential.binary:vmm.notify_socket=dnNvY2stc3RyZWFtOjI6MjA3NDQxNDI5Ng== -append 'rw systemd.wants=network.target module_blacklist=vmw_vmci systemd.tty.term.hvc0=xterm-256color systemd.tty.columns.hvc0=167 systemd.tty.rows.hvc0=23 ip=enc0:any ip=enp0s1:any ip=enp0s2:any ip=host0:any ip=none loglevel=4 SYSTEMD_SULOGIN_FORCE=1 systemd.tty.term.console=xterm-256color systemd.tty.columns.console=167 systemd.tty.rows.console=23 console=hvc0 TERM=xterm-256color enforcing=0 rw systemd.ssh_auto=no init=/init root=root rootfstype=virtiofs systemd.mount-extra=LABEL=scratch:/var/tmp:ext4'
The text was updated successfully, but these errors were encountered:
No branches or pull requests
mkosi commit the issue has been seen with
main
Used host distribution
Fedora 40
Used target distribution
Arch
Linux kernel version used
6.11.6-200.fc40.x86_64
CPU architectures issue was seen on
x86_64
Unexpected behaviour you saw
When using direct kernel boot (i.e.
QemuFirmware=linux
) any custom build initrds set withInitrd=
are not picked up.I have experienced this when working with mkosi-kernel which uses direct kernel boot extensively
Used mkosi config
No response
mkosi output
The are no warnings because mkosi still starts. However, the qemu cmdline does not contain any "-initrd foobar" flag: ‣ + /usr/bin/qemu-system-x86_64 -machine type=q35,memory-backend=mem -smp 2 -m 4096M -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0,id=rng-device0 -device virtio-balloon,free-page-reporting=on -no-user-config -object memory-backend-memfd,id=mem,size=4096M,share=on -nic user,model=virtio-net-pci -accel kvm -device vhost-vsock-pci,guest-cid=253982209,vhostfd=4 -cpu max -nographic -nodefaults -chardev stdio,mux=on,id=console,signal=off -device virtio-serial-pci,id=mkosi-virtio-serial-pci -device virtconsole,chardev=console -mon console -kernel /home/septatrix/Documents/university/semester13/LKP/Lab/mkosi-kernel/mkosi.output/image.vmlinuz -chardev socket,id=sock-b35e25b2ec774548a9d5fa4389c4ae,path=/tmp/mkosi-virtiofsd-7928yvv_/sock-b35e25b2ec774548a9d5fa4389c4ae -device vhost-user-fs-pci,queue-size=1024,chardev=sock-b35e25b2ec774548a9d5fa4389c4ae,tag=root -chardev socket,id=sock-35ae7bf19ecb4b18a8a723b32fe2e1,path=/tmp/mkosi-virtiofsd-k4vh_7y9/sock-35ae7bf19ecb4b18a8a723b32fe2e1 -device vhost-user-fs-pci,queue-size=1024,chardev=sock-35ae7bf19ecb4b18a8a723b32fe2e1,tag=share -device virtio-scsi-pci,id=mkosi -drive if=none,id=scratch,file=/var/tmp/mkosi-scratch-lkzo39b9,format=raw,discard=on,cache.writeback=on,cache.direct=on,cache.no-flush=yes,aio=io_uring -device virtio-blk-pci,drive=scratch -smbios type=11,value=io.systemd.credential.binary:firstboot.locale=Qy5VVEYtOA== -smbios type=11,value=io.systemd.credential.binary:firstboot.timezone=RXVyb3BlL0Jlcmxpbg== -smbios type=11,value=io.systemd.credential.binary:ssh.authorized_keys.root=c3NoLXJzYSBBQUFBQjNOemFDMXljMkVBQUFBREFRQUJBQUFCQVFDdXRWbWo5OXFVOVVMVWpIYVpmczNOVk53OXRFNWNoc0tmUUpUZ0s5SU9EdGt0aTYxTzZQNXpHRTZMWDh4bm5CWmhqSU5HV0gzYjlMbkh4QUNYVEYycksrTUFSSlpGV1BaZWlQRUNISHVnekJFVFYxMEMzTTRjZmcrdy9ZdlhmLzAvampDdEw4akFmOGdTSzVUaENRNERJOENBUCsraGFyN2hhUGxFSG45YXphWDJPYVJFSDU5aUZ0ZjFEdmkybjJ5TkdibGhKbityRVpMMThYVDFDTnZsMG91TVlRMndPaWdsY3IyL0N5amlkVDZSdU91Ky9zbE83bHRDV05YejdxcVJtNDRZbTBHYU9VekxUV09BSXkxOGx2YWphdEUyN1N4YlJHVnZqaTY2aytvZ2RPRmxKUHl5dlhrckExaS96ZXl6WjMxcTRzQ0FhMmIvUnZQMHRSeUg= -smbios type=11,value=io.systemd.credential.binary:fstab.extra=c2hhcmUgL3Jvb3Qvc2hhcmUgdmlydGlvZnMgeC1pbml0cmQubW91bnQK -smbios type=11,value=io.systemd.credential.binary:vmm.notify_socket=dnNvY2stc3RyZWFtOjI6MjA3NDQxNDI5Ng== -append 'rw systemd.wants=network.target module_blacklist=vmw_vmci systemd.tty.term.hvc0=xterm-256color systemd.tty.columns.hvc0=167 systemd.tty.rows.hvc0=23 ip=enc0:any ip=enp0s1:any ip=enp0s2:any ip=host0:any ip=none loglevel=4 SYSTEMD_SULOGIN_FORCE=1 systemd.tty.term.console=xterm-256color systemd.tty.columns.console=167 systemd.tty.rows.console=23 console=hvc0 TERM=xterm-256color enforcing=0 rw systemd.ssh_auto=no init=/init root=root rootfstype=virtiofs systemd.mount-extra=LABEL=scratch:/var/tmp:ext4'
The text was updated successfully, but these errors were encountered: