> These images should likewise be bootable under libvirt with, at most, a boot performance penalty because of the second boot.
Well, yes, it does boot on the second boot. Not trying to be contrarian here, but isn't a moot point that booting on the first boot is the de facto way things should work? I.e., a panic/reboot shouldn't be considered the "normal" way to boot on libvirt, or anywhere, for that matter. Furthermore, the panic/reboot breaks the virt-install cloud-init workflow, which expects the first boot to succeed. I mean, that's a solid expectation, right? :) What is the cloudimg designed to boot with, if not libvirt? I think virtio-scsi is being used. Here's the virt-install line, if it helps, virt-install \ -n myvm \ --description '' \ --os-type Linux \ --os-variant ubuntu16.04 \ --disk path=/var/lib/libvirt/images/focal-server-cloudimg-amd64.img,bus=scsi,discard=unmap \ --controller type=scsi,model=virtio-scsi \ --cdrom /var/lib/libvirt/images/nocloud.iso \ --virt-type kvm \ --graphics none \ --ram 1024 \ --vcpus 1 \ --network bridge:guestbr,model=virtio,virtualport_type=openvswitch,target=myvm \ --boot hd Once I do (eventually) get the image to boot through arcane ways, then I can confirm it is loading virtio-scsi: $ lsmod | grep virt virtio_net 53248 0 virtio_scsi 24576 2 Virtio-scsi seems like it needs to be compiled into the kernel for this to make sense. Am I missing something here? :) Thanks. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-azure in Ubuntu. https://bugs.launchpad.net/bugs/1870189 Title: initramfs does not get loaded Status in grub2 package in Ubuntu: Won't Fix Status in linux-azure package in Ubuntu: Confirmed Bug description: A Gen-1 Ubuntu 19.10 VM on Azure was created and upgraded to Ubuntu 20.04 by “do-release-upgrade –d”. Then the latest Ubuntu v5.6 kernel was installed from https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.6/. As soon as a reboot was performed, a panic with the v5.6 kernel occured because the rootfs can not be found. It turns out by default, initramfs does not get loaded: /boot/grub/grub.cfg: menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-3d2737e8- b95a-42bf-bac1-bb6fb4cda87f' { … if [ "${initrdfail}" = 1 ]; then linux /boot/vmlinuz-5.6.0-050600-generic root=PARTUUID=bc3d472f-401e-4774-affa-df1acba65a73 ro console=tty1 console=ttyS0 earlyprintk=ttyS0 ignore_loglevel sysrq_always_enabled unknown_nmi_panic initrd /boot/initrd.img-5.6.0-050600-generic else linux /boot/vmlinuz-5.6.0-050600-generic root=PARTUUID=bc3d472f-401e-4774-affa-df1acba65a73 ro console=tty1 console=ttyS0 earlyprintk=ttyS0 ignore_loglevel sysrq_always_enabled unknown_nmi_panic panic=-1 #Dexuan: here the initrd line is missing! fi initrdfail } As we can see, Ubuntu only uses the initrd.img if initrdfail=1. Normally, initrdfail = 0, so when we boot the v5.6 kernel for the first time, we must hit the “fail to mount rootfs” panic and the kernel will automatically reboot…. Also, the “initrdfail” here marks initrdfail=1, so when the kernel boots for the 2nd time, the kernel should successfully boot up. Next, when the kernel boots for the 3rd time, it panics again since the userspace program resets initrdfail to 0, and next time when the kernel boots, it can boot up successfully -- this “panic/success/panic/success” pattern repeats forever… The linux-azure kernels are not affected since they have the vmbus driver and storage drivers built-in (i.e. “=y”): /boot/config-5.3.0-1013-azure:CONFIG_HYPERV_STORAGE=y /boot/config-5.3.0-1013-azure:CONFIG_HYPERV=y /boot/config-5.4.0-1006-azure:CONFIG_HYPERV_STORAGE=y /boot/config-5.4.0-1006-azure:CONFIG_HYPERV=y /boot/config-5.6.0-050600-generic:CONFIG_HYPERV_STORAGE=m /boot/config-5.6.0-050600-generic:CONFIG_HYPERV=m The v5.6 kernel uses =m rather than =y, so is affected here. It looks the setting may be intentional, but we should not assume a customer kernel must have the necessary vmbus/storage drivers built-in. This issue only happens to the Ubuntu Marketplace image (19.10 and maybe 19.04 as well?) on Azure. We installed a Ubuntu 20.04 VM from the .iso file from http://cdimage.ubuntu.com/daily-live/pending/ and don’t see the strange grub issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1870189/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
