update-grub doesn't work correctly with raid partitions

Bug #46223 reported by Giuseppe Iuculano on 2006-05-23
24
Affects Status Importance Assigned to Milestone
grub (Ubuntu)
Medium
Unassigned

Bug Description

Hi,

this is my /etc/fstab

/dev/md0 / ext3 defaults,errors=remount-ro 0 1
/dev/md2 /home reiserfs defaults 0 2

and this is fdisk -l

Disk /dev/sda: 163.9 GB, 163927522816 bytes
255 heads, 63 sectors/track, 19929 cylinders
Units = cilindri of 16065 * 512 = 8225280 bytes

Dispositivo Boot Start End Blocks Id System
/dev/sda1 * 1 4863 39062016 7 HPFS/NTFS
/dev/sda2 4864 19929 121017645 5 Esteso
/dev/sda5 * 4864 7295 19535008+ fd Autorilevamento raid di Linux
/dev/sda6 7296 7441 1172713+ fd Autorilevamento raid di Linux
/dev/sda7 7442 19929 100309828+ fd Autorilevamento raid di Linux

Disk /dev/sdb: 163.9 GB, 163927522816 bytes
255 heads, 63 sectors/track, 19929 cylinders
Units = cilindri of 16065 * 512 = 8225280 bytes

Dispositivo Boot Start End Blocks Id System
/dev/sdb1 * 1 4863 39062016 7 HPFS/NTFS
/dev/sdb2 4864 19929 121017645 5 Esteso
/dev/sdb5 * 4864 7295 19535008+ fd Autorilevamento raid di Linux
/dev/sdb6 7296 7441 1172713+ fd Autorilevamento raid di Linux
/dev/sdb7 7442 19929 100309828+ fd Autorilevamento raid di Linux

This is my cat /proc/mdstat
Personalities : [raid0] [raid1]
md2 : active raid1 sda7[0] sdb7[1]
      100309760 blocks [2/2] [UU]

md1 : active raid0 sda6[0] sdb6[1]
      2345216 blocks 64k chunks

md0 : active raid1 sda5[0] sdb5[1]
      19534912 blocks [2/2] [UU]

On sda1 I' ve windows, so the Ubuntu root / is md0, raid1 with sda5 and sdb5.

When I do an update-grub. I have in /boot/grub/menu.lst:

title Ubuntu, kernel 2.6.15-23-686
root (hd0,0)
kernel /boot/vmlinuz-2.6.15-23-686 root=/dev/md0 ro quiet splash
initrd /boot/initrd.img-2.6.15-23-686

So update-grub writes root (hd0,0), but the correct value should be (hd0,4), because sda1 is a NTFS partition with windows... Why does it write (hd0,0) ?

Regards

MK (mk1970g) wrote :

I confirm this (the bug exists at least in 6.06.1 and 6.10).

I just installed a new machine with two disks and with the following partitions:

sda1 NTFS sdb1 ext3 ==> used as /data
sda2 RAID sdb2 RAID ==> md0 used as /
sda3 RAID sdb3 RAID ==> md1 used as swap
sda4 RAID sdb4 RAID ==> md2 used as /home

After installation menu.lst has this invalid entry, i.e. (hd0,0) should be (hd0,1):

title Ubuntu, kernel 2.6.17-10-generic
root (hd0,0)
kernel /boot/vmlinuz-2.6.17-10-generic root=/dev/md0 ro quiet splash locale=fi_FI
initrd /boot/initrd.img-2.6.17-10-generic
quiet
savedefault
boot

I had to edit the root entry before first successfull boot. Then I modified menu.lst to use the correct entry and now everything is okay. This might, however, be VERY confusing for newbies...

Changed in grub:
status: Unconfirmed → Confirmed
Tormod Volden (tormodvolden) wrote :

Make sure that your menu.lst has correct #kopt and #groot entries. Can you please attach your menu.lst?

Changed in grub:
status: Confirmed → Needs Info

