Speaking of cloud-images generally I propose the following:
* Images in the ubuntu-cpc project by default should boot with an initramfs.
* Revert the livecd-rootfs change which "Unconditionally set
GRUB_FORCE_PARTUUID in cloud images"
* Images with custom kernels can boot without an initramfs
* Set GRUB_FORCE_PARTUUID as part of livefs-rootfs:live-build/functions
replace_kernel() as this is used by the ubuntu-cpc project for each image that
ships an optimized kernel intended to boot without initramfs.
Steve, I agree with everything you said in comment #21 about removing
not this functionality from Azure images. I think there is room to
improve the experience for users that change their kernel and encounter
this behavior. The panic/reboot behavior is unexpected and the mapping
of GRUB_FORCE_PARTUUID to initramfs-less boot is non-obvious to the end
user. I don't immediately have suggestions to smooth this rough edge
but I feel that we need to take some time on this before completely
closing this bug out.
--
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 cloud-images:
New
Status in grub2 package in Ubuntu:
Won't Fix
Status in linux-azure package in Ubuntu:
Invalid
Status in livecd-rootfs package in Ubuntu:
Triaged
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/cloud-images/+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
