Installer fails: grub fails on Intel ICH10 raid

Bug #436340 reported by Billy Charlton
98
This bug affects 18 people
Affects Status Importance Assigned to Milestone
ubuntu-meta (Ubuntu)
Fix Released
Undecided
Colin Watson
Nominated for Karmic by keteflips
Nominated for Lucid by keteflips

Bug Description

Installing Karmic x86 livecd image (23-Sep-09 nightly).
Dell OptiPlex 960, 4Gb RAM, with Intel ICH10 fakeraid setup with Windows XP (RAID 1).

1) I resized NTFS partition to make 20Gb of room for Ubuntu.
2) Run Karmic installer, it sees fakeraid correctly, and I choose Manual partitioning, creating ext4 on new partition.
3) Installer goes thru entire installation, but fails on grub step with following error:

"Grub package failed to install into /target. Without GRUB boot loader, the installed system will not boot."

4) I tried opening a terminal as su, and ran
  grub-install --root-directory=target /dev/mapper/isw_bfdafeice_ARRAY (which is the correct mapped disk, I believe) and it fails with "grub-probe: error: no mapping exists for isw_bfdafeice_ARRAY5". Auto detection of a filesystem module failed.

5) Then I tried
  grub-install --module=ext4 --root-directory=target /dev/mapper/isw_bfdafeice_ARRAY
and it fails with, "You attempted a cross-disk install, but the filesystem containing target/boot/grub does not support UUIDs".

So, left with a system that won't install GRUB so I can't boot. Happy to provide more detail.

affects: ubuntu → grub2 (Ubuntu)
Revision history for this message
Billy Charlton (billy) wrote :

(Edited initial post for clarity).

Note also that I only tried steps 4 and 5 above because I thought maybe the ext4 had something to do with it. I'll try the same install using ext3 and see if it makes a difference -- the filesystem type is likely a red herring but I want to be sure.

description: updated
Revision history for this message
Colin Watson (cjwatson) wrote : Re: [Bug 436340] Re: Installer fails: grub fails on Intel ICH10 raid

Could you attach the installer syslog (should be in /var/log/syslog
after the failed installation but before reboot)? Right now, it's
supposed to use GRUB Legacy in the dmraid case, but clearly isn't for
you; I'd like to know why not.

Revision history for this message
Billy Charlton (billy) wrote :

Syslog attached. Relevant lines at bottom of file: looks like it couldn't find/install "grub".

-----

ubuntu grub-installer: info: architecture: i386/generic
Sep 29 14:25:27 ubuntu grub-installer: info: Identified partition label for /dev/mapper/isw_bfdafeice_ARRAY5: loop
Sep 29 14:25:28 ubuntu grub-installer: (Reading database ...
Sep 29 14:25:28 ubuntu grub-installer: 110163 files and directories currently installed.)
Sep 29 14:25:28 ubuntu grub-installer: Removing grub-pc ...
Sep 29 14:25:28 ubuntu grub-installer: Purging configuration files for grub-pc ...
Sep 29 14:25:29 ubuntu grub-installer: Processing triggers for man-db ...
Sep 29 14:25:30 ubuntu ubiquity: Reading package lists...
Sep 29 14:25:30 ubuntu ubiquity:
Sep 29 14:25:30 ubuntu ubiquity: Building dependency tree...
Sep 29 14:25:30 ubuntu ubiquity:
Sep 29 14:25:30 ubuntu ubiquity: Reading state information...
Sep 29 14:25:30 ubuntu ubiquity:
Sep 29 14:25:30 ubuntu ubiquity: Package grub is not available, but is referred to by another package.
Sep 29 14:25:30 ubuntu ubiquity: This may mean that the package is missing, has been obsoleted, or
Sep 29 14:25:30 ubuntu ubiquity: is only available from another source
Sep 29 14:25:30 ubuntu ubiquity: E:
Sep 29 14:25:30 ubuntu ubiquity: Package grub has no installation candidate
Sep 29 14:25:30 ubuntu ubiquity:
Sep 29 14:25:30 ubuntu grub-installer: info: Calling 'apt-install grub' failed

Revision history for this message
Ian Hutchinson (ianhutchinson) wrote :

I'd like to bump this, it'll stop folks with RAID configurations from being able to use Karmic.

Revision history for this message
Jim Bailey (jim-freesolutions) wrote :

I have exactly the same issue Intel Raid on an Asus MB uninstallable.

Revision history for this message
Crosshair (will-e-carlson) wrote :

Confirmed here. I have the same problem for x86_64 karmic. I have a separate raid1 that isn't even in / and it just hangs when grub starts to load. Someone needs to mark this as high importance, because it is a show stopper.

