Hi,

I'm finding this strange problem on my system. I have partitions /dev/hda5, /dev/hda6 and /dev/hda7 set aside to be root for testing versions. This is a debian based system. The grub files are in partition /dev/hda7... namely /boot/grub. I edited menu.list file in /dev/hda7 and during boot, I can see all the choices that I made to this file. Currently, they are :

title Debian GNU/Linux, kernel (hda6)
root (hd0,5)
kernel /boot/vmlinuz root=/dev/hda6 ro ramdisk_size=100000 lang=us apm=power-off nomce vga=0x317
initrd /boot/initrd.img
boot

title Debian GNU/Linux, kernel (hda7)
root (hd0,6)
kernel /boot/vmlinuz root=/dev/hda7 ro ramdisk_size=100000 lang=us apm=power-off nomce vga=0x317
initrd /boot/initrd.img
boot

title Debian GNU/Linux, kernel (hda5)
root (hd0,4)
kernel /boot/vmlinuz root=/dev/hda5 ro ramdisk_size=100000 lang=us apm=power-off nomce vga=0x317
initrd /boot/initrd.img
boot

I can boot into the 1st and 3rd one correctly, however, when I choose the second one, it actually mounted hda6 as my root partition. The /etc/fstab file under /dev/hda7 is as follows :

# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
usbfs /proc/bus/usb usbfs devmode=0666 0 0
/dev/hda7 / ext3 defaults,errors=remount-ro 0 1
/dev/hda3 /home ext3 defaults 0 2
/dev/hda8 /share ext3 defaults 0 2
#/dev/hda1 /media/hda1 ext3 defaults 0 0
/dev/hda2 none swap sw 0 0
#/dev/hda5 /media/hda5 ext3 defaults 0 0
#/dev/hda6 /media/hda6 ext3 defaults 0 0
/dev/cdrom /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto 0 0

which should mount /dev/hda7 as root. However, I get /dev/hda6 as my root partition.

Does anyone know why I'm getting the right root partition?

Thanks.

All I can think of is that grub is not looking at the menu.lst that you think it is. Try giving all the different kernels distinctive names--and setting up some other flags, dummy files, etc. so it is obvious where you are.

Actually, it should, since every time I change menu.list, the changes show up when I reboot. In fact, when I move the selected kernel, I can see that it shows the correct root=/dev/hda* paramater to grub. So, I don't think that is the problem. Thanks.

hi everybody,

this is an old thread, unfortunately without solution, and i'm having
just the same problem...
i boot into hda2 but end up with hda1 mounted as / even when using UUID

this is how it happened:
i had debian running on my laptop when my hard disk started to produce
i/o errors. i managed to copy the whole root partition (which was on
hda1) to an external disk, bought a new hard disk, reserved two root
partitions (hda1 and hda2) on it and installed ubuntu on hda1. finally,
i copied the old debian system the new disk on hda2. now, when booting
it, it always mounts hda1 as / s it used to on the old hard disk.
somehow, it seems to remember that it was originally on hda1. but how?
the grub menu and /etc/fstab are correct...

my grub entry for debian:
root (hd0,1)
kernel /boot/vmlinuz-2.6.18-4-686 root=/dev/hda2 ro
initrd /boot/initrd.img-2.6.18-4-686

my debian-/etc/fstab on hda2:
/dev/hda2 / ext3 defaults,errors=remount-ro 0 1

but df shows that /dev/hda1 is mounted to /
uname -a shows that the debian kernel 2.6.18 is running (and not the
ubuntu 2.6.22 kernel from hda1).
however, the ubuntu programs and settings from hda1 are used (for gdm
etc.).

alright, so i changed the grub entry to
kernel /boot/vmlinuz-2.6.18-4-686 root=UUID=12b261e9-cc1e-4634-925f-4f$

which is the UUID of hda2, and i did the same for the debian /etc/fstab
...

same result! hda1 is being mounted!!

???

somewhere i read that initrd probably points to the old partition
regardless of what is listed in grub's menu.lst
so i tried to reinstall initrd.img with yaird but didn't succeed
(unknown kernel version). i have to leave for now and will continue on
monday.

maybe someone has an idea? or knows how to make yaird work properly?

thanks.

wasi

I don't believe in any of these wild stories.

Grub never loads a wrong partition. It is always the user's mistake of not knowing what he/she is doing.

There are several areas of possible mis-direction.

(1) The menu.lst must be the one that is used by the MBR. This is to say if Grub boots off hda1 partition editing the Grub in hda2 would change nothing in the booting.

(2) The menu.lst should match the /etc/fstab. If in doubt post both outputs.

The confusion can be cut down considerably if chainloading is used.

I feel a need to use the language strongly because the title condemns Grub as buggy and unreliable but no solid proof is provided. I have to speak out for Grub because it boots 150+ in my box and never misses a beat.

Sorry, but that's wrong. Grub DOES load a wrong partition when using a wrong initrd.img ...

Well, yes, that's right. So finally, I found out what I did wrong:

When you simply copy the whole system from one partition to another (let's say from hda1 to hda2), you have to generate a new initrd.img - otherwise, the previously used partition (in my case hda1) will still be mounted as / - no matter what you write into grub's menu.lst and into /etc/fstab (even if you use UUIDs instead of hdaX)!

When using yaird to create a new initrd.img file, you need to copy the proper directory to /lib/modules (in my case 2.6.18-4-686) and the config-2.6.18-4-686 to /boot - otherwise you obtain an 'unknown kernel version' error.

It was not my intention to accuse grub of being buggy.
Apparently, grub needs a correct initrd.img file!

Cheers,

Wasi

mcwasi,

This is how I prove the user (in this case it is you) wrong again.

Let me use the three lines of booting my Debian as an example
The kernel vmlinuz-2.6.18-5-686 and the initrd initrd.img-2.6.18-5-686 are always stored in the /boot defined by the "root" statement. That is why Grub can go into partition (hd0,10) in my case to read off /boot/vmlinuz-2.6.18-5-686 and /boot/initrd.img-2.6.18-5-686. The "/" can be somewhere else but since I use a single partition my /boot is a subdirectory of "/" and there are all in sda11 (marked blue).

I have transferred up to 63 partitions at a time, moved Linux from partition to partition, hard disk to hard disk and even PC to PC but I have never had a need to touch the initrd, not even once. In other word Grub has never passed a wring initrd.img to me.

Thus the statement
is groundless because the location for an initrd.img is specified by a user with "root" and "initrd" commands. It is a 100% user's own choice. Grub has nothing to do with the right one or the wrong one.

Let me show you how Grub works. Here is a part print out of my (hd0) or sda output in "fdisk -l"
I can in a Grub shell using the "root" command to ask Grub to load any partition, which I do so with the first five partitions in my sda because they are all different. Here are the response by Grub
In each and every case Grub has reported the partition type exactly as those I specified by the root statement for sda1, sda2, sda3, sda4 and sda5. I have XP in sda1 and need to hide it when booting Vista in sda2. That is why sda1 has a type 17.

I know it is rather strong to say the user is wrong and Grub is right but the above fact speaks for itself.

A member posts a title as used in this thread literally telling the whole world that there is a serious fault in Grub because "Grub mounts the wrong partition". Is it fair when the error is self inflicited and got nothing to do with Grub?

I am not an expert in Grub or involved in maintaining it but my experience convinces me that Grub just mounts whatever we want. If I don't like the partition I got at the end I do not blame Grub. I look at my instruction and find out what's wrong. I certainly would not go out knowingly to maliciously damage Grub's reputation with something I do not understand.

I fully accept an inexperienced user can get things wrong and it is not a big deal but I also believe the title of the thread needs to be moderated, unless there is concrete evidence contributing to our knowledge on the deficiency of Grub.

Well, for me it was different. Only after recompiling initrd.img, the requested new partition was indeed mounted.

Alright, the same is true for my case. So, let me rephrase my statement:
Grub always correctly used the specified partition (i.e. did not mount any wrong partition). However, the specified initrd.img (loaded from the correct, i.e. specified partition) somehow initiated to mount the previously used partition (from which it had been copied) as root partition, i.e. not the partition specified in grub's menu.lst.

Please bear in mind that this is not a dedicated developers forum but a forum for everyone. Unexperienced users like me might sometimes use an incorrect formulation like "grub mounts a wrong partition", without intentionally implying that there is a bug in grub, only meaning that a different partition is mounted instead of the one specified with grub.
It was not my intention to blame grub for anything (which, in fact, I did, if you just look at the logical meaning of the words I used).
Human language is not always used in such a strict and logically correct way (although this might be, in a case like this, desirable), above all by folks who are not so deeply involved in the issue. Please be forgiving in a case like this!

The kernel and the BIOS may order disks differently. I have Windows XP on the first disk and
SuSE Linux on the second. When I boot, grub thinks that the Linux drive is the first and Windows is the second, because that is what the BIOS is telling it. However after booting (hd0) is the windows drive and (hd1) is the Linux drive. So running grub-install will fail. The solution is to edit the /boot/grub/device.map file. I think in your case, the reordering by the BIOS pointed to a different disk which happened to be another Linux disk. In the previous posters case, I wonder if using fdisk would indicate that the partitions are out of order.

jschiwal,

You may have hit on the nail head!

I think there can be 3 set of disk orders a Linux user should be aware of.

My investigation was based on a ABit AW9D-MAX mobo using 9 hard disks consisting of

3 internal Sata disk,
1 Internal Pata disk,
3 USb external hard disk,
1 external eSata disk,
1 external firewire hard disk.

The above was the disk order I arranged in the Bios

(a) Apparently the controllers take priority. The 1st internal Sata was No. 1 disk seen by Grub. The next No. 2 disk went to the only Pata disk (IDE controller). The external eSata was detected as 3rd hard disk because its controller is a SCSI type, according to the Bios. The 4th and 5th positions were grabbed by the remaining 2 Sata. The 3 USB were in 6th, 7th and 8th position and the firewire hard disk was the last disk seen by Grub.

(b) The Grub disk order I always assume to be the Bios disk order as Grub does not do detection. It simply accepts whatever the Bios hands down.

(c) Linux call the hard disk by sda, sdb, sdc, sdd, sde, sdf, sdg, sdh and sdi. It seems to have a different priority on the detection order. When I tried Ubuntu it always reserves sda to the Pata, Sata disks took sdb ,sdc and sdd. The SCSI disk took the next assigned sde. USB disk were ahead of the Firewire unit with name in descending order of sdf, sdg, sdh and sdi respectively. Thus the disk device names in Linux are given according to the type of hard disk in the detection sequence and fixed by the connection points of the mobo, since one can not put a Pata into a Sata connector. Neither a eSata can be plugged into an internal Sata point.

I know the above is as clear as mud but my point is unless a user knows exactly how the disk device names are assigned in Linux and different disks are detected in the Bios he/she should not be confident in saying which disk or partition Grub is booting to because Grub uses a numbering system. One can however asks Grub to show up the geometry of each disk by the command "geometry (hd0)", "geometry (hd1)"...etc , etc to verify his/her belief.

When I was greener in Linux i had exactly the same problem and suspected Grub wasn't doing everything quite right. Time has taught me that I was wrong.

It is easy to use grub's autocompletion to locate the partition containing the kernel. This allows booting even if you have no idea which disk or partitition contains the kernel and vmlinuz.