I set groot=(hd0,4), but update-grub delete it and add a commented groot=(hd0,0)

Attachment is the good menu.list

And this is the menu.lst after update-grub

Tormod Volden (tormodvolden) wrote :

Thanks. This is update-grub trying to be smarter than it is - it will try to detect a RAID and pick the right raw device but fails, and falls back to (hd0,0).

(IMHO it's a separate bug that update-grub at all tries to change these #groot or #kopt values that users have configured. That should maybe be done on an upgrade, but not everytime update-grub is run.)

Can you please run "sh -x update-grub 2>update-grub.txt" and attach update-grub.txt" ?

Tormod Volden (tormodvolden) wrote :

Sorry, I meant:
sudo sh -x /sbin/update-grub 2>update-grub.txt

Attachment is update-grub.txt

I think problem is here:

+ sed -ne /^### BEGIN AUTOMAGIC KERNELS LIST$/,/^### END DEBIAN AUTOMAGIC KERNELS LIST$/ {
                /^## ## Start Default Options ##$/,/^## ## End Default Options ##$/ {
                        /^# groot=/ {
                                s/^# groot=\(.*\)$/\1/

It searches for # groot, so, if I type in my menu.lst "# groot=(hd0,4)", all works fine, with "groot=(hd0,4)" not

Ok, this is not a bug, I read menu.lst:

## DO NOT UNCOMMENT THEM, Just edit them to your needs

so the right valuse is # groot=(hd0,4)

Changed in grub:
status: Needs Info → Rejected
Tormod Volden (tormodvolden) wrote :

I think we can leave this bug open:
1) The installer should have written #groot=(hd0,4) in the first place.
2) if the #groot gets lost (like it did in Giuseppe's case because he removed the#) and it needs to be autogenerated, it should guess better than (hd0,0).

Changed in grub:
status: Rejected → Confirmed

This is still a problem on 6-6-2007:
http://www.howtoadvice.com/DellUbuntu/

The update-grub command does a poor job of determining which partition the operating system in on.

Instead of using the "#groot" line in /boot/grub/menu.lst why doesn't it just look at the last kernel's root partition and use that as the default for the new kernel entry in /boot/grub/menu.lst ?

Would this be more resilient? No one who installs Ubuntu know to edit the "#groot" line to set the default. Dell certainly didn't know (see the link above). If you keep using the "#groot line to set the default root, then this needs to be a part of the installation process. There needs to be an option, during installation, that asks which partition is default. Or, during installation of Uubntu, perhaps a script can run to update the "#groot" value to which ever partition is mounted as root.

Actually, grub is foundational. It can be underneath several installations of Ubuntu Linux and multiple partitions. However, during a kernel update of one of these installations, the update-grub command is called. How can this command be aware of the "calling installation's root boot needs"?

Tormod Volden (tormodvolden) wrote :

Interesting that Dell got bitten by this, they are probably not using RAID like in this bug. Congratulations with your new Ubuntu Dell, Lonnie :)
The convert() and find_device() functions inside update-grub are not pretty. They are also duplicated in grub-install. I hope it will be all rewritten in grub2.

IMHO the #groot value should have been determined and written out by the installer program or manually set once, and then not be messed around with each time update-grub is run. If grub needs to autodetect it on its first run, it should ask the user to verify (and the autodetection should be separated out and possibly be overridden by command options).

Alfredo (frederick-jansen) wrote :

This bug still exists in Hardy. Each time I upgrade my kernel, I have to manually restore my menu.lst file.

Tormod Volden (tormodvolden) wrote :

Alfredo, please attach your menu.lst.

summary: - [DAPPER] update-grub doesn't work correctly with raid partitions
+ update-grub doesn't work correctly with raid partitions
Changed in grub (Ubuntu):
status: Confirmed → Incomplete
Launchpad Janitor (janitor) wrote :

[Expired for grub (Ubuntu) because there has been no activity for 60 days.]

Changed in grub (Ubuntu):
status: Incomplete → Expired
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