Revision history for this message
Crosshair (will-e-carlson) wrote :

Oh, and I am running the ICH9 intel raid. Please don't get off topic about the pitfalls of this type of fake raid, I like it and use it a lot.

Revision history for this message
RedBass (redbass) wrote :

Same:
Fake raid on a Moderboard MSI, nVidia Raid Controller MCP55.

I had try to install Ubuntu 9.10 (alternate and server), but i can't install Grub.

If i install 9.04 (server) and then upgrade to 9.10... all works, but i cant upgrade to Grub2

Revision history for this message
Ian Hutchinson (ianhutchinson) wrote :

I did a virtual machine in VirtualBox that had 2 hard drives, and I tried an installlation using the linux software RAID provided by the mdadm package, and will a bit of extra legwork, it managed to boot the RAID0 system using grub2.

I dunno if the kinda setup you guys and girls have needs to keep to the Intel ICH10 raid, but for me, I'm not too fussed and this is a do-able solution. On the real computer, it just means backing up everything, removing the Intel BIOS raid, and setting it up in Ubuntu as a mdadm software RAID..

Any thoughts?

Revision history for this message
Jim Bailey (jim-freesolutions) wrote :

Not an good idea for me I have a reasonably high end Windows Vista install on another partition I use the raid for. This is something that need fixing pre-release, most ASUS high end gamer boards have this kind Raid and I believe most of the Biostar and ECM boards.

What I really need to see is someone from the grub2 team to triage this bug but with 137 and counting open bugs against grub2 and 2 weeks to release I am quite worried.

Revision history for this message
Felix Zielcke (fzielcke) wrote : Re: [Bug 436340] Re: Installer fails: grub fails on Intel ICH10 raid

Am Dienstag, den 13.10.2009, 17:20 +0000 schrieb Jim Bailey:
>
> What I really need to see is someone from the grub2 team to triage this
> bug but with 137 and counting open bugs against grub2 and 2 weeks to
> release I am quite worried.

I know the problem since a few months and even sent a first patch in
June for my nvidia dmraid devices to upstream.

But the problem is that the internal design used by grub-probe to map
Linux devices to GRUB devices doestn't work with any non real harddisk
devices like dmraid and multipath.
For LVM/mdraid we don't need to do this as we have native support for
them.

That discussion is here:
http://lists.gnu.org/archive/html/grub-devel/2009-07/msg00509.html
http://lists.gnu.org/archive/html/grub-devel/2009-08/msg00065.html
For me this is just not a high priority.

--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Revision history for this message
Billy Charlton (billy) wrote :

Still fails on Oct 13th cd image.

Happy to test further if a patch gets committed. From RedBass' comment #8 above it sounds like the only workaround so far is to install 9.04 and then perform an upgrade.

*sigh* this bug is a huge bummer since it permanently prevents anyone from installing Karmic who has a stock desktop PC running RAID1 (as mine was set when received from the factory). I say permanently because no post-release fixes will make it onto the install CD. Erasing the hard drive and removing RAID isn't an option; that would require removing Windows, programs, and user data from the other side. A tough pill to swallow!

Revision history for this message
Jim Bailey (jim-freesolutions) wrote :

Thanks for the reply Felix,

it doesn't help me but at least I understand some of the reasoning behind this. I guess karmic gets a thumbs down from me based on this regression alone. At lot of people installing Karmic for the first time, are going to get the hump when there install fails at the last hurdle. I wonder if the possibility of using grub1 can be included in the installer.

Revision history for this message
Felix Zielcke (fzielcke) wrote :

Am Mittwoch, den 14.10.2009, 09:51 +0000 schrieb Jim Bailey:
> I wonder if the possibility of using grub1 can be included in
> the installer.

For dmraids always GRUB Legacy was forced inside grub-installer and this
hasn't change even since Debian switched to GRUB 2 by default too.
But it seems that at least in Ubuntu this has become broken.
I don't know for Debian.
Comment #3 in this report looks like GRUB Legacy has been excluded from
the CD.

--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Revision history for this message
Colin Watson (cjwatson) wrote :

Indeed, I think it's just that grub is no longer on the CD. That wasn't intentional as we need it for this and other reasons; I've committed a fix.

Revision history for this message
Colin Watson (cjwatson) wrote :

revno: 1584
committer: Colin Watson <email address hidden>
branch nick: ubuntu.karmic
timestamp: Wed 2009-10-14 21:40:44 +0100
message:
  ensure that grub is shipped on live CDs, since it's needed for dmraid (LP: #436340)

affects: grub2 (Ubuntu) → ubuntu-meta (Ubuntu)
Changed in ubuntu-meta (Ubuntu):
assignee: nobody → Colin Watson (cjwatson)
status: New → Fix Released
Revision history for this message
Jim Bailey (jim-freesolutions) wrote :

This is good news I will Test and report at the weekend.

Revision history for this message
ozbird (ozbird) wrote :

I struck the same problem with the 19 October daily build of karmic-alternate-amd64.iso (I didn't try the livecd.)

During the installation, grub2 (grub-pc) was installed - not grub - and failed to detect the dmraid devices as above.

Booting into rescue mode. Was asked if I wanted to initialise the SATA raid devices (yes), but received the error "The installer could not find any partitions"; it found the existing partitions during the installation process. Opened a shell; dmraid and /dev/mapper were configured correctly. Set up the chroot environment, removed grub-pc and installed grub.

I eventually got grub to install correctly, but running update-grub created the menu.lst file with an extra comma on each of the root device definitions e.g. "(hd0,2,)". Script bug? (I tried to report it via ubuntu-bug, but it fails with it's own bug!)

Revision history for this message
Colin Watson (cjwatson) wrote : Re: [Bug 436340] Re: Installer fails: grub fails on Intel ICH10 raid

On Tue, Oct 20, 2009 at 01:54:24PM -0000, Paul Taylor wrote:
> I struck the same problem with the 19 October daily build of karmic-
> alternate-amd64.iso (I didn't try the livecd.)

Oh dear. Could you attach /var/log/installer/syslog, please?

Revision history for this message
My Name (thisismyusername799-deactivatedaccount) wrote :

Somewhat Related....

I used the 9.10 Alt CD on my machine with ICH10 Raid 1 (Mirrored).

Installed Ubuntu to another drive. (the RAID array is just file storage)

Upon installing, it asked if I wanted to use the RAID hardware...I said yes.

after installing, Ubuntu still sees these as separate drives.

Worked fine with 8.04. Odd

Revision history for this message
Colin Watson (cjwatson) wrote :

On Sat, Oct 31, 2009 at 09:01:17PM -0000, rkolb86 wrote:
> Somewhat Related....

Not really - it's another bug with the same kind of hardware, certainly,
but not a bug in grub. Please file a separate report.

Revision history for this message
Marc Nieper-Wißkirchen (marc-nieper-wisskirchen) wrote :

I do have the same problem here. I have upgraded from Jaunty to Karmic. "apt-get install grub2" quits with the following error:

grub-probe: error: no mapping exists for `isw_eceeeacaf_diskset1'.

As much I would like to see this error properly fixed, is there an alternative fix, e.g. by specifying a proper mapping by hand?

Revision history for this message
Colin Watson (cjwatson) wrote :

On Mon, Nov 09, 2009 at 08:33:11AM -0000, Marc Nieper-Wißkirchen wrote:
> I do have the same problem here. I have upgraded from Jaunty to Karmic.
> "apt-get install grub2" quits with the following error:
>
> grub-probe: error: no mapping exists for `isw_eceeeacaf_diskset1'.
>
> As much I would like to see this error properly fixed, is there an
> alternative fix, e.g. by specifying a proper mapping by hand?

The solution in Ubuntu 9.10 is: *don't install grub2*. Continue to use
GRUB Legacy if you're using SATA RAID devices, since it's the only
version that will work in 9.10.

This bug was filed because the installer wasn't automatically selecting
GRUB Legacy on these devices. That bug is now fixed.

Revision history for this message
Paradigm (paradox) wrote :

its great we can run 9.10 with grub legacy, however are we ever going to see grub 2 working with fake raid partitions?

Revision history for this message
Colin Watson (cjwatson) wrote :

On Sat, Nov 28, 2009 at 04:46:02PM -0000, Charlie Burnett wrote:
> its great we can run 9.10 with grub legacy, however are we ever going to
> see grub 2 working with fake raid partitions?

I expect it'll work in 10.04 - Felix recently mentioned upstream that
he's got it working.

Revision history for this message
Miek Gieben (miek) wrote :

With lucid alpha3 (alternate) installer this is still a problem. I'm looking a the exact error (UUIDs not supported) right now

Revision history for this message
Miek Gieben (miek) wrote :

I'm if I mount /proc in the chroot is seems to work:

chroot /target
mount /proc
grub-install --modules=raid /dev/sda

Revision history for this message
David Tomlin (davetomlin) wrote :

This is still an issue in Ubuntu 10.04 Beta as well.

Revision history for this message
Colin Watson (cjwatson) wrote :

Wouldn't that be bug 527401, which is fixed in later daily builds?

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

I'm working to remove grub1 from the seeds, and I'm now wondering if this is still the case. I.e. if we can drop grub1, and only have grub2 for e.g. fakeraid installs et.al. Wouldn't this support be visible in like installer changes too?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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