[Bug 1828558] Re: installing ubuntu on a former md raid volume makes system unusable

[Michael Hudson-Doyle]

I have verified the fix for bionic and disco by doing netinstalls with
apt-setup/proposed=true on the kernel command line with disk images that
had had a raid6 with 0.90 metadata created on them and watching the
output of wipefs $image outside of the VM. Immediatly before selecting
the "write changes to disk" action in partman:

mwhudson at ringil:~/tmp/netinstall/bionic$ wipefs raid2.img
DEVICE    OFFSET      TYPE              UUID                                 LABEL
raid2.img 0x27fff0000 linux_raid_member 2ff715a9-0173-2508-14d5-894fb9296617 
raid2.img 0x1fe       dos                                                    

And immediately after:

mwhudson at ringil:~/tmp/netinstall/bionic$ wipefs raid2.img
DEVICE    OFFSET TYPE UUID LABEL
raid2.img 0x1fe  dos       

I also checked the installed disk booted and the wipefs output inside
the VM.

And the same for disco:

mwhudson at ringil:~/tmp/netinstall/disco$ wipefs raid3.img
DEVICE    OFFSET      TYPE              UUID                                 LABEL
raid3.img 0x27fff0000 linux_raid_member 2ff715a9-0173-2508-14d5-894fb9296617 
mwhudson at ringil:~/tmp/netinstall/disco$ wipefs raid3.img
DEVICE    OFFSET TYPE UUID LABEL
raid3.img 0x1fe  dos       


** Tags removed: verification-needed verification-needed-bionic verification-needed-disco
** Tags added: verification-done verification-done-bionic verification-done-disco

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

Title:
  installing ubuntu on a former md raid volume makes system unusable

Status in partman-base package in Ubuntu:
  Fix Released
Status in partman-base source package in Bionic:
  Fix Committed
Status in partman-base source package in Disco:
  Fix Committed

Bug description:
  [impact]
  Installing ubuntu on a disk that was previously a md raid volume leads to a system that doesn't boot (or perhaps does not reliably boot)

  [test case]
  Create a disk image that has a md RAID 6, metadata 0.90 device on it using the attached "mkraid6" script.

  $ sudo mkraid6

  Install to it in a VM:

  $ kvm -m 2048 -cdrom ~/isos/ubuntu-18.04.2-desktop-amd64.iso -drive
  file=raid2.img,format=raw

  Reboot into the installed system. Check that it boots and that there
  are no occurrences of linux_raid_member in the output of "sudo wipefs
  /dev/sda".

  SRU member request: testing other, regular installation scenarios to
  sanity check for regressions (comment #10).

  [regression potential]
  The patch makes a change to a core part of the partitioner. A bug here could crash the installer, rendering it impossible to install. The code is adapted from battle-tested code in wipefs from util-linux and has been somewhat tested before uploading to eoan. The nature of the code makes regressions beyond crashing the installer or failing to do what it's supposed to very unlikely -- it is hard to see how this could result on data loss on a drive not selected to be formatted, for example.

  [original description]
  18.04 is installed using GUI installer in 'Guided - use entire volume' mode on a disk which was previously used as md raid 6 volume. Installer repartitions the disk and installs the system, system reboots any number of times without issues. Then packages are upgraded to the current states and some new packages are installed including mdadm which *might* be the culprit, after that system won't boot any more failing into ramfs prompt with 'gave up waiting for root filesystem device' message, at this point blkid shows boot disk as a device with TYPE='linux_raid_member', not as two partitions for EFI and root (/dev/sda, not /dev/sda1 and /dev/sda2). I was able fix this issue by zeroing the whole disk (dd if=/dev/zero of=/dev/sda bs=4096) and reinstalling. Probably md superblock is not destroyed when disk is partitioned by the installer, not overwritten by installed files and somehow takes precedence over partition table (gpt) during boot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/partman-base/+bug/1828558/+subscriptions