[Bug 2004485] Re: Ubuntu 22.04 is unable to boot from degraded software raid created by autoinstall

[Dan Bungert]

** Changed in: subiquity (Ubuntu)
       Status: New => Triaged

** Changed in: subiquity (Ubuntu)
   Importance: Undecided => Medium

** Package changed: subiquity (Ubuntu) => subiquity

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to subiquity in Ubuntu.
https://bugs.launchpad.net/bugs/2004485

Title:
  Ubuntu 22.04 is unable to boot from degraded software raid created by
  autoinstall

Status in subiquity:
  Triaged

Bug description:
  The new autoinstall installer which deprecated the previously used debian-installer supports the creation of an raid array during setup (in my case raid1).
  Also as part of the installer the /dev/md0 device is registered as Physical Volume in LVM, a Volume Group is being created and a Logical Volume is created which will be mounted at "/" for the root filesystem.

  Creating such an array works fine and results in a flawlessly working
  system. After the installation I verified that the array is in sync by
  issuing "cat /proc/mdstat".

  To simulate a failure of one disk I erased one of the disks completely
  and rebooted the system.

  The expected behaviour would be: The system boot's normally since
  there is still one disk available.

  The actual behaviour: The system is stuck during boot displaying the
  following relevant messages:

  "Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Volume Group "VG" not found"
  "Cannot process volume group VG"
  "Gave up waiting for root file system device"

  What helped resolving the issue (before wiping one of the disks):
    echo "sleep 60" > /etc/initramfs-tools/scripts/init-premount/init-mdfix
    chmod 744 /etc/initramfs-tools/scripts/init-premount/init-mdfix
    update-grub
    update-initramfs -u

  I assume the system is trying to find the root file system but this is
  not yet available since the raid array is taking too long to
  initialize after one of the disks has been wiped.

  After applying the above fix and wiping one of the disks the system
  booted normally after waiting for 60 seconds. This seems to be enough
  for the raid to initialize in a degraded state.

To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/2004485/+subscriptions