Upgrade to 12.04LTS dumps to busybox on boot

Question

I just upgraded my server from 10.04LTS to 12.04 LTS using the server upgrade process documented here: https://help.ubuntu.com/community/PreciseUpgrades.

On boot, I am now dumped to the busybox shell (more on this in a moment). However, if I boot a kernel from the previous release, everything boots fine.

The only thing odd about my configuration is that my boot device is a multi-disk device using RAID1. When I get to the busybox shell, typing "mount /dev/md0 /root" works just fine. I've tried passing in rootdelay=30 and I'm dumped to the shell within 5 seconds of boot.

Unlike the question marked here: Upgraded from 10.04 to 12.04 and grub drops to BusyBox prompt without error I've not been booting with the splash or quiet option, and I've received no complaints about a degraded array. Nonetheless, I've tried booting with the bootdegraded kernel option and this has not worked either.

Any thoughts on what to try?

(And yes, the power supply is plugged in :-) )

Config information:

Grub version: grub (GNU GRUB 0.97)

Most grub menu.lst options are commented out (to use defaults). Most recent kernel which doesn't work:

title           Ubuntu 12.04.2 LTS, kernel 3.2.0-51-generic-pae
root            (hd0,1)
kernel          /boot/vmlinuz-3.2.0-51-generic-pae root=/dev/md0 ro
initrd          /boot/initrd.img-3.2.0-51-generic-pae
quiet

Most recent kernel which does work:

title           Ubuntu 12.04.2 LTS, kernel 2.6.32-46-generic-pae
root            (hd0,1)
kernel          /boot/vmlinuz-2.6.32-46-generic-pae root=/dev/md0 ro
initrd          /boot/initrd.img-2.6.32-46-generic-pae
quiet

mdadm information:

garrett@stargate:/boot/grub$ sudo mdadm --detail /dev/md0
/dev/md0:
        Version : 0.90
  Creation Time : Sat Dec 16 22:27:17 2006
     Raid Level : raid1
     Array Size : 57609024 (54.94 GiB 58.99 GB)
  Used Dev Size : 57609024 (54.94 GiB 58.99 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Mon Sep  2 17:02:27 2013
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : 5c92f0d9:9cf5be95:03611c5e:a540b92f
         Events : 0.24172972

    Number   Major   Minor   RaidDevice State
       0       8       18        0      active sync   /dev/sdb2
       1       8        2        1      active sync   /dev/sda2

Md device data as seen by the kernel:

garrett@stargate:~$ cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid1 sda2[1] sdb2[0]
      57609024 blocks [2/2] [UU]

unused devices: <none>

Answer 1

This is caused by an odd configuration as well as a change in boot scripts.

First, the mirrored device, /dev/md0 does not have a partition table. It is treated as a raw block device with a filesystem directly on it. In emergency cases, this allows the backing device (/dev/sda2 or /dev/sdb2) to be booted directly. There was previously an short-lived installation of LVM on this partition, but this was deemed unneeded so the device was reinitialized as a raw ext3 device. This did not successfully remove all traces of LMV, however. This results in the utility wait-for-root returning 'LVM2_member' as the device type. It has done this all along.

Second, updates to the boot script 'scripts/local' changed the mount command from:

mount ${roflag} ${ROOTFLAGS} ${ROOT} ${rootmnt}

to:

mount ${roflag} ${FSTYPE:+-t ${FSTYPE} }${ROOTFLAGS} ${ROOT} ${rootmnt}

Mount now fails because we are forcing the type of filesystem into the mount command. In this case, the type 'LVM2_member' doesn't work at all - we need ext3 instead. The old version worked because mount was easily able to determine that this was an ext3 filesystem.

The short-term work-around for this is to pass in rootfstype=ext3 on the kernel boot line. This ignores the improperly auto-detected filesystem type and specifies ext3 to mount.