Since it looks like LXC won't be updated for 15.0, I changed my package building system from LXC to qemu/kvm. A particular advantage (over a change to VBox) is the ability to specify an "external" kernel & initrd i.e. a kernel and initrd not part of the VM image itself, rather just files in the host filesystem. This brings with it the ability to pass kernel arguments (such as a list of packages to build) when the VM image is launched via an -append entry e.g.
When the VM runs, it extracts the package list from /proc/cmdline, builds whatever is needed and dumps the result in a known location in the host file system.

That has all worked quite well for a few months now but recent discussion about secure boot led me to revisit booting these VM's with UEFI. Not that there's a particular need; I'm just interested. So I've installed the system/ovmf SBo package (actually a 2021 version, not the 2019 version specified in the repo) and following the required day of googling & fiddling around, I'm now able to boot the VM's under UEFI provided they use the internal kernel & initrd i.e. those in the VM image itself, not the external ones. Therefore my ability to pass kernel arguments no longer exists.

So, hoping someone has passed this way before, the question is how to pass extra information to a VM when it boots under UEFI?

Thanks for any suggestions,
chris

No issue here with this command:the kernel and initrd are loaded, the system starts and /proc/cmdline is as expected.

Thanks for looking at it Didier. That (using kernel & initrd located in regular /boot) doesn't work for me. I suspect it's because if I specify root=/dev/sda2 (as it is in the VM) then I see an error that /dev/sda2 doesn't exist. Although it's true that there is no /dev/sda2 in the host system, I want the VM to mount /dev/sda2 of the VM, not the host.

chris

More info:
all the errors about not mounting /dev/sd* are because no disk partitions at all are visible in the environment that I'm dumped to when booting fails. The initrd has run because I see modules loading after "Loading kernel modules from initrd image" and running "ls -l" in the resulting shell shows the contents the initrd.

/proc/partitions contains only ram0-ram15 and fd0. Why no disk partitions available I wonder?

This document is as dry as burnt toast, but it does contain
Perhaps UUID specification would help?

Maybe because the script /init in the in initrd didn't run udev for some reason although that looks weird (I won't assume an issue with the SD SCSI disk driver). Did you try to set as argument of the -initrd option a copy of the initrd you installed in the VM?

I attach the init script I include in the initrds (same as in Slackware only support for a LUKS key in the initrd added).

PS Else you also could use as argument of -kernel a "huge" kernel (the -append option only needs to also set the -kernel option, the -initrd option is optional).

PPS You can also include in the init script commands helping to investigate like "echo" for the values of variables and "read" or "sleep'" to give you time to read them. Been there, did that.

Attached Files

init.txt (12.7 KB, 31 views)

Yes, I tried that when I thought there could be confusion between device paths in the VM and the host (before I realized that no device paths at all from either VM or host were being discovered).


Yes, when I updated the VM's kernel and initrd for 5.12.14, I copied them into the host file system. It's only when I try to run the VM with those copies in the host that the problem occurs. They seem to run (I can see modules from initrd being installed) but they don't seem to access the VM itself.

I installed it in a new initrd and saw (when dumped in the shell after finding no devices) that it's quite similar to the init already there. I tried a few of the udev commands in there - even re-ran the whole script - but no change

I tried the huge kernel without initrd but it had a panic with message . Running huge kernel with the initrd was almost same as generic + initrd; just modules couldn't be loaded (already in kernel).

Well I think the problem is before the init script is run (huge kernel's message about unknown-block(0,0)) but was surprised that dmesg and less commands are supported in the initrd shell. Unfortunately "dmesg|less" showed no errors until initrd's init ran almost to the end until "No /sbin/init found on rootdev (or not mounted). Trouble ahead."

Shot in the dark: in Slint the initrd and kernel are not copied in the ESP, as GRUB's OS loader includes the needed file system modules to find them in /boot. Could that make a difference?

PS if everything else fails, install Slint to compare. If you choose the 'auto' mode this won't take more than 20 minutes (preferably when connected to the Internet so you won't have to upgrade or get new packages after installation). Qemu is included. GPG-KEY

1 members found this post helpful.

