-
-
Notifications
You must be signed in to change notification settings - Fork 216
New issue
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
On Void Linux: QEMU failed to run feature checks / Failed creating instance record. #475
Comments
Just got to do some quick tests. To get VMs working on Void, I had to:
|
Worth noting that I figured out what was going on by looking at the Incus log file as that's where we log early startup errors. In this case, we were showing:
|
Thanks, Stéphane, for tracking that down. I was looking into edk2 as a source but overlooked putting --debug on the incus daemon. Is that logging output only available from incusd --debug? ; would it be possible to include it in the client --debug or --verbose? May help resolve things for others down the road. I'll update the Void incus package accordingly. |
I didn't have to run |
We do indeed log to Regarding Would it be possible to add a configuration option for this so instances can be specified with different paths to the OVMF files? |
Incus only supports running the native architecture anyway, we don't do support architecture emulation. So as long as you set INCUS_OVMF_PATH to point to the host architecture path, it'll be fine. |
Hi all, That fix can't be applied (or I do not know how) on a RaspberryPi4 since VoidLinux doesn't have edk2-ovmf package for aarch64 platform, so I switched to Fedora which provides such package and it looks like the right environment in incusd.service as well. To setup it I followed the section 'Start your first virtual machine' here, but i got the the same error. This is a very low priority issue, I was dealing with my RPI4, Let me know if i can help anyway My regards |
@stgraber Sorry for bumping this, but in updating incus to 6.4 on Void, now for me |
Also, for secure boot, the files are named like
Is there a way to make incus use them? |
Probably won't get to look into this much until October, I've got a bunch of things to do for 6.5 next week and then traveling most of September. You should look at the console For the paths, you can send a PR to update https://github.com/lxc/incus/blob/main/internal/server/instance/drivers/edk2/driver_edk2.go#L36 to match the paths on Void. Note that you need both the firmware (CODE) and data (VARS). |
Note that in this case
until reboot.) Not sure it is relevant, but the same command (without daemonize) gives
From /run/incus/user-1000_v1/qemu.conf
|
So looks like everything is fine on the Incus side, we started QEMU with the firmware from your distribution, things then got stuck there which could indicate a broken EDK2 firmware or something wrong with the VM image. |
Thanks for clarifying. Indeed incus stop -f works fine.
This is with alpine/edge vm:
BdsDxe: loading Boot0001 "UEFI QEMU QEMU HARDDISK " from PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/Scsi(0x0,0x1)
BdsDxe: starting Boot0001 "UEFI QEMU QEMU HARDDISK " from PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/Scsi(0x0,0x1)
Booting `Alpine Linux v3.19'
Loading Linux virt ...
Loading initial ramdisk ...
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
I can try downgrading the ed2k package, but is it possible that something
changed in incus? if so, do you have a guess which version of incus to
try and downgrade to? or can you still get to exec a shell with v6.4?
|
Ah, downgrading edk2-ovmf to 202311 lets the vm start. |
Will inquire with Void then. |
I'm trying to patch incus to find void edk2 stuff. |
see #1170 |
While creating a PR for the Void Linux project to update
incus
on void-packagesto v0.5.1, I discovered an issue that has been present in lxd and in incus from the current shipping version on Void, 0.4.0. I note a few similar reports on other distributions over the last few months.Required information
Issue description
Attempt to create a VM instance - any VM - fails.
No detailed logging information is provided beyond that, even in --debug mode or in
incus monitor
. It would help if theactual error were reported. It appears that OVMF is being located, btw.
Steps to reproduce
incus launch
per the issue description; multiple images/different distributions checked.Information to attach
dmesg
)None available.
incus info NAME --show-log
)None created
incus config show NAME --expanded
)None created
None available.
incus monitor --pretty
while reproducing the issue)The text was updated successfully, but these errors were encountered: