[Bug 1870189] Re: initramfs does not get loaded
Steve Langasek
steve.langasek at canonical.com
Tue May 19 18:59:06 UTC 2020
On Tue, May 12, 2020 at 08:09:12PM -0000, Dexuan Cui wrote:
> Hi Steve, I guess you assume the pattern is
> "panic/success/success/success/...", but actually the pattern is
> “panic/success/panic/success/panic/success/...” -- this is pretty
> confusing. Please refer to the the Bug Description for details.
No, on the contrary, it's intentional that on each fresh reboot it again
attempts an initramfsless boot before falling back to an initramfsfull boot.
Because the expectation is that any image using this feature should boot
without initramfs, and if it doesn't that is a bug or a configuration error
(using the wrong kernel for the target, or not removing the config flag when
testing a different kernel). The intent is that the system remain bootable
even if there is such a bug or configuration error.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 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
More information about the foundations-bugs
mailing list