Hmmm, I am not using the ISO, but rather the pre-installed cloudimg, and I am not so sure it is actually fixed. I just tried out the latest one, and can confirm the issue still persists with it:
https://cloud-images.ubuntu.com/focal/20200430.1/focal-server-cloudimg- amd64.img Here is the output from booting: [ 0.000000] Linux version 5.4.0-28-generic (buildd@lgw01-amd64-036) (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) #32-Ubuntu SMP Wed Apr 22 17:40:10 UTC 2020 (Ubuntu 5.4.0-28.32-generic 5.4.30) [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-28-generic root=PARTUUID=be1f3b17-864d-49f8-8249-5fb0edc7e606 ro console=tty1 console=ttyS0 panic=-1 ... [ 0.999771] VFS: Cannot open root device "PARTUUID=be1f3b17-864d-49f8-8249-5fb0edc7e606" or unknown-block(0,0): error -6 [ 1.001738] Please append a correct "root=" boot option; here are the available partitions: [ 1.003295] 0b00 1048575 sr0 [ 1.003295] driver: sr [ 1.004578] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 1.006119] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.0-28-generic #32-Ubuntu [ 1.007522] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 [ 1.009254] Call Trace: [ 1.009790] dump_stack+0x6d/0x9a [ 1.010488] panic+0x101/0x2e3 [ 1.011137] mount_block_root+0x23f/0x2e8 [ 1.011931] mount_root+0x38/0x3a [ 1.012624] prepare_namespace+0x13f/0x194 [ 1.013443] kernel_init_freeable+0x231/0x255 [ 1.014319] ? rest_init+0xb0/0xb0 [ 1.015018] kernel_init+0xe/0x100 [ 1.015721] ret_from_fork+0x35/0x40 [ 1.016842] Kernel Offset: 0x1ac00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Upon reboot, initrdfail will now be set, and therefore it will actually load the initrd on the second reboot. But, because I am trying to configure the machine on the first boot using cloud-init NoCloud, it needs to actually work on the first boot. (Anyways, I think it's a moot point that first time booting should work.) In the above, the "panic=-1" followed by "Cannot open root device" indicates that there is still something amiss, at least with the cloudimg distribution. I can file a different ticket for cloudimg, if it would be more appropriate. Please advise. 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: Confirmed 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
