[SOLVED] Issues with menu.lst and grub.cfg ...

[ghmitch]

I have a longstanding situation with Mageia 2 whereby the Mageia tools try to guess at the "hd" variables in menu.lst and get them wrong. This is a continual frustration because each time a new kernel gets installed I end up with a boot failure. And now I am seeing the same issue with grub2 and grub.cfg although in the case of grub2, things still work because grub2 drops back to UUID for final validation. So what is the underlying problem with this issue? Is it a matter of no existing underlying system tools to verify and properly map BIOS (hdX,Y) to System UUID relationships? It would certainly seem that grub2 would be able to handle this from the system side ... or not? I am also aware, of course, that anytime I change my boot disk order in my BIOS, it modifies the "hd" designations.

Aside from this I am moving along with Mageia 3 pretty uneventfully. I currently have all of my 3 OSs booting from grub2 OK and both grub and grub2 working alongside one another on the same box. My next challenge is to migrate Mageia 3 off of ext4 and onto a RAID 1 BtrFS platform. My first step in that direction will be to attempt to create a new ram disk image that includes a btrfs module. That should boot OK on either ext4 or BtrFS. The rest should be fairly straightforward (fstab, grub.cfg, etc) ... I hope? I will let you all know of any unexpected problems encountered with that.

- George

[isadora]

And ... wow! ... I can't believe I am actually up and running with BtrFS as the root file system. Some things seemed to be going wrong, but when I attemted to boot anyway ... wa la! It just can't be that easy?

But here's the first part of the output of the mount command:

Code: Select all

[ghmitch@localhost ~]$ mount
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=2067240k,nr_inodes=194850,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
/dev/sdc1 on / type btrfs (rw,relatime,space_cache)

And it sure looks like I'm there. And I expected this to be torturous.

- George

[ghmitch]

I now, finally, have Mageia3 on BtrFS, Mageia 3 on ext4, existing Mageia 2, and Mandriva 2011 all booting from one grub2 screen on one system. Getting there wasn't particularly easy. My big breakthrough was learning the significance of the BIOS enumeration of "hd" devices. That whole process is rather obscure. My best advice to anyone else trying to implement a global grub2 bootloader is:

1) First of all get it working on your Mageia 3 install and install the bootloader to its own MBR on its own disk if at all possible and navigate back and forth by changing boot order in your machine until you are able to successfully get all OS's booted from the Mageia 3 grub2 bootloader. That way you won't lose access to your existing grub legacy install. Any Mageia 3 root installed on BtrFS will ONLY be bootable from grub2 and can not be successfully added to legacy grub.

2) Most likely your grub2 bootloader will list all of your existing onboard OS's, BUT also most likely, some or all of those will fail to boot from grub2 with errors like can't find partition or invalid partition or such. The solution is to boot to the grub2 bootloader screen and go immediately to the command line with a "c". I found the following wiki extremely helpful in this process: http://members.iinet.net/~herman546/p20/GRUB2%20CLI%20Mode%20Commands.html. If you use the "ls" command in the grub shell, you will see a listing of what grub2 sees. Then there are grub shell commands (like "cat (hdX,Y)/etc/lsb-release") that let you see what is on each of the partitions listed. If the drive/partition you are looking for is not listed, you are going to have to reprogram your BIOS until it is AND you won't make any more progress with grub2 until you reconfigure your BIOS. Just remember or write down what your initial boot order is so you can always restore it quickly and get access to your legacy grub back. In my case, I had to make sure to get the boot order right, that helped some. But I found that with my BIOS, even drives excluded from the boot order could mess with the "hd" enumeration. As it turned out, I had to specifically DISABLE those drives in the BIOS. That removed them from the "hd" map and suddenly everything worked. My BIOS "hd" map is able to contain only 4 drives, so anything beyond the first four that are enumerated are toast. You will never be able to access them from grub2 since the BIOS won't map them. Seemingly any drive that is not a boot drive can be disabled in the BIOS with no problem since Linux goes back and picks up these drives on its own at boot time, so they are not lost to Linux, only to the BIOS and grub2. BUT DO NOT disable the drive containing your legacy grub bootloader or you won't be able to access it anymore!

The good news is that in spite of all of the horror stories, I think it is possible to get this to work especially if you have more than one hard drive to work with. Having an existing stable Linux system to work from can make it much easier to build up a new parallel system on the same hardware. Just make sure to keep the new project separate from the old stable system until you can safely integrate them with grub2 or you can end up with a nightmare, including complete loss of your old system.

It is nice that grub shell can see both BIOS "hd" assignments and system information from the bootloader side. Too bad the grub shell (or anything else for that matter) seemingly can not do this from the OS side. That creates a real disconnect when trying to create a bootloader that "just works".