In this instance, I'm not sure (although I just tried it and it made no difference). In any case, the whole point of this particular exercise is to boot with kernel & initrd which are not contained in the VM itself. Or do you mean ESP of host system?

A reinstalation made me wonder how you set up your system - did you convert an existing VM to use UEFI, or did you create the VM under UEFI (OVMF)?

chris

I had in mind the host system, but maybe the VM matters too, although I don't know why it would. Just trying to find something that differs between our contexts. Anyway later today I will try with host Slint and VM Slackware as well as host Slackware and VM Slint.

So that I can reproduce please tell what is your host (Slackware64-current? Slackware64-14.2?) and how it boots: elilo? lilo? grub? In EFI or Legacy mode? And does the VM boots using elilo or grub?

Well, I just change the virtual firmware whenever needed, including or not these lines in the command:
In my understanding OVMF_CODE-pure-efi.fd is the firmware itself, my_uefi_vars.bin stores the EFI variables, like the boot entries of the firmware. This illustrated by the fact that if I change the virtual disk the firmware's boot menu remains as before (displayed with the Qemu option -boot-menu=on, of course).

Thanks for taking the time. My host Slackware64-current boots with grub in UEFI mode. The VM boots with grub although it was generally not previously used since I was booting from external kernel/initrd. It's only since adding the ovmf lines to the qemu script that it won't boot with external kernel/initrd (but will boot via VM's grub if I remove kernel/append/initrd lines from the script.

Yes, I use (almost) the same lines:
Adding those lines to an existing qemu script is what I meant by "converting an existing VM".

chris

I did this:

1. Install Slackware64-current (ISO built from an up to date local mirror) in a Qemu VM, host Slint64-14.2.1 up to date, Qemu version 6.0.0, install neither lilo nor elilo
2. Start Slackware using the last entry of the GRUB menu "detect and start all OS" (yes I forgot to chroot to install GRUB before rebooting the VM), ran grub-install && grub-mkconfig -o /boot/grub/grub.cfg
3. Shutdown Slackware in the VM.
4. Edit the script to start the VM:
   Code:

   #!/bin/sh
   qemu-system-x86_64 \
   -enable-kvm \
   -cpu host \
   -boot order=c \
   -m 4G \
   -kernel /boot/vmlinuz-generic-5.12.11 \
   -initrd /boot/initrd-generic-5.12.11 \
   -append "root=/dev/sda2 ro TITI=toto" \
   -device intel-hda \
   -device hda-duplex \
   -display gtk \
   -vga std \
   -fsdev local,id=vmslack,path=slackbuilds,security_model=none \
   -device virtio-9p-pci,fsdev=vmslack,mount_tag=SBo \
   -drive file=/data/images_iso/slackware64-current.qcow2,format=qcow2,media=disk \
   -drive if=pflash,format=raw,readonly,file=OVMF_CODE-pure-efi.fd \
   -drive if=pflash,format=raw,file=my_uefi_vars.bin \
   -cdrom /data/images_iso/slackware64-current.iso

5. Run the script.

Success: Slackware is running the external kernel (internal version is 5.12.15), and cat /proc/cmdline gives:Next, I will build Qemu in Slackware-current and experiment using the same VM but in a Slackware64-current host. Stay tuned.

The root partition is /dev/sda2 in the VM, /dev/sda3 in the host.

EDIT.

Also tried to run the script on an up to date Slackware64-current host (only changed the kernel version, now 5.12.15). Success.

In Slackware I rename the initrd built running geninitrd as initrd-generic-<kernel version> to make os-prober happy, but I doubt that matters. Do you use the same Qemu version (6.0.0)? Else you will find a package just built on Slackware64-current here.

A plain "grub-install", or "grub-install --efi-directory= ... ..."? i.e. without or with an ESP in the VM?

chris

A plain grub-install. As there is a mounted ESP in the VM GRUB automatically selects the x86_64-efi platform, puts the OS loader in the ESP and by default writes a boot entry in the firmware's boot menu.

PS I edited my previous post after you answered it.

OK thanks, I think I'll try building a new VM later today and see how that goes.

chris