[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
Both the 18.04 & 16.04 Ubuntu Minimal cloud images use the kvm kernel by default, so we need this fix applied to those kernels as well. Are there plans for that so that we can use those Minimal images in LXD? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Fix Released Status in linux-kvm source package in Focal: Fix Released Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR - 3FBEEA98 0047, LDTR
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
This bug was fixed in the package linux-kvm - 5.4.0-1020.20 --- linux-kvm (5.4.0-1020.20) focal; urgency=medium * focal/linux-kvm: 5.4.0-1020.20 -proposed tracker (LP: #1887063) [ Ubuntu: 5.4.0-42.46 ] * focal/linux: 5.4.0-42.46 -proposed tracker (LP: #1887069) * linux 4.15.0-109-generic network DoS regression vs -108 (LP: #1886668) - SAUCE: Revert "netprio_cgroup: Fix unlimited memory leak of v2 cgroups" linux-kvm (5.4.0-1019.19) focal; urgency=medium * focal/linux-kvm: 5.4.0-1019.19 -proposed tracker (LP: #1885848) [ Ubuntu: 5.4.0-41.45 ] * focal/linux: 5.4.0-41.45 -proposed tracker (LP: #1885855) * Packaging resync (LP: #1786013) - update dkms package versions * CVE-2019-19642 - kernel/relay.c: handle alloc_percpu returning NULL in relay_open * CVE-2019-16089 - SAUCE: nbd_genl_status: null check for nla_nest_start * CVE-2020-11935 - aufs: do not call i_readcount_inc() * ip_defrag.sh in net from ubuntu_kernel_selftests failed with 5.0 / 5.3 / 5.4 kernel (LP: #1826848) - selftests: net: ip_defrag: ignore EPERM * Update lockdown patches (LP: #1884159) - SAUCE: acpi: disallow loading configfs acpi tables when locked down * seccomp_bpf fails on powerpc (LP: #1885757) - SAUCE: selftests/seccomp: fix ptrace tests on powerpc * Introduce the new NVIDIA 418-server and 440-server series, and update the current NVIDIA drivers (LP: #1881137) - [packaging] add signed modules for the 418-server and the 440-server flavours [ Ubuntu: 5.4.0-40.44 ] * linux-oem-5.6-tools-common and -tools-host should be dropped (LP: #1881120) - [Packaging] Add Conflicts/Replaces to remove linux-oem-5.6-tools-common and -tools-host * Packaging resync (LP: #1786013) - [Packaging] update helper scripts * Slow send speed with Intel I219-V on Ubuntu 18.04.1 (LP: #1802691) - e1000e: Disable TSO for buffer overrun workaround * CVE-2020-0543 - UBUNTU/SAUCE: x86/speculation/srbds: do not try to turn mitigation off when not supported * Realtek 8723DE [10ec:d723] subsystem [10ec:d738] disconnects unsolicitedly when Bluetooth is paired: Reason: 23=IEEE8021X_FAILED (LP: #1878147) - SAUCE: Revert "UBUNTU: SAUCE: rtw88: Move driver IQK to set channel before association for 11N chip" - SAUCE: Revert "UBUNTU: SAUCE: rtw88: fix rate for a while after being connected" - SAUCE: Revert "UBUNTU: SAUCE: rtw88: No retry and report for auth and assoc" - SAUCE: Revert "UBUNTU: SAUCE: rtw88: 8723d: Add coex support" - rtw88: add a debugfs entry to dump coex's info - rtw88: add a debugfs entry to enable/disable coex mechanism - rtw88: 8723d: Add coex support - SAUCE: rtw88: coex: 8723d: set antanna control owner - SAUCE: rtw88: coex: 8723d: handle BT inquiry cases - SAUCE: rtw88: fix EAPOL 4-way failure by finish IQK earlier * CPU stress test fails with focal kernel (LP: #1867900) - [Config] Disable hisi_sec2 temporarily * Enforce all config annotations (LP: #1879327) - [Config]: do not enforce CONFIG_VERSION_SIGNATURE - [Config]: prepare to enforce all - [Config]: enforce all config options * Focal update: v5.4.44 upstream stable release (LP: #1881927) - ax25: fix setsockopt(SO_BINDTODEVICE) - dpaa_eth: fix usage as DSA master, try 3 - net: don't return invalid table id error when we fall back to PF_UNSPEC - net: dsa: mt7530: fix roaming from DSA user ports - net: ethernet: ti: cpsw: fix ASSERT_RTNL() warning during suspend - __netif_receive_skb_core: pass skb by reference - net: inet_csk: Fix so_reuseport bind-address cache in tb->fast* - net: ipip: fix wrong address family in init error path - net/mlx5: Add command entry handling completion - net: mvpp2: fix RX hashing for non-10G ports - net: nlmsg_cancel() if put fails for nhmsg - net: qrtr: Fix passing invalid reference to qrtr_local_enqueue() - net: revert "net: get rid of an signed integer overflow in ip_idents_reserve()" - net sched: fix reporting the first-time use timestamp - net/tls: fix race condition causing kernel panic - nexthop: Fix attribute checking for groups - r8152: support additional Microsoft Surface Ethernet Adapter variant - sctp: Don't add the shutdown timer if its already been added - sctp: Start shutdown on association restart if in SHUTDOWN-SENT state and socket is closed - tipc: block BH before using dst_cache - net/mlx5e: kTLS, Destroy key object after destroying the TIS - net/mlx5e: Fix inner tirs handling - net/mlx5: Fix memory leak in mlx5_events_init - net/mlx5e: Update netdev txq on completions during closure - net/mlx5: Fix error flow in case of function_setup failure - net/mlx5: Annotate mutex destroy for root ns - net/tls: fix encryption error checking - net/tls: free record only on encryption error - net: sun: fix missing release
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
We weren't planning to as the previous releases (xenial and bionic) did not have "-kvm" image and their default image includes an initrd making them boot just fine under LXD. So it's really just groovy+focal that we need before we can start using those images. focal has been taken care of so we're just waiting for linux-kvm to hit the release pocket on groovy before we can switch over to those. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Released Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
Hey all, will we get backports of this to previous releases? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Released Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR - 3FBEEA98 0047, LDTR - IDTR - 3F2D8018 0FFF, TR - FXSAVE_STATE - 3FF1C290 Find image based on
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
This bug was fixed in the package linux-kvm - 5.4.0-1018.18 --- linux-kvm (5.4.0-1018.18) focal; urgency=medium * focal/linux-kvm: 5.4.0-1018.18 -proposed tracker (LP: #1885099) * LXD 4.2 broken on linux-kvm due to missing VLAN filtering (LP: #1882955) - [Config] kvm: VLAN_8021Q=m && BRIDGE_VLAN_FILTERING=y * Make linux-kvm bootable in LXD VMs (LP: #1873809) - [Config] kvm: Match ramdisk config with master - [Config] kvm: Build-in EFI framebuffer linux-kvm (5.4.0-1017.17) focal; urgency=medium * focal/linux-kvm: 5.4.0-1017.17 -proposed tracker (LP: #1883517) * Make linux-kvm bootable in LXD VMs (LP: #1873809) - [Packaging] Start to sign the KVM kernel linux-kvm (5.4.0-1016.16) focal; urgency=medium * focal/linux-kvm: 5.4.0-1016.16 -proposed tracker (LP: #1882691) * Focal update: v5.4.42 upstream stable release (LP: #1879759) - [Config] kvm: Record CC_HAS_WARN_MAYBE_UNINITIALIZED drop * Packaging resync (LP: #1786013) - [Packaging] update helper scripts [ Ubuntu: 5.4.0-38.42 ] * CVE-2020-0543 - UBUNTU/SAUCE: x86/speculation/srbds: do not try to turn mitigation off when not supported * Realtek 8723DE [10ec:d723] subsystem [10ec:d738] disconnects unsolicitedly when Bluetooth is paired: Reason: 23=IEEE8021X_FAILED (LP: #1878147) - SAUCE: Revert "UBUNTU: SAUCE: rtw88: Move driver IQK to set channel before association for 11N chip" - SAUCE: Revert "UBUNTU: SAUCE: rtw88: fix rate for a while after being connected" - SAUCE: Revert "UBUNTU: SAUCE: rtw88: No retry and report for auth and assoc" - SAUCE: Revert "UBUNTU: SAUCE: rtw88: 8723d: Add coex support" - rtw88: add a debugfs entry to dump coex's info - rtw88: add a debugfs entry to enable/disable coex mechanism - rtw88: 8723d: Add coex support - SAUCE: rtw88: coex: 8723d: set antanna control owner - SAUCE: rtw88: coex: 8723d: handle BT inquiry cases - SAUCE: rtw88: fix EAPOL 4-way failure by finish IQK earlier * CPU stress test fails with focal kernel (LP: #1867900) - [Config] Disable hisi_sec2 temporarily * Enforce all config annotations (LP: #1879327) - [Config]: do not enforce CONFIG_VERSION_SIGNATURE - [Config]: prepare to enforce all - [Config]: enforce all config options * Focal update: v5.4.44 upstream stable release (LP: #1881927) - ax25: fix setsockopt(SO_BINDTODEVICE) - dpaa_eth: fix usage as DSA master, try 3 - net: don't return invalid table id error when we fall back to PF_UNSPEC - net: dsa: mt7530: fix roaming from DSA user ports - net: ethernet: ti: cpsw: fix ASSERT_RTNL() warning during suspend - __netif_receive_skb_core: pass skb by reference - net: inet_csk: Fix so_reuseport bind-address cache in tb->fast* - net: ipip: fix wrong address family in init error path - net/mlx5: Add command entry handling completion - net: mvpp2: fix RX hashing for non-10G ports - net: nlmsg_cancel() if put fails for nhmsg - net: qrtr: Fix passing invalid reference to qrtr_local_enqueue() - net: revert "net: get rid of an signed integer overflow in ip_idents_reserve()" - net sched: fix reporting the first-time use timestamp - net/tls: fix race condition causing kernel panic - nexthop: Fix attribute checking for groups - r8152: support additional Microsoft Surface Ethernet Adapter variant - sctp: Don't add the shutdown timer if its already been added - sctp: Start shutdown on association restart if in SHUTDOWN-SENT state and socket is closed - tipc: block BH before using dst_cache - net/mlx5e: kTLS, Destroy key object after destroying the TIS - net/mlx5e: Fix inner tirs handling - net/mlx5: Fix memory leak in mlx5_events_init - net/mlx5e: Update netdev txq on completions during closure - net/mlx5: Fix error flow in case of function_setup failure - net/mlx5: Annotate mutex destroy for root ns - net/tls: fix encryption error checking - net/tls: free record only on encryption error - net: sun: fix missing release regions in cas_init_one(). - net/mlx4_core: fix a memory leak bug. - mlxsw: spectrum: Fix use-after-free of split/unsplit/type_set in case reload fails - ARM: dts: rockchip: fix phy nodename for rk3228-evb - ARM: dts: rockchip: fix phy nodename for rk3229-xms6 - arm64: dts: rockchip: fix status for in rk3328-evb.dts - arm64: dts: rockchip: swap interrupts interrupt-names rk3399 gpu node - ARM: dts: rockchip: swap clock-names of gpu nodes - ARM: dts: rockchip: fix pinctrl sub nodename for spi in rk322x.dtsi - gpio: tegra: mask GPIO IRQs during IRQ shutdown - ALSA: usb-audio: add mapping for ASRock TRX40 Creator - net: microchip: encx24j600: add missed kthread_stop - gfs2: move privileged user check to gfs2_quota_lock_check - gfs2: Grab glock reference sooner in gfs2_add_revoke - drm/amdgpu: drop unnecessary
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
@Stéphane, right now (and that might be for a while still) the linux-kvm kernel in Groovy is a copy-forward from Focal. So once this releases, you should be able to use it there as well. I started to have annotated config enforcement for the adjusted config which hopefully will survive when the specific kvm kernel for Groovy gets started. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Committed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
Confirmed, 1018 boots fine here under Secure Boot, all good! ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Committed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR - 3FBEEA98 0047, LDTR - IDTR - 3F2D8018 0FFF, TR -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
@smb what's the state of groovy, did you push the config update there too? For the cloud images, we'll want to switch over to those using linux-kvm in groovy first, then focal, so just want to make sure we'll get a working kernel on there too! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Committed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
Note that for me the latest kernel works past the decoding failed stage. But it would be good to have a second verification is possible. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Committed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR - 3FBEEA98 0047, LDTR - IDTR - 3F2D8018 0FFF, TR -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
Latest version: 5.4.0-1018-kvm This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- focal' to 'verification-done-focal'. If the problem still exists, change the tag 'verification-needed-focal' to 'verification-failed-focal'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags removed: verification-failed-focal ** Tags added: verification-needed-focal -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Committed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
Alright, at least partially understanding things now. So it looks like "Decoding failed" happens generally on some platforms (and I do not understand still why this is). The difference between the generic kernel and the kvm kernel is that the kvm kernel has a built-in BLK_DEV_RAM of size (4096) whereas the generic kernel uses a module for that. It looks like only if BLK_DEV_RAM=y is set, the code which populates the initial rootfs does try to flush and refill the ramdisk device. Otherwise the partially expanded rootfs is retained. And I guess the ramdisk size is set to small so we get the incomplete write there. I guess the solution (which does not solve the decode failure) is to change the kvm kernel config to BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_SIZE=65536 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Committed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
Ok, so with the same software versions installed but on a different hw platform, I did at least once get this incomplete write error. The working box is an AMD/BIOS one and the non-working an Intel/EFI. Not sure why that has any impact. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Committed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR - 3FBEEA98
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
Hm, and maybe also relevant: what kind of pool is used? My setup was "lxd init --auto" which is a file based image backend. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Committed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR - 3FBEEA98 0047, LDTR - IDTR - 3F2D8018 0FFF, TR -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
@Stéphane, I have now followed your steps from commant #38 (was using the official ubuntu image before with cloud-init and that does a initrd-less boot first which is successful for me) but this does not show me the error you see either. And a break=top does work (with some complaints about tty1 which is expected due to the missing efi-fb). I double-checked the initramfs compression setting and that is lz4. This is rather weird. I will try on a different hw but that really should not be relevant. For double checking: which LXD version are you using? I am on the focal/stable/4.0 stream: lxd4.0.115682 4.0/stable/… canonical✓ - -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Committed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
It's not the log above clearly shows the kernel loading an initrd. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Committed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR - 3FBEEA98 0047, LDTR - IDTR - 3F2D8018 0FFF, TR - FXSAVE_STATE - 3FF1C290 Find image based
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
I'm not sure if it's related, but maybe worth the mention: could this be due to the initrd-less boot? I've noticed that in some VMs, it first fails to boot (it tries an initrd-less boot), reboots and then loads the initrd. This is an Ubuntu grub-thing, and you can prevent that by deleting a file *40*partuuid* form /etc/default/grub.d/ (need to recreate grub config file after that). Cheers, Guilherme -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Committed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
""" stgraber@castiana:~$ lxc launch images:ubuntu/focal f1 --vm Creating f1 Starting f1 stgraber@castiana:~$ lxc exec f1 bash root@f1:~# echo "deb http://archive.ubuntu.com/ubuntu focal-proposed main restricted universe multiverse" >> /etc/apt/sources.list root@f1:~# apt-get update Hit:1 http://archive.ubuntu.com/ubuntu focal InRelease Get:2 http://archive.ubuntu.com/ubuntu focal-updates InRelease [107 kB] Get:3 http://security.ubuntu.com/ubuntu focal-security InRelease [107 kB] Get:4 http://archive.ubuntu.com/ubuntu focal-proposed InRelease [265 kB] Get:5 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages [201 kB] Get:6 http://archive.ubuntu.com/ubuntu focal-updates/main Translation-en [80.2 kB] Get:7 http://archive.ubuntu.com/ubuntu focal-updates/restricted amd64 Packages [11.1 kB] Get:8 http://archive.ubuntu.com/ubuntu focal-updates/restricted Translation-en [3036 B] Get:9 http://archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages [114 kB] Get:10 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages [82.4 kB] Get:11 http://archive.ubuntu.com/ubuntu focal-proposed/main Translation-en [35.0 kB] Get:12 http://archive.ubuntu.com/ubuntu focal-proposed/restricted amd64 Packages [7132 B] Get:13 http://archive.ubuntu.com/ubuntu focal-proposed/restricted Translation-en [2144 B] Get:14 http://archive.ubuntu.com/ubuntu focal-proposed/universe amd64 Packages [35.8 kB] Get:15 http://archive.ubuntu.com/ubuntu focal-proposed/universe Translation-en [24.5 kB] Get:16 http://archive.ubuntu.com/ubuntu focal-proposed/multiverse Translation-en [3404 B] Fetched 1079 kB in 1s (794 kB/s) Reading package lists... Done root@f1:~# apt-get install linux-kvm Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: linux-headers-5.4.0-1017-kvm linux-headers-kvm linux-image-5.4.0-1017-kvm linux-image-kvm linux-kvm-headers-5.4.0-1017 linux-modules-5.4.0-1017-kvm Suggested packages: fdutils linux-kvm-doc-5.4.0 | linux-kvm-source-5.4.0 linux-kvm-tools The following NEW packages will be installed: linux-headers-5.4.0-1017-kvm linux-headers-kvm linux-image-5.4.0-1017-kvm linux-image-kvm linux-kvm linux-kvm-headers-5.4.0-1017 linux-modules-5.4.0-1017-kvm 0 upgraded, 7 newly installed, 0 to remove and 18 not upgraded. Need to get 28.4 MB of archives. After this operation, 126 MB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 linux-kvm-headers-5.4.0-1017 all 5.4.0-1017.17 [11.3 MB] Get:2 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 linux-headers-5.4.0-1017-kvm amd64 5.4.0-1017.17 [1254 kB] Get:3 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 linux-headers-kvm amd64 5.4.0.1017.16 [4376 B] Get:4 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 linux-modules-5.4.0-1017-kvm amd64 5.4.0-1017.17 [10.6 MB] Get:5 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 linux-image-5.4.0-1017-kvm amd64 5.4.0-1017.17 [5158 kB] Get:6 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 linux-image-kvm amd64 5.4.0.1017.16 [ B] Get:7 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 linux-kvm amd64 5.4.0.1017.16 [4416 B] Fetched 28.4 MB in 2s (14.2 MB/s) Selecting previously unselected package linux-kvm-headers-5.4.0-1017. (Reading database ... 46372 files and directories currently installed.) Preparing to unpack .../0-linux-kvm-headers-5.4.0-1017_5.4.0-1017.17_all.deb ... Unpacking linux-kvm-headers-5.4.0-1017 (5.4.0-1017.17) ... Selecting previously unselected package linux-headers-5.4.0-1017-kvm. Preparing to unpack .../1-linux-headers-5.4.0-1017-kvm_5.4.0-1017.17_amd64.deb ... Unpacking linux-headers-5.4.0-1017-kvm (5.4.0-1017.17) ... Selecting previously unselected package linux-headers-kvm. Preparing to unpack .../2-linux-headers-kvm_5.4.0.1017.16_amd64.deb ... Unpacking linux-headers-kvm (5.4.0.1017.16) ... Selecting previously unselected package linux-modules-5.4.0-1017-kvm. Preparing to unpack .../3-linux-modules-5.4.0-1017-kvm_5.4.0-1017.17_amd64.deb ... Unpacking linux-modules-5.4.0-1017-kvm (5.4.0-1017.17) ... Selecting previously unselected package linux-image-5.4.0-1017-kvm. Preparing to unpack .../4-linux-image-5.4.0-1017-kvm_5.4.0-1017.17_amd64.deb ... Unpacking linux-image-5.4.0-1017-kvm (5.4.0-1017.17) ... Selecting previously unselected package linux-image-kvm. Preparing to unpack .../5-linux-image-kvm_5.4.0.1017.16_amd64.deb ... Unpacking linux-image-kvm (5.4.0.1017.16) ... Selecting previously unselected package linux-kvm. Preparing to unpack .../6-linux-kvm_5.4.0.1017.16_amd64.deb ... Unpacking linux-kvm (5.4.0.1017.16) ... Setting up linux-kvm-headers-5.4.0-1017 (5.4.0-1017.17) ... Setting up linux-modules-5.4.0-1017-kvm (5.4.0-1017.17) ... Setting up linux-headers-5.4.0-1017-kvm
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
https://paste.ubuntu.com/p/7yHDCFt75m/ for additional proof that the initrd is never executed (break=top would immediately drop to a shell). -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Committed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR - 3FBEEA98 0047, LDTR - IDTR - 3F2D8018 0FFF, TR -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
@smb Can you confirm that your system indeed goes through the initrd and isn't just silently falling back to directly mounting and booting /? Booting with break=mount would likely be a valid way to test this (should drop you in a shell). -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Committed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
Hmm, actually no luck at booting either 1015 or 1017 on security.secureboot=false here, poked at grub and it does load both kernel and initrd... -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Committed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR - 3FBEEA98 0047, LDTR - IDTR - 3F2D8018 0FFF, TR
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
""" Loading Linux 5.4.0-1015-kvm ... Loading initial ramdisk ... Linux version 5.4.0-1015-kvm (buildd@lcy01-amd64-027) (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) #15-Ubuntu SMP Fri Jun 5 00:55:20 UTC 2020 (Ubuntu 5.4.0-1015.15-kvm 5.4.41) Command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-1015-kvm root=UUID=03167f19-fb7f-4ba9-b4da-5e4acc0d97e3 ro single nomodeset x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64 x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64 x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format. BIOS-provided physical RAM map: BIOS-e820: [mem 0x-0x0009] usable BIOS-e820: [mem 0x0010-0x3ee6afff] usable BIOS-e820: [mem 0x3ee6b000-0x3ef2bfff] reserved BIOS-e820: [mem 0x3ef2c000-0x3f8eefff] usable BIOS-e820: [mem 0x3f8ef000-0x3faeefff] reserved BIOS-e820: [mem 0x3faef000-0x3fb75fff] usable BIOS-e820: [mem 0x3fb76000-0x3fb7efff] ACPI data BIOS-e820: [mem 0x3fb7f000-0x3fbfefff] ACPI NVS BIOS-e820: [mem 0x3fbff000-0x3ffd] usable BIOS-e820: [mem 0x3ffe-0x3fff] reserved BIOS-e820: [mem 0xb000-0xbfff] reserved BIOS-e820: [mem 0xffe0-0x] reserved NX (Execute Disable) protection: active extended physical RAM map: reserve setup_data: [mem 0x-0x0009] usable reserve setup_data: [mem 0x0010-0x3df4b017] usable reserve setup_data: [mem 0x3df4b018-0x3df86457] usable reserve setup_data: [mem 0x3df86458-0x3df87017] usable reserve setup_data: [mem 0x3df87018-0x3df90a57] usable reserve setup_data: [mem 0x3df90a58-0x3ee6afff] usable reserve setup_data: [mem 0x3ee6b000-0x3ef2bfff] reserved reserve setup_data: [mem 0x3ef2c000-0x3f8eefff] usable reserve setup_data: [mem 0x3f8ef000-0x3faeefff] reserved reserve setup_data: [mem 0x3faef000-0x3fb75fff] usable reserve setup_data: [mem 0x3fb76000-0x3fb7efff] ACPI data reserve setup_data: [mem 0x3fb7f000-0x3fbfefff] ACPI NVS reserve setup_data: [mem 0x3fbff000-0x3ffd] usable reserve setup_data: [mem 0x3ffe-0x3fff] reserved reserve setup_data: [mem 0xb000-0xbfff] reserved reserve setup_data: [mem 0xffe0-0x] reserved efi: EFI v2.70 by EDK II efi: SMBIOS=0x3f915000 ACPI=0x3fb7e000 ACPI 2.0=0x3fb7e014 MEMATTR=0x3e115118 secureboot: Secure boot disabled SMBIOS 2.8 present. DMI: QEMU Standard PC (Q35 + ICH9, 2009)/LXD, BIOS 0.0.0 02/06/2015 Hypervisor detected: KVM kvm-clock: Using msrs 4b564d01 and 4b564d00 kvm-clock: cpu 0, msr 14630001, primary cpu clock kvm-clock: using sched offset of 4626558194 cycles clocksource: kvm-clock: mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns tsc: Detected 2712.000 MHz processor last_pfn = 0x3ffe0 max_arch_pfn = 0x4 x86/PAT: Configuration [0-7]: WB WT UC- UC WB WT UC- UC Using GB pages for direct mapping secureboot: Secure boot disabled RAMDISK: [mem 0x2c111000-0x2cbadfff] ACPI: Early table checksum verification disabled ACPI: RSDP 0x3FB7E014 24 (v02 BOCHS ) ACPI: XSDT 0x3FB7D0E8 4C (v01 BOCHS BXPCFACP 0001 0113) ACPI: FACP 0x3FB7A000 F4 (v03 BOCHS BXPCFACP 0001 BXPC 0001) ACPI: DSDT 0x3FB7B000 001E86 (v01 BOCHS BXPCDSDT 0001 BXPC 0001) ACPI: FACS 0x3FBDD000 40 ACPI: APIC 0x3FB79000 78 (v01 BOCHS BXPCAPIC 0001 BXPC 0001) ACPI: HPET 0x3FB78000 38 (v01 BOCHS BXPCHPET 0001 BXPC 0001) ACPI: MCFG 0x3FB77000 3C (v01 BOCHS BXPCMCFG 0001 BXPC 0001) ACPI: BGRT 0x3FB76000 38 (v01 INTEL EDK2 0002 0113) No NUMA configuration found Faking a node at [mem 0x-0x3ffd] NODE_DATA(0) allocated [mem 0x3ff8-0x3ff82fff] Zone ranges: DMA32[mem 0x1000-0x3ffd] Normal empty Movable zone start for each node Early memory node ranges node 0: [mem 0x1000-0x0009] node 0: [mem 0x0010-0x3ee6afff] node 0: [mem 0x3ef2c000-0x3f8eefff] node 0: [mem 0x3faef000-0x3fb75fff] node 0: [mem 0x3fbff000-0x3ffd] Zeroed struct page in
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
Yeah, I think you're right, I also had the exact same panic happen now on 1015, so it's likely some grub weirdness rather than kernel regression. It just so happened that in my last test I managed to get a working grub config after moving to 1015 and not with 1017. Looks like we'll need to poke at grub... -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Committed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - ,
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
@Stéphane, the uncompress message appears to be something that may happen if blocks are not aligned but not harming anything. By now I have played around with both a self created secureboot VM on bionic and also (following your turorial) a LXD 4.0 vM. And for both I could not repeat what you saw. Both booted. There is a minor issue for people creating their own VMs and using a graphical interface (like virt-manager). The kvm kernel has no framebuffer devices enabled so one does not see anything if one does not enable a serial console. For LXD, when I repeated the steps from https://discuss.linuxcontainers.org/t/running-virtual-machines-with-lxd-4-0/7519 I saw one crash not finding the root disk after the initial lxc start when I ran lxc console. But that was with the generic kernel and that seems to be handled by the panic handler. Attaching to he console a second time I saw cloud-init finishing and then I installed the proposed kvm kernel in that running vm and rebooted. And this gave me a working boot: ubuntu@ubuntu:~$ uname -a Linux ubuntu 5.4.0-1017-kvm #17-Ubuntu SMP Mon Jun 15 13:05:31 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux ubuntu@ubuntu:~$ dmesg|grep secure [0.00] secureboot: Secure boot enabled [0.260090] secureboot: Secure boot enabled -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Committed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
@Stefan, so actually this is an actual regression. 1015 will boot just fine in LXD with secureboot disabled. 1017 will not boot at all in LXD with or without secureboot disabled. I don't know if it's switching to a signed kernel which causes the lz4 issue but the result is a clear regression so I would not consider this kernel suitable for release to anyone. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Committed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
@Stephane, if this bug was not phrased that generically I would feel inclined to say it verified ok if the kernel image can be booted in secureboot mode and has the requested config options set. And treat the initrd issue as a separate one on the path to completion. For us, I would propose to count this feedback as success (and still release the kernel that way if there is no other problems). -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Committed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
""" Jun 18 13:56:15 f1 kernel: [0.383207] Trying to unpack rootfs image as initramfs... Jun 18 13:56:15 f1 kernel: [0.463102] Initramfs unpacking failed: Decoding failed """ Is what we're getting on current generic kernel, though boot continues after that. I don't know if when that happens we're actually skipping the initrd entirely and just get lucky that the generic kernel has everything we need builtin so it boots or if the error in that case is just wrong and the initrd is still properly unpacked and run. Either way, this needs sorting, looking at the other bug report, there's been something wrong with our kernel and lz4 initrd for a long time and it's apparently biting us a lot more now. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Committed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
Trying to boot the proposed kernel in LXD: """ BdsDxe: loading Boot0007 "ubuntu" from HD(1,GPT,25633192-5DBD-412A-8A50-E29B79F72A50,0x800,0x32000)/\EFI\ubuntu\shimx64.efi BdsDxe: starting Boot0007 "ubuntu" from HD(1,GPT,25633192-5DBD-412A-8A50-E29B79F72A50,0x800,0x32000)/\EFI\ubuntu\shimx64.efi RAMDISK: incomplete write (4194304 != 8388608) Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.0-1017-kvm #17-Ubuntu Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)/LXD, BIOS 0.0.0 02/06/2015 Call Trace: 0x9392230d 0x932a8a21 0x9412e5c1 0x9412e80f 0x9412e976 0x9412e274 ? 0x93938a70 0x93938a79 0x93a00215 Kernel Offset: 0x1220 from 0x8100 (relocation range: 0x8000-0xbfff) ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]--- """ This appears to be lz4 related. Changing the initramfs to gzip makes the VM boot just fine. It's worth noting that when booting the generic kernel, we get the unpack error showed in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1835660 but things still boot fine. Marking verification as failed based on this. We need images to work properly with a standard Ubuntu config so need lz4 fixed. ** Tags removed: verification-needed-focal ** Tags added: verification-failed-focal -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Committed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 "
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- focal' to 'verification-done-focal'. If the problem still exists, change the tag 'verification-needed-focal' to 'verification-failed-focal'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-focal -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Committed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
** Changed in: linux-kvm (Ubuntu Focal) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: Fix Committed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR - 3FBEEA98 0047, LDTR - IDTR - 3F2D8018 0FFF, TR - FXSAVE_STATE - 3FF1C290
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
** Also affects: linux-kvm (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: linux-kvm (Ubuntu Focal) Importance: Undecided => High ** Changed in: linux-kvm (Ubuntu Focal) Status: New => In Progress ** Changed in: linux-kvm (Ubuntu Focal) Assignee: (unassigned) => Stefan Bader (smb) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Status in linux-kvm source package in Focal: In Progress Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
Pinged in #ubuntu-kernel today for an update. It'd be good to have groovy signed soon so we can then roll this out to focal users. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR - 3FBEEA98 0047, LDTR - IDTR - 3F2D8018 0FFF, TR - FXSAVE_STATE - 3FF1C290 Find image
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
Re-opening as I'm not seeing any mention of this being signed now. ** Changed in: linux-kvm (Ubuntu) Status: Fix Released => Triaged -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR - 3FBEEA98 0047, LDTR - IDTR - 3F2D8018 0FFF, TR - FXSAVE_STATE - 3FF1C290 Find
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
This bug was fixed in the package linux-kvm - 5.3.0-1017.19
---
linux-kvm (5.3.0-1017.19) eoan; urgency=medium
* eoan/linux-kvm: 5.3.0-1017.18 -proposed tracker (LP: #1877951)
* Packaging resync (LP: #1786013)
- [Packaging] resync dkms-build and family
- [Packaging] add libcap-dev dependency
* Make linux-kvm bootable in LXD VMs (LP: #1873809)
- [config] Enable CONFIG_EFI_STUB
- [Config] Enable VSOCKETS in KVM
[ Ubuntu: 5.3.0-53.47 ]
* eoan/linux: 5.3.0-53.47 -proposed tracker (LP: #1877257)
* Intermittent display blackouts on event (LP: #1875254)
- drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
* Unable to handle kernel pointer dereference in virtual kernel address space
on Eoan (LP: #1876645)
- SAUCE: overlayfs: fix shitfs special-casing
[ Ubuntu: 5.3.0-52.46 ]
* eoan/linux: 5.3.0-52.46 -proposed tracker (LP: #1874752)
* alsa: make the dmic detection align to the mainline kernel-5.6
(LP: #1871284)
- ALSA: hda: add Intel DSP configuration / probe code
- ALSA: hda: fix intel DSP config
- ALSA: hda: Allow non-Intel device probe gracefully
- ALSA: hda: More constifications
- ALSA: hda: Rename back to dmic_detect option
- [Config] SND_INTEL_DSP_CONFIG=m
- [packaging] Remove snd-intel-nhlt from modules
* built-using constraints preventing uploads (LP: #1875601)
- temporarily drop Built-Using data
* ubuntu/focal64 fails to mount Vagrant shared folders (LP: #1873506)
- [Packaging] Move virtualbox modules to linux-modules
- [Packaging] Remove vbox and zfs modules from generic.inclusion-list
* linux-image-5.0.0-35-generic breaks checkpointing of container
(LP: #1857257)
- SAUCE: overlayfs: use shiftfs hacks only with shiftfs as underlay
* shiftfs: broken shiftfs nesting (LP: #1872094)
- SAUCE: shiftfs: record correct creator credentials
* Add debian/rules targets to compile/run kernel selftests (LP: #1874286)
- [Packaging] add support to compile/run selftests
* shiftfs: O_TMPFILE reports ESTALE (LP: #1872757)
- SAUCE: shiftfs: fix dentry revalidation
* getitimer returns it_value=0 erroneously (LP: #1349028)
- [Config] CONTEXT_TRACKING_FORCE policy should be unset
* 5.3.0-46-generic - i915 - frequent GPU hangs / resets rcs0 (LP: #1872001)
- drm/i915/execlists: Preempt-to-busy
- drm/i915/gt: Detect if we miss WaIdleLiteRestore
- drm/i915/execlists: Always force a context reload when rewinding RING_TAIL
* alsa/sof: external mic can't be deteced on Lenovo and HP laptops
(LP: #1872569)
- SAUCE: ASoC: intel/skl/hda - set autosuspend timeout for hda codecs
* Eoan update: upstream stable patchset 2020-04-22 (LP: #1874325)
- ARM: dts: sun8i-a83t-tbs-a711: HM5065 doesn't like such a high voltage
- bus: sunxi-rsb: Return correct data when mixing 16-bit and 8-bit reads
- net: vxge: fix wrong __VA_ARGS__ usage
- hinic: fix a bug of waitting for IO stopped
- hinic: fix wrong para of wait_for_completion_timeout
- cxgb4/ptp: pass the sign of offset delta in FW CMD
- qlcnic: Fix bad kzalloc null test
- i2c: st: fix missing struct parameter description
- cpufreq: imx6q: Fixes unwanted cpu overclocking on i.MX6ULL
- media: venus: hfi_parser: Ignore HEVC encoding for V1
- firmware: arm_sdei: fix double-lock on hibernate with shared events
- null_blk: Fix the null_add_dev() error path
- null_blk: Handle null_add_dev() failures properly
- null_blk: fix spurious IO errors after failed past-wp access
- xhci: bail out early if driver can't accress host in resume
- x86: Don't let pgprot_modify() change the page encryption bit
- block: keep bdi->io_pages in sync with max_sectors_kb for stacked devices
- irqchip/versatile-fpga: Handle chained IRQs properly
- sched: Avoid scale real weight down to zero
- selftests/x86/ptrace_syscall_32: Fix no-vDSO segfault
- PCI/switchtec: Fix init_completion race condition with poll_wait()
- media: i2c: video-i2c: fix build errors due to 'imply hwmon'
- libata: Remove extra scsi_host_put() in ata_scsi_add_hosts()
- pstore/platform: fix potential mem leak if pstore_init_fs failed
- gfs2: Don't demote a glock until its revokes are written
- x86/boot: Use unsigned comparison for addresses
- efi/x86: Ignore the memory attributes table on i386
- genirq/irqdomain: Check pointer in irq_domain_alloc_irqs_hierarchy()
- block: Fix use-after-free issue accessing struct io_cq
- media: i2c: ov5695: Fix power on and off sequences
- usb: dwc3: core: add support for disabling SS instances in park mode
- irqchip/gic-v4: Provide irq_retrigger to avoid circular locking dependency
- md: check arrays is suspended in mddev_detach before call quiesce
operations
- firmware: fix a double abort case with fw_load_sysfs_fallback
- locking/lockdep: Avoid recursion in lockdep_count_{for,back}ward_deps()
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
@stgraber sorry I should have clarified that I'm referring to Eoan specifically. In Eoan, EFI_STUB is still not enabled. Is it needed there? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR - 3FBEEA98 0047, LDTR - IDTR - 3F2D8018 0FFF, TR - FXSAVE_STATE - 3FF1C290 Find
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
@Khaled yes, it is and we have it now. What's still needed is for the kernel to be signed so it can be used under secureboot. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR - 3FBEEA98 0047, LDTR - IDTR - 3F2D8018 0FFF, TR - FXSAVE_STATE - 3FF1C290 Find image based on
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
@stgraber I'm getting mixed messages from the last few comments about whether CONFIG_EFI_STUB is needed or not - can you please clarify? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR - 3FBEEA98 0047, LDTR - IDTR - 3F2D8018 0FFF, TR - FXSAVE_STATE - 3FF1C290 Find
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
Hello, Just tested the latest image in ./current and it boots fine : root@focal-ok:~# uname -a Linux focal-ok 5.4.0-1009-kvm #9-Ubuntu SMP Mon Apr 20 20:23:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux root@focal-ok:~# cat /etc/cloud/build.info build_name: server serial: 20200421 root@focal-ok:~# uname -r 5.4.0-1009-kvm root@focal-ok:~# grep -i ^CONFIG_EFI /boot/config-5.4.0-1009-kvm CONFIG_EFI=y CONFIG_EFI_STUB=y CONFIG_EFI_MIXED=y CONFIG_EFI_VARS=y CONFIG_EFI_ESRT=y CONFIG_EFI_RUNTIME_WRAPPERS=y CONFIG_EFI_EARLYCON=y CONFIG_EFI_PARTITION=y CONFIG_EFIVAR_FS=m Thanks for the quick turnaround ! ...Louis -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
Ok, fixed the bug tasks and re-opened the bug as we still need this kernel to get signed. ** Changed in: linux-kvm (Ubuntu) Status: Fix Released => Triaged ** Changed in: cloud-images Assignee: Roufique Hossain (roufique) => (unassigned) ** Changed in: linux-kvm (Ubuntu) Assignee: Roufique Hossain (roufique) => (unassigned) ** Changed in: cloud-bl-tutorials Status: Confirmed => Invalid ** Changed in: cloud-bl-tutorials Status: Invalid => New ** Changed in: cloud-bl-tutorials Remote watch: Email to roufique@rtat # => None ** Project changed: cloud-bl-tutorials => linux (Ubuntu) ** No longer affects: linux (Ubuntu) ** Changed in: cloud-images Status: Confirmed => Invalid -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: Triaged Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
Hmm, actually, CONFIG_EFI_STUB is the one we were missing and I'm not seeing that in your VM either, which makes me wonder how it was booted in the first place :) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in Cloud-Bio-Linux Tutorials: Confirmed Status in cloud-images: Confirmed Status in linux-kvm package in Ubuntu: Fix Released Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR - 3FBEEA98 0047, LDTR - IDTR - 3F2D8018
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
Thanks Louis, so our testing may in fact have been accurate and things regressed afterwards :) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in Cloud-Bio-Linux Tutorials: Confirmed Status in cloud-images: Confirmed Status in linux-kvm package in Ubuntu: Fix Released Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR - 3FBEEA98 0047, LDTR - IDTR - 3F2D8018 0FFF, TR - FXSAVE_STATE - 3FF1C290
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
This bug was fixed in the package linux-kvm - 5.4.0-1009.9 --- linux-kvm (5.4.0-1009.9) focal; urgency=medium * focal/linux-kvm: 5.4.0-1009.9 -proposed tracker (LP: #1873934) * multipathd.service fails to start with linux-kvm kernel (LP: #1873912) - [Config] Enable dm-multipath modules * Make linux-kvm bootable in LXD VMs (LP: #1873809) - [Config] CONFIG_EFI_STUB=y - [Config] Enable vsocket config options -- Seth Forshee Mon, 20 Apr 2020 14:30:41 -0500 ** Changed in: linux-kvm (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in Cloud-Bio-Linux Tutorials: Confirmed Status in cloud-images: Confirmed Status in linux-kvm package in Ubuntu: Fix Released Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
Hello, thanks for the quick turnaround. For the record, some EFI configs did exist in prior 5.3 images : root@focal:/boot# cat /etc/cloud/build.info build_name: server serial: 20200223 root@focal:/boot# uname -r 5.3.0-1009-kvm root@focal:/boot# grep -i ^CONFIG_EFI config-5.3.0-1009-kvm CONFIG_EFI=y CONFIG_EFI_VARS=y CONFIG_EFI_ESRT=y CONFIG_EFI_RUNTIME_WRAPPERS=y CONFIG_EFI_EARLYCON=y CONFIG_EFI_PARTITION=y CONFIG_EFIVAR_FS=m I'll be using the other image for testing in the meantime ...Louis -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in Cloud-Bio-Linux Tutorials: Confirmed Status in cloud-images: Confirmed Status in linux-kvm package in Ubuntu: Confirmed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
** Changed in: cloud-images Status: Invalid => Confirmed ** Changed in: cloud-images Assignee: (unassigned) => Roufique Hossain (roufique) ** Changed in: linux-kvm (Ubuntu) Assignee: Colin Ian King (colin-king) => Roufique Hossain (roufique) ** Changed in: linux-kvm (Ubuntu) Status: New => Incomplete ** Changed in: linux-kvm (Ubuntu) Status: Incomplete => Confirmed ** Bug watch added: Email to roufique@rtat # mailto:roufi...@rtat.net ** Also affects: cloud-bl-tutorials via mailto:roufi...@rtat.net Importance: Undecided Status: New ** Changed in: cloud-bl-tutorials Status: New => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in Cloud-Bio-Linux Tutorials: Confirmed Status in cloud-images: Confirmed Status in linux-kvm package in Ubuntu: Confirmed Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
** Changed in: linux-kvm (Ubuntu) Assignee: (unassigned) => Colin Ian King (colin-king) ** Changed in: linux-kvm (Ubuntu) Importance: Undecided => High -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: New Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR - 3FBEEA98 0047, LDTR - IDTR - 3F2D8018 0FFF, TR - FXSAVE_STATE -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
Just tested it now, confirmed that this still boots fine and that this time the LXD agent successfully starts too. So this config seems suitable for us. That + enabling kernel signing will get us working images. Thanks! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: New Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR - 3FBEEA98 0047, LDTR - IDTR - 3F2D8018
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
** Description changed: The `disk-kvm.img` images which are to be preferred when run under - virtualization, completely fail to boot under UEFI. + virtualization, currently completely fail to boot under UEFI. - This is a critical issue as those are the images that LXD is now pulling - by default. + A workaround was put in place such that LXD instead will pull generic- + based images until this is resolved, this however does come with a much + longer boot time (as the kernel panics, reboots and then boots) and also + reduced functionality from cloud-init, so we'd still like this fixed in + the near future. + To get things behaving, it looks like we need the following config + options to be enable in linux-kvm: + + - CONFIG_EFI_STUB + - CONFIG_VSOCKETS + - CONFIG_VIRTIO_VSOCKETS + - CONFIG_VIRTIO_VSOCKETS_COMMON + + == Rationale == + We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. + + We also need the LXD agent to work, which requires functional virtio + vsock. + + == Test case == + - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz + - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img + - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 + - lxc launch bug1873809 v1 + - lxc console v1 + - + - + - lxc exec v1 bash + + To validate a new kernel, you'll need to manually repack the .img file + and install the new kernel in there. + + == Regression potential == + I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. + + Also, this will be introducing virtio vsock support which again, could + maybe confused some horribly broken systems? + + + In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. + + + -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 - Note that the non optimized images boot just fine (disk1.img). - - I've reproduced this issue with: - - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G - + - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img + - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR - 3FBEEA98 0047, LDTR - IDTR - 3F2D8018 0FFF, TR - FXSAVE_STATE -
[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs
Test build with the vsock options: https://people.canonical.com/~sforshee/lp1873809/linux- kvm-5.4.0-1008-kvm/ -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: Make linux-kvm bootable in LXD VMs Status in cloud-images: Invalid Status in linux-kvm package in Ubuntu: New Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, currently completely fail to boot under UEFI. A workaround was put in place such that LXD instead will pull generic- based images until this is resolved, this however does come with a much longer boot time (as the kernel panics, reboots and then boots) and also reduced functionality from cloud-init, so we'd still like this fixed in the near future. To get things behaving, it looks like we need the following config options to be enable in linux-kvm: - CONFIG_EFI_STUB - CONFIG_VSOCKETS - CONFIG_VIRTIO_VSOCKETS - CONFIG_VIRTIO_VSOCKETS_COMMON == Rationale == We'd like to be able to use the linux-kvm based images for LXD, those will directly boot without needing the panic+reboot behavior of generic images and will be much lighter in general. We also need the LXD agent to work, which requires functional virtio vsock. == Test case == - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809 - lxc launch bug1873809 v1 - lxc console v1 - - - lxc exec v1 bash To validate a new kernel, you'll need to manually repack the .img file and install the new kernel in there. == Regression potential == I don't know who else is using those kvm images right now, but those changes will cause a change to the kernel binary such that it contains the EFI stub bits + a signature. This could cause some (horribly broken) systems to no longer be able to boot that kernel. Though considering that such a setup is common to our other kernels, this seems unlikely. Also, this will be introducing virtio vsock support which again, could maybe confused some horribly broken systems? In either case, the kernel conveniently is the only package which ships multiple versions concurently, so rebooting on the previous kernel is always an option, mitigating some of the risks. -- Details from original report -- User report on the LXD side: https://github.com/lxc/lxd/issues/7224 I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - ExceptionData - RIP - 3FF2DA12, CS - 0038, RFLAGS - 00200202 RAX - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0398, RSP - 3FF1C638, RBP - 3FF34360 RSI - 3FF343B8, RDI - 1000 R8 - 3E80F108, R9 - 3E815B98, R10 - 0065 R11 - 2501, R12 - 0004, R13 - 3E80F100 R14 - , R15 - DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 80010033, CR2 - , CR3 - 3FC01000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR - 3FBEEA98 0047, LDTR - IDTR - 3F2D8018 0FFF, TR - FXSAVE_STATE - 3FF1C290 Find image based on IP(0x3FF2DA12)
