[Bug 1870189] Re: initramfs does not get loaded

[Mathew Hodson]

livecd-rootfs (2.672) groovy; urgency=medium

  [ David Krauser ]
  * Boot with an initramfs by default in cloud images, except when
    using a non-generic kernel.

 -- Robert C Jennings <robert.jennings at canonical.com>  Fri, 10 Jul 2020
07:47:47 -0500

** Changed in: livecd-rootfs (Ubuntu)
       Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1870189

Title:
  initramfs does not get loaded

Status in cloud-images:
  Confirmed
Status in livecd-rootfs package in Ubuntu:
  Fix Released
Status in livecd-rootfs source package in Focal:
  Confirmed

Bug description:
  [Impact] 
  Generic cloud images will boot without initramfs, fail, and then fall back, resulting in a double boot performance hit

  [Test Case] 
  Load up cloud images from http://cloud-images.ubuntu.com/releases/focal/release/.

  For example, using http://cloud-
  images.ubuntu.com/releases/focal/release/ubuntu-20.04-server-cloudimg-
  amd64.img :

  qemu-system-x86_64    -cpu host -machine type=q35,accel=kvm -m 2048
  -nographic   -snapshot   -netdev
  id=net00,type=user,hostfwd=tcp::2222-:22   -device virtio-net-
  pci,netdev=net00   -drive if=virtio,format=qcow2,file=ubuntu-20.04
  -server-cloudimg-amd64.img   -drive if=virtio,format=raw,file=seed.img

  Note: seed.img is created using cloud-localds and a cloud-init file
  containing ssh keys.

  Observe the double boot.

  On a fixed system, there should only be one boot, and
  /boot/grub/grubenv should show initrdless_boot_fallback_triggered=0.

  [Regression Potential]
  Cloud images (both generic and cloud-specific) images perform a double boot. To mitigate the regression potential, testing will occur for all cloud-specific kernels as well as all generic cloud images.

  
  [Original 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