Cannot install grub2 on dmraid with text-mode installer

Is this bug still a problem in beta? I do not see any comments upstream that would indicate it has been fixed...

Sure, it's still a problem in beta.

grub-installer now installs grub legacy rather than grub2 on dmraid systems, as was previously intended. Getting it all working with grub2 will have to wait for a future release.

Can I test it with Daily Build CD?

Yes, all the necessary fixes have been in daily builds for a few days
now.

(Just adding some more information)

I ran into an issue on a system with a fake-raid on the first few SATA hard drives, followed by stand-alone SATA drives. The target install is on the stand-alone SATA drives, and not on the fake-raid.

When attempting to install grub2 using the default hard drive selection, the system doesn't boot and errors in grub 1.5 stage with error 15. The install for 9.04 worked with the default drive selection, but the system had a different grub 0.97 setup on the fake-raids' boot-sector. The boot-sector was damaged by the grub2 install with 9.10 but fake-raid setup and data is still intact.

I fixed it by directing the Ubuntu Install to install grub2 on the stand-alone hard drive instead of the default hard drive selection. My BIOS supports selecting the boot-order for the hard disks, and my system boots fine now with grub2. My fake-raid contents were undamaged.

problem still exists with karmic final amd64 alt install disk (confirmed with my sager software (fake) raid 0 config the disk used dmraid. tried to install on a partition (hd 0,4) with windows 7 home premium on the other one. it crashes at 16% try to go to install menu and click the dont install boot loader option (or something like that) and it loops back to try again (and crash again, repeat and so on and so forth), only option in alt install disk is to abort install (haven't tried spawn a shell, and i don't want to screw with lilo). any ideas (really want to get this installed by thanksgiving.)

thanks in advanced

Also want to confirm that the problem still exist with Ubuntu 9.10 as with Ubuntu 10.04 daily builds. When installing with the alternative installation it still cannot continue at the part of installing the boot loader. Which is Grub2 and not Grub. Installing Ubuntu 9.04 works as a charm which uses Grub.

System used: Via (Fake)Raid with raid 1

Le 27/01/2010 20:31, woolysheep a écrit :
> Also want to confirm that the problem still exist with Ubuntu 9.10 as
> with Ubuntu 10.04 daily builds. When installing with the alternative
> installation it still cannot continue at the part of installing the boot
> loader. Which is Grub2 and not Grub. Installing Ubuntu 9.04 works as a
> charm which uses Grub.
>
> System used: Via (Fake)Raid with raid 1
>
>
thank for this report._
_When booting XP with an array ins RAID0+1although it was'nt a true RAID
(because of it is a soft Raid) it is clearly faster to start the
operating system and the recording and reading disk time seems to be
really lower... So I was thinking it will be possible an advantageous to
start from the array with Linux.... unfortunately you say that it's
impossible with Grub....

I've got another problem with Grub (the array is now disabled in the
bios) it's that it take a long time to start ( 3 or 4 minutes...) is it
normal ?

Thanks for your effort in promoving open source operating system..

Tony

I can confirm this bug in Ubuntu 10.04 beta1 alternate cd, installing on a ATI SB600 fakeraid (raid0 formed by /dev/sda and /dev/sdb). Grub installer fails trying to install the boot loader on the first disk of the array (/dev/sda), instead of the array /dev/mapper/pdc_xxxxxxx.

From the logs (attached syslog.gz) it seems that grub-install cannot map the boot device due to missing device.map. There are also many errors related to failed access to /proc which is not mounted inside /target.

I can successfully install grub2 manually on the fakeraid array following these steps:
1) create /target/boot/device.map containing "(hd0) /dev/mapper/pdc_xxxxxxx"
2) mount /proc inside target with "mount -o bind /proc /target/proc"
3) run "chroot /target grub-install /dev/mapper/pdc_xxxxxxx"
4) run "chroot /target update-grub"

Also update-grub cannot find my Windows partition, but re-running the command after booting in Lucid solves the problem.

grub-installer 1.49ubuntu7
grub-pc 1.98-1ubuntu1

is there a way of fixing the package itself rather than fixing it via diving into the partition? if its just a matter of adding text to a file, tell me how, I have too much free time, so i might as well fix it.

I had this bug today when trying to install 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.

Luckily I had already found and used the workaround as described above in #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 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

Update:
See also my post in LP:631795.
Yesterday I had to try some combo of software that would not install on Lucid together. So I got adventurous and did a two-stage upgrade of my testing system from Lucid to Maverick and then on to Natty. This is the machine with an Intel chipset and 2 disks in mirror set. (The other one has a Promise Fasttrack and 2 discs in a striped set.)

Grub did not install on the right device twice, so I had to boot off an USB-stick to rescue a broken system and reinstall it manually from a root shell. That fixed it for me, but I would have expected the installer to
- find the active raid set (I did activate it manually earlier on in the process)
- use the existing configuration (this was an upgrade)
- ask me where to boot from (well it sort of did, but whatever I pointed it to, it went back to /sda)
As things are now Grub / Grub-installer has been breaking installations on dmraid reliably in Lucid, Maverick and Natty.
I think this may be related to several issues in Gparted and dmraid on same machines where name convention for devices and partitions is not consistent.

If there's anything I need to check and report back here, let me know.

cheers
Tom

update

Installed Oneiric from CD onto one of my machines with dmraid (theone with the Promise Fasttrak100 chipset). The live CD found all partitions OK and offered to upgrade the existing 10.10 Maverick installation. So far, so good.

At the end of the process grub-installer tried to set up grub on sda. No luck, but it did come up with a screen asking me where I would like to see grub. At that moment I was happy and confident things would go right, since the pull down menu showed all the right entries.
I chose /dev/mapper/pcb_jcchiiab, which is the raid set's mbr as opposed to one of the partitions.
The installer obliged -it seemed- and finished without further messages.

Alas, after rebooting I got a grub shell prompt. It seems the installation did not replace the part of grub living in the MBR, so it does not load the stage that actually boots my OS.
I'll try and get into a root shell and reinstall manually, that did help me out before.

Will report back and let you know.

cheers
Tom