System boots to initramfs after upgrade from 21.10 to 22.04

Question

I upgraded to jammy and now I have problems.

I have two 500G SSDs (sda/sdb) in RAID1 mirror in ASUS BIOS ("promise" RAID, I suspect) and sdc is a physical LSI RAID controller. It's a UEFI system, so there were two partitions on the mapper. Upon initial reboot after upgrade, I got "unable to mount root fs" kernel panic. When I rebooted and selected a previous kernel, I got "mdadm no arrays found" error and dropped to initramfs. I don't know why mdadm is being called, as I stated above was using the ASUS BIOS RAID.

I used the boot repair tool, and that also downloaded the mdadm utilities. I've uploaded the repair tool results here:

https://paste.ubuntu.com/p/yTb4gZcWc3

Any help getting back to a working system would be appreciated!

Answer 1

I ran into a similar issue but only /home was on the RAID so this solution may not work for you.

I started with the suggestion from ascii above (bugs.launchpad.net/ubuntu/+source/linux/+bug/1313169). In addition to the steps mentioned, I updated /etc/fstab to use the UUID of the RAID volume instead of the /dev/mapper path.

Then I followed the steps at https://superuser.com/questions/1221023/isw-raid-member-intel-rapid-storage-on-debian

From busybox:

1. dmsetup ls should show the RAID block device (something like isw_bcegjbdfjj_Volume_0000)

2. partprobe /dev/mapper/[RAID name] should mount the partitions in /dev/mapper

3. mount [mountpoint] should now work if the partition naming is consistent with /etc/fstab

4. If that works, exiting busybox should reboot as normal.

Answer 2

Bug report with patch: https://bugs.launchpad.net/ubuntu/+source/dmraid/+bug/2047303

initramfs needs to be regenerated after patch is applied (What does "regenerate your initramfs" mean?)

• OS can be booted from the above point (initramfs shell) by manually detecting the partitions like via 'kpartx' (Boot fails after upgrading from 20.04 to 22.04 on dmraid device, no partitons).
• If boot partition is encrypted, it must manually be unlocked before continuing
  • cryptsetup open /dev/mapper/name-of-os-volume expected-name-of-unlocked-volume
  • Encrypted disk not available in boot process after distro upgrade
• type 'exit' to continue booting. Boot will succeed if nothing else is wrong and the encrypted volume was opened with the name the OS expects

Lots of posts over many years indicate that dmraid is awful/obsolete and should be replaced with mdadm without question. Take great care in attempting to retrofit an existing installation. The two technologies use completely different naming schemes for devices and the references will need to be updated. I've not yet come across end-to-end instructions that work and I've spent many hours re-learning how to recover my boot partition after mdadm was unexpectedly installed.