Grub2 installs on the wrong device if in a RAID config

[Ameet Paranjape]

Binary package hint: grub2

- Install Ubuntu server 11.04 Beta1 x86_64 on a HP DL380 G7 with a RAID controller using a USB startup disk
- The OS install proceeds normally, but at the end of the install when it is time for GRUB2 to load itself onto a local disk, the installer is incorrectly selecting the USB startup disk's /dev location instead of a /dev on the box
- If the USB stick is removed for reboot after the install completes, the system does not boot to a login

Workaround:
- Plug the USB stick back into the system
- Reboot the box
- Manually move grub2 off the usb stick on to a local drive using 'sudo grub-install /dev/sda' or whatever your local disk's location is

This was an issue in 11.04 Alpha2, it went away in 11.04 Alpha3, but has returned in 11.04 Beta1 on the same box and same hardware.

[Ameet Paranjape (ameetp)]

Forgot to mention that I have not seen this issue on systems without a RAID controller

[Rudy Broersma (tozz)]

I have the same issue. The partition wizard selects /dev/cciss/c0d0 as preferred device, when selecting 'Use entire disk' it configures the root partition on this device. But grub decides to install on /dev/sda insteaf of /dev/cciss/c0d0

/dev/sda is an internal 4GB flashdrive.
the HP SmartArray (cciss) is selected as primary boot device in the BIOS

I'm not 100% sure (I cant verify right now) but I think I have the same issue with a Dell R805 which also has a build in internal flashdrive (for VMWare purposes, which we do not use).

[Tom Ellis (tellis)]

This also affects Lucid #589483

[Peter Matulis (petermatulis)]

@Tom, I marked that bug as a duplicate of this one.

Can we say for sure that this affects only cciss RAID devices (HP)?

@Rudy, did you confirm whether your Dell is affected by this?

[Colin Watson (cjwatson)]

Could I have an installer syslog demonstrating the problem, please? It would help if you could ensure that the DEBCONF_DEBUG=developer boot parameter is used when booting the installer (be careful not to use valuable passwords in this case).

[Ameet Paranjape (ameetp)]

Here is a syslog from an affected system with the DEBCONF_DEBUG=developer supplied at boot prompt.

[Ameet Paranjape (ameetp)]

This is the installer syslog with the DEBCONF_DEBUG=developer option set.

[Colin Watson (cjwatson)]

Ameet, are you sure that this installation demonstrated the problem? What I'm seeing is:

 * /dev/sda is a 4GB device, presumably a USB stick, and contains the installation medium
 * /dev/sdb is an 897GB device, rather unlikely to be a USB stick
 * grub-installer/bootdev defaults to /dev/sdb

Unless I'm missing something, this looks as though the installer has behaved correctly ...

[Ameet Paranjape (ameetp)]

@Colin, you are correct the installer is behaving correctly now.

I cannot get this system to reproduce the error on Ubuntu server 11.04 anymore. I swore I saw it the first time I put Ubuntu on this box...

Anyway, I need to do some investigation on my side about when and why this occurs. i.e. installing on an existing RAID config or a new one, RAID 0 vs 1,5,10, installing Ubuntu over another OS, etc. I will update the bug when I have more data.

[Peter Matulis (petermatulis)]

@Colin

Here is a (partial, grepped) syslog. I'm trying to track down the full one.

[Peter Matulis (petermatulis)]

@Colin

Is the attached syslog sufficient?

[Milan Niznansky (online-minosi-deactivatedaccount)]

Tried to change to D-I since thi is clearly upstream issue, LP accepted save, did nothing and removed my text. Screw it.

Just tio let you know Squeeze 6.0.21 has identical behavior - D-I just overwrites first disk present not even telling the user it intends to brick the box.

Happen to me on 6-disk devel box with D-I basically aliminatin hyper-v boot loader ...

Really nice. So now eve to install debian-based stuff one has to go onsite and physically remove all drives except the one to be used.

One has to love such "feature" parity with Windows ...

[Phillip Susi (psusi)]

Since Colin pointed out that the logs show it worked correctly and the reporter said he could not reproduce it, I'm going to close this now.