grub does not detect partitions properly on DMRAID

Bug #634840 reported by Tom Louwrier on 2010-09-10
This bug affects 11 people
Affects Status Importance Assigned to Milestone
grub2 (Debian)
Fix Released
grub2 (Ubuntu)
Phillip Susi
Nominated for Maverick by mitchelln

Bug Description

Binary package hint: grub2

Having troubles installing Ubuntu on a DMRAID / striped set.
Lucid would not partition right, but that was fixed recently in Gparted (LP 554582).
Went on to install from a Maverick alternative CD dd 5 sept 2010. Had a lot of troubles with getting Grub to install on the right device (it kept trying hda directly, it should go to /dev/mapper/pdc_jhiiaabc something which is the array. see LP 420992 and 603854).
Managed to overcome that (see LP 631795) but still see issues between (I think) kernel, udev, dmraid and now grub over naming conventions of devices/partitions on my dmraid setup.

Since yesterday Grub-probe ends in error because it can not find my disks and prompts me to look at
thomas@tomdesktop:~$ sudo update-grub
[sudo] password for thomas:
Generating grub.cfg ...
/usr/sbin/grub-probe: error: cannot find a GRUB drive for /dev/mapper/pdc_jcchiiab5. Check your

I tried modifying, but no success. See attached.
This means I cannot use newer kernels because update-grub will not add them to my grub config.
Also any change that triggers a kernel rebuild and update-grub after that ends with an error and keeps retrying every time I load updates or install software.

I think this issue has just been fixed: http://<email address hidden>/msg817097.html
Please implement in Maverick and Lucid if this is the case, installing on dmraid is not really working out of the box right now for a number of reasons.


Related branches

Tom Louwrier (tom-louwrier) wrote :
Phillip Susi (psusi) on 2010-09-15
Changed in grub2 (Ubuntu):
assignee: nobody → Phillip Susi (psusi)
importance: Undecided → Critical
status: New → In Progress
Phillip Susi (psusi) wrote :
Phillip Susi (psusi) wrote :

The attached patch from debian seems to fix the issue for me. While debugging it last night I traced the problem to the same area, I just didn't quite figure out how to fix it properly before bed. Found this patch today on the forums. After building grub with this patch and installing it on today's daily livecd build, I could install to and boot from a dmraid just fine.

Colin Watson (cjwatson) wrote :

Thanks, I'll look at this. I want to get it upstream first.

mitchelln (mitchell-neill) wrote :


I tried the fix_dmraid.patch, built grub2 from source and this still fails for me.

I run update-grub and get the error:
Generating grub.cfg ...
/usr/sbin/grub-probe: error: cannot find a GRUB drive for /dev/mapper/isw_cbiajacjhg_Watercooler5. Check your

mitchelln (mitchell-neill) wrote :

I've just got it to work as well with the fix_dmraid.patch. I did not have libdevmapper-dev and libfreetype6-dev installed. Put them on and rebuilt and it worked.

tags: added: patch
Launchpad Janitor (janitor) wrote :
Download full text (4.6 KiB)

This bug was fixed in the package grub2 - 1.98+20100804-5ubuntu1

grub2 (1.98+20100804-5ubuntu1) maverick; urgency=low

  * Resynchronise with Debian. Remaining changes:
    - Adjust for default Ubuntu boot options ("quiet splash").
    - Default to hiding the menu; holding down Shift at boot will show it.
    - Set a monochromatic theme for Ubuntu.
    - Apply Ubuntu GRUB Legacy changes to legacy update-grub script: title,
      recovery mode, quiet option, tweak how memtest86+ is displayed, and
      use UUIDs where appropriate.
    - Fix backslash-escaping in merge_debconf_into_conf.
    - Remove "GNU/Linux" from default distributor string.
    - Add crashkernel= options if kdump and makedumpfile are available.
    - If other operating systems are installed, then automatically unhide
      the menu. Otherwise, if GRUB_HIDDEN_TIMEOUT is 0, then use keystatus
      if available to check whether Shift is pressed. If it is, show the
      menu, otherwise boot immediately. If keystatus is not available, then
      fall back to a short delay interruptible with Escape.
    - Allow Shift to interrupt 'sleep --interruptible'.
    - Don't display introductory message about line editing unless we're
      actually offering a shell prompt. Don't clear the screen just before
      booting if we never drew the menu in the first place.
    - Remove some verbose messages printed before reading the configuration
    - Suppress progress messages as the kernel and initrd load for
      non-recovery kernel menu entries.
    - Change prepare_grub_to_access_device to handle filesystems
      loop-mounted on file images.
    - Ignore devices loop-mounted from files in 10_linux.
    - Show the boot menu if the previous boot failed, that is if it failed
      to get to the end of one of the normal runlevels.
    - Handle RAID devices containing virtio components.
    - Don't generate /boot/grub/ during grub-install or
      grub-mkconfig by default.
    - Adjust upgrade version checks for Ubuntu.
    - Don't display "GRUB loading" unless Shift is held down.
    - Adjust versions of grub-doc and grub-legacy-doc conflicts to tolerate
      our backport of the grub-doc split.
    - Fix LVM/RAID probing in the absence of /boot/grub/
    - Look for .mo files in /usr/share/locale-langpack as well, in
    - Make sure GRUB_TIMEOUT isn't quoted unnecessarily.
    - Probe all devices in 'grub-probe --target=drive' if
      /boot/grub/ is missing.
    - Adjust hostdisk id for hard disks, allowing grub-setup to use its
      standard workaround for broken BIOSes.
    - Build-depend on qemu-kvm rather than qemu-system for grub-pc tests.
    - Use qemu rather than qemu-system-i386.
    - Extend the EFI version of grub-install to be able to install into an
      EFI System Partition mounted on /boot/efi in a location that complies
      with the EFI specification.
    - Upgrade the installed core image when upgrading grub-efi-ia32 or
      grub-efi-amd64, although only if /boot/efi/EFI/ubuntu already exists.
    - Make grub-efi-ia32 and grub-efi-amd64 depend on efibootmgr so that


Changed in grub2 (Ubuntu):
status: In Progress → Fix Released

Yep, that certainly fixed it on my system.
Maverick now happily finishing its daily updates and and adding/removing
kernels as I wish.

Thanks guys!


Leo Richard Comerford (lrc1) wrote :

I encounter apparently the same problem when trying to perform a fresh install either of 10.4.1 or of 10.10 beta. The Debian installer fails to detect a four-disk RAID5 on an ASUS M4N78 Pro motherboard (BIOS v. 1205). (The disks in the RAID5 do not show up individually and no other HDDs are installed, so no disks were detected. debian-installer itself also fails to handle this error condition correctly, showing me the Partition disks screen with no disks listed and offering me the two options "Undo changes to partitions" and "Finish partitioning and write changes to disk".) It also fails to detect the disks when set up as two two-disk RAID1s, failing in a different fashion. Installs onto RAID5 using the 22 Sep. daily of 10.10 fail in the same manner as 10.4.1, 10.10 beta and several previous 10.10 dailies. (Actually, I seemed to get a different form of install failure the first time I tried the 22 Sep. alternate install CD, but I can't reproduce it. I can't explain the discrepancy; parted didn't seem to show anything written to the disks after that attempt.)

Logs from failed installations follow.

Leo Richard Comerford (lrc1) wrote :

Logs from failed installation as above, this time using Ubuntu 10.4.1 and the four-disk RAID5 setup.

Leo Richard Comerford (lrc1) wrote :

Logs from failed installation as above, this time using the Ubuntu 10.10 daily from 19 September and the four-disk RAID5 setup.

Leo Richard Comerford (lrc1) wrote :

Logs from failed installation as above, this time using the Ubuntu 10.10 daily from 22 September and the four-disk RAID5 setup.

Leo Richard Comerford (lrc1) wrote :

Logs from failed installation as above, this time using Ubuntu 10.4.1 and two separate mirrored pairs.

Phillip Susi (psusi) wrote :

Leo, your issue is unrelated to this bug report. This report is about grub failing to install on fake raid devices.

This patch also has fixed grub for me, the 9/22 daily now installs fine.

Leo Richard Comerford (lrc1) wrote :

You're right, it's pretty clearly not related to grub. My apologies.

Changed in grub2 (Debian):
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.