When installing onto fake raid grub still tried to install to /dev/sda

Bug #603854 reported by Joel Ebel on 2010-07-10
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
grub-installer (Ubuntu)
High
Colin Watson
Lucid
High
Colin Watson
Maverick
High
Colin Watson

Bug Description

Impact: d-i installations onto fake RAID (a.k.a. DM-RAID or SATA RAID) install to /dev/sda rather than to the RAID device. This may work for a while but leaves the boot arrangements vulnerable to RAID elements going away, different device ordering, etc.
Development branch (and maverick): http://bazaar.launchpad.net/~ubuntu-core-dev/grub-installer/ubuntu/revision/869
Patch: See above; the same patch applies with only an offset.
TEST CASE: Install on a system with DM-RAID using d-i (alternate CD, server CD, or netboot). (Until new CDs are respun, testing the fixed version will only be possible using netboot, and will require 'apt-setup/proposed=true' on the installer kernel command line.) Either watch the GRUB installation step closely, or check the output of 'sudo debconf-show grub-pc | grep install_devices:' after installation (you may need to run the value through 'readlink -f' to resolve symlinks); GRUB should be installed to /dev/mapper/something rather than to /dev/sda or similar.
Regression potential: The variable controlling this code is only set for the DM-RAID and multipath cases, both of which need the same treatment, so assuming it works at all I don't expect anything else to get worse.

Original report follows:

Binary package hint: grub-installer

It was suggested in bug 568050 that I file a new bug for the grub-installer portion of installing onto fake raid. That bug has resolved the partman issues around installing onto fakeraid, so now getting grub-installer to install onto the raid device is the only remaining part to getting it working I think. Attached is a syslog from an install onto fakeraid. The system is installed and could boot off of /dev/mapper/isw_bjffiahcab_Volume0 but grub-installer still chose to install to /dev/sda and strangely reported memory leaks.

This seems to be a long standing issue, and is likely a duplicate bug, but I was unable to find exactly the right bug. grub-installer doesn't have any other bugs currently open.

Joel Ebel (jbebel) wrote :
Tom Louwrier (tom-louwrier) wrote :

I had this bug today when trying to install 10.10 Maverick Beta from a alternative daily CD (iso-image from 05 sept 2010). At the end of the install procedure grub was installed on /dev/sda which i *did not* ask for.
See also LP 420992.

Luckily, earlier I had found and used the workaround as described in 420992 #11 so grub was already on the array's mbr.
Rebooted into recovery mode and got myself a root session on the right partition (pdc_jcchiiaab5), mounted /home partition and then ran update-grub. Saw a lot of error messages about memory leaks, but it found my OS'es.

Ubuntu will not boot though because of issues with device names not handled right between kernel, grub and dmraid. Bummer.
This means I can now boot into XP (alas... but that does work with dmraid) but not into Maverick.

cheers
Tom

Changed in grub-installer (Ubuntu):
status: New → Confirmed
Colin Watson (cjwatson) wrote :

Reproduced on a current daily, still. Eek. I'll see if I can squeeze a fix into 10.10 ...

Changed in grub-installer (Ubuntu):
status: Confirmed → Triaged
Colin Watson (cjwatson) wrote :

Uploaded a fix to maverick, awaiting release team approval. (I'll deal with lucid later, but I hope in time for 10.04.2.)

I've done a straight-through server install in KVM with this fix, and tested that the resulting system boots with the two virtual disks both ways round.

Changed in grub-installer (Ubuntu Lucid):
status: New → Triaged
importance: Undecided → High
Changed in grub-installer (Ubuntu Maverick):
importance: Undecided → High
Changed in grub-installer (Ubuntu Lucid):
assignee: nobody → Colin Watson (cjwatson)
milestone: none → ubuntu-10.04.2
Changed in grub-installer (Ubuntu Maverick):
assignee: nobody → Colin Watson (cjwatson)
milestone: none → ubuntu-10.10
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package grub-installer - 1.55ubuntu4

---------------
grub-installer (1.55ubuntu4) maverick; urgency=low

  * Install GRUB to the SATA RAID or multipath device when /boot is on such
    a device, rather than installing to the first hard disk (LP: #603854).
 -- Colin Watson <email address hidden> Tue, 05 Oct 2010 21:57:05 +0100

Changed in grub-installer (Ubuntu Maverick):
status: Triaged → Fix Released
Colin Watson (cjwatson) on 2010-11-10
description: updated
Colin Watson (cjwatson) on 2010-11-10
Changed in grub-installer (Ubuntu Lucid):
status: Triaged → In Progress
Joel Ebel (jbebel) wrote :

Verified the fix on an HP z600 using RAID 0. grub was installed to /dev/dm-0.

Accepted grub-installer into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in grub-installer (Ubuntu Lucid):
status: In Progress → Fix Committed
tags: added: verification-needed
Darin Tay (dtay) wrote :

I've verified on an HP z600 using RAID 0 (which fails normal Lucid installation due to this issue) that installing Lucid with the package in proposed worked fine.

Martin Pitt (pitti) on 2010-12-23
tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package grub-installer - 1.49ubuntu11.1

---------------
grub-installer (1.49ubuntu11.1) lucid-proposed; urgency=low

  * Install GRUB to the SATA RAID or multipath device when /boot is on such
    a device, rather than installing to the first hard disk (LP: #603854).
 -- Colin Watson <email address hidden> Wed, 10 Nov 2010 13:16:08 +0000

Changed in grub-installer (Ubuntu Lucid):
status: Fix Committed → Fix Released
tags: added: testcase
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments