karmic server 64 bit installer fails at GRUB when installing with RAID1

Bug #485604 reported by Huuanito on 2009-11-20
This bug affects 12 people
Affects Status Importance Assigned to Milestone
grub-installer (Ubuntu)

Bug Description

Binary package hint: ubiquity

'lsb_release -rd Description: Ubuntu 9.10, Release: 9.10
Linux 2.6.31-14-server #48-Ubuntu SMP Fri Oct 16 15:07:34 UTC 2009 x86_64 GNU/Linux

when installing karmic server 64 bit with RAID1 installer always fails at installing GRUB.
Tried on three different mobos, one amd 64 bit, one with intel core 2 and one with ICH10 and intel i7
 all fail at the same step.

download ubuntu 9.10 server (2.6.31-14-server)
do checksum against the downloaded image
burn image on cd
boot to cd
check cd
run install ubuntu

set ip etc
set tz

choose manual
partition sda
 #1 6gb beginning, use as: physical volume for RAID
 #2 100 gb beginning, use as: physical volume for RAID

(attempts to set bootable flag on here failed)

partition sdb
 #1 6gb beginning, use as: physical volume for RAID
 #2 100 gb beginning, use as: physical volume for RAID

move back up the menu to "Configure software RAID"
answer Yes to "write changes to the storage devices and configure RAID"
Create MD device choose RAID1, 2 devices,0 spares
/dev/sda1 (6000MB; raid)
/dev/sdb1 (6000MB; raid)
press enter
Create MD device choose RAID1, 2 devices,0 spares
/dev/sda2 (100000MB; raid)
/dev/sdb2 (100000MB; raid)
press enter
Finish <enter>
(|starting up the partner| scanning disks…)

Choose RAID1 device #0 - 6.0 GB Software RAID device
         #1 6.0 GB
select use as: swap area
Choose RAID1 device #1 - 100.0 GB Software RAID device
         #1 100.0 GB
  use as: ext4 journaling file system
  mount point: /

*Select "Finish partitioning and write changes to disk" <enter>
*Select 'Yes" to "Do you want to boot your system if your RAID becomes degraded?"

*Select "Yes" to "write the changes to disks?"

creating ext4 file system on …

installing the base system…

*enter username, password for new user
*encrypt home <no>
*configuring apt..
*HTTP proxy <blank>
configuring apt
retrieving (28 files)

*select and install software
  no automatic updates
retrieving file 1of 3…
choose software to instal. <don't choose any>
retrieving file 1of 142…
97% cleaning up…

installing grub2 package
retrieving file 1 of 3

Configuring grub-pc
Unable to install GRUB in /dev/sda
Executing 'grub-install /dev/sda failed.
This is a fatal error.
What I expected to happen:
GRUB would install and then a reboot would take me into the new system
After reading this bug https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/436340 I tried regular grub but same outcome.
I think the fix from that bug may have only been applied to the desktop version as grub2 was in the installer I used.

But from there I found where to look for the logs and found in the syslog these lines here:
Nov 19 18:59:05 grub-installer: grub-setup: warn: This GPT partition label has no BIOS Boot Partition; embedding won't be possible!
Nov 19 18:59:05 grub-installer: grub-setup: error: Embedding is not possible, but this is required when the root device is on a RAID array or LVM volume.
 so I think this is related to a doc bug I filed before doing all thhe above https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/477167

From that error I figured I could use a separate non-RAID /boot with the bootable flag set then the install went flawlessly. However that route requires a bunch of tweaking to get the system booting from both drives.

attached is the syslog, I'll add partman in the next comment as this post only allows on attachment
Note that the logs attached are for a slightly different partition layout but the results for the RAID test case which is what I described above were exactly the same.

Huuanito (jonnykent) wrote :
Huuanito (jonnykent) wrote :
Huuanito (jonnykent) wrote :

I also tried an install using lucid server 64 bit from a latest cd downloaded yesterday 11/18/2009 lucid-server-amd64.iso
same result

mcof32 (mcofaptudvsi) wrote :
Download full text (3.3 KiB)

I can confirm this doesn't work. There appears to be a regression between Ubuntu 9.10 and Ubuntu 9.04 when installing to a software RAID 1 according to the directions in the Ubuntu Server Guide (https://help.ubuntu.com/9.10/serverguide/C/advanced-installation.html).

==Repro case (as above and in the Server Guide)==

1. Assume two physical devices

     - /dev/sda
     - /dev/sdb

2. Boot from ubuntu-9.10-server-amd64.iso

3. Select defaults for [keyboard, time, configure via DHCP, etc]

4. Create partition tables on /dev/sda and /dev/sdb

5. Create two partitions

     - 20 GB, /dev/sda1, physical volume for RAID
     - 20 GB, /dev/sdb1, physical volume for RAID

6. Select "Configure Software RAID", "Create MD drive", "RAID1" using "/dev/sda1" and "/dev/sdb1"

7. Select RAID1 device #0 partition ("/dev/md0"), use as "Ext3 journaling file system", mount as "/ - the root file system"

8. Continue installing base system, mostly just selecting defaults [no swap, write changes to disk, etc]

9. When asking where to install GRUB the default is "/dev/md" and that is what worked for 9.04 (saying "/dev/md0" doesn't seem to work for 9.04). The error is "Executing 'grub-install /dev/md' failed. This is a fatal error." I've tried:

     - /dev/md => "Executing 'grub-install /dev/md' failed. This is a fatal error."
     - /dev/md0 => "Executing 'grub-install /dev/md0' failed. This is a fatal error."
     - /dev/sda => "Executing 'grub-install /dev/sda' failed. This is a fatal error."
     - /dev/sda0 => "Executing 'grub-install /dev/sda0' failed. This is a fatal error."
     - (hd0) => "Executing 'grub-install (hd0)' failed. This is a fatal error."
     - (hd0,0) => "Executing 'grub-install (hd0,0)' failed. This is a fatal error."

All of them yield the same error.


Ubuntu 9.04 uses legacy GRUB (0.97) while Ubuntu 9.10 uses GRUB2. The following is the working legacy GRUB configuration the 9.04 installer creates.

############### menu.lst #################

## default num
# Set the default entry to the entry number NUM. Numbering starts from 0, and
# the entry number 0 is the default if the command is not used.
default 0

## timeout sec
# Set a timeout, in SEC seconds, before automatically booting the default entry
# (normally the first entry defined)
timeout 3

## hiddenmenu
# Hides the menu by default (press ESC to see the menu)

## ## End Default Options ##

title Ubuntu 9.04, kernel 2.6.28-11-server
root (hd0,0)
kernel /boot/vmlinuz-2.6.28-11-server root=/dev/md0 ro quiet splash
initrd /boot/initrd.img-2.6.28-11-server

title Ubuntu 9.04, kernel 2.6.28-11-server (recovery mode)
root (hd0,0)
kernel /boot/vmlinuz-2.6.28-11-server root=/dev/md0 ro single
initrd /boot/initrd.img-2.6.28-11-server

title Ubuntu 9.04, memtest86+
root (hd0,0)
kernel /boot/memtest86+.bin


############## end of menu.lst #####################

Huuanito--You might try using Intel Matrix RAID (or whatever version of fakeRAID your mobo supports) at least for the /boot partition. You would need to use the DVD or server CD (e.g. ubuntu-9.10-dvd-amd64.iso or ubuntu-9.10-server-amd64.iso). The...


mcof32 (mcofaptudvsi) on 2009-11-22
tags: added: grub installation karmic raid software
Aiman Baharna (aiman) on 2009-11-29
Changed in lucid:
status: New → Invalid
Colin Watson (cjwatson) on 2009-12-02
affects: ubiquity (Ubuntu) → grub-installer (Ubuntu)
Jakob Unterwurzacher (jakobunt) wrote :

This looks like it was the same problem as bug #506670 - there is no warning that you have to create a BIOS boot partition (or that we are using GPT at all).

matt (matthiasgies) wrote :

I think this bug is not a duplicate and should receive more attention.

Bug #506670 only talks about adding a warning to remind the user of creating a boot partition.
But why would I want to use a boot partition seperate from my RAID? I'd like to have it in the RAID.

This used to work with old GRUB, why the change with the new one?

Agreeing with matt, this should not be labeled as a duplicate!
This bug is stopping me from using any form of software RAID!
I could put /boot outside of the RAID and / inside the raid and still be affected by this bug. :(

This problem is also showing up in Debian Sid and Testing, so fixing this bug would be helpful to Debian users too. :)

ceg (ceg) wrote :

can you identify this with Bug #527401 maybe?
why should this be invalid in lucid (grub2 also)?

Invalid in lucid: somebody mistakenly opened a task against the lucid
*project*, which is not the same as the Lucid release of Ubuntu.

Huuanito (jonnykent) wrote :

re comment #4
Thanks for the suggestions but I already have a workaround with the script mirroring of /boot.
I tried many times to use LILO for RAID1 on 9.10 server 64 bit but it would not work on the i7 mobo which was my initial target. LILO worked fine for an AMD mobo. Thanks though.

re comment #8
Bug #527401 says
"While trying to install a raid5 with /boot on raid1 system using preseed, grub-install fails to install correctly:"
I can't say I understand the jargon there... so it is not clear to me that bug is not to do with a failed install on an existing RAID1 array. If not then maybe it is a dup of this bug.

re comment #9
Colin, that would be me. My apologies.
Before filing the bug I tried the same install using the latest Ubuntu 10 Lucid 64-bit install disk I could find at the time and it failed there also.

I did not understand the difference between "Lucid project" and "Lucid release of Ubuntu" at the time I entered the bug and I'm not sure I do now either. Sorry.

I'm attempting to install to an Acer Aspire One netbook. I've tried multiple setups, but in this instance I'm not using a RAID partition at all, just the 8 gb SSD drive that comes standard in the netbook. Attempting to install from ubuntu-9.10-netbook-remix-i386.iso downloaded today from one of the FTP sites and loaded on a 2 gb USB stick to do installation, I get all kinds of failures using ext2, ext3, ext4 related to bug #452208. Attempts to reformat using JFS result in the same behavior as above, getting 94% through the installation and then failing with the following messages: Window will pop up titled "Unable to install GRUB in /dev/sda" with a detailed message of "Executing 'grub-install /dev/sda' failed. This is a fatal error."
Don't mean to rant, but I'm about damned ready to abandon Ubuntu for a different distribution after all of these problems. I've wasted a damned good portion of the last 24 hours fighting with the installer and these issues. Does anyone have any kind of workaround that might get grub installed?
Please let me know if anyone needs more information.

Further update re: my comments above. Got email from mcof suggesting a dd if=/dev/zero of=/dev/sda bs=128k to wipe the drive and had a very successful install after that. No worries now, and thanks to mcof for the help.

Aiman Baharna (aiman) on 2010-03-29
affects: lucid → launchpad
affects: launchpad → null
Alan Krause (alan-krause) wrote :

Just another note that I also tried installing lucid in a software RAID 1 configuration, and receive the error message when the installer tries to install grub2.

I successfully installed lucid w/out software RAID, but as this is for a new server, I'm a bit stuck for the moment.

Huuanito (jonnykent) wrote :

re #13 don't be stuck Alan. Another workaround is to put /boot on a memory stick and have everything else on RAID. works a treat

Curtis Hovey (sinzui) on 2011-11-11
no longer affects: null
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in grub-installer (Ubuntu):
status: New → Confirmed
w2vy (tom-moulton) wrote :

Windows XP system with two 300gb disks.
They were raid1, due to performance issues the second disk was removed from the raid
installing 14.04 installer does not find windows, so as per some suggestions i
apt-get remove dmraid

re run install and windows is seen and installs system on second (empty) disk

grub-install /dev/sda fails

I tried adding dmraid back in and it fails

when I try from shell I get

root@ubuntu:/etc/default# grub-install /dev/sda
Installing for i386-pc platform.
grub-install: error: failed to get canonical path of `/cow'.

Will reboot and try to boot new install and reinstall grub

Phillip Susi (psusi) wrote :

9.10 reached end of life some time ago and is no longer supported.

Changed in grub-installer (Ubuntu):
status: Confirmed → Invalid
Changed in grub-installer:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers