grub variable device name

[blahblahblah]

I installed the latest Sabayon onto a USB external hard drive, which is hooked up to my Toshiba Satellite laptop, via a LiveCD. When I took the CD out and rebooted, first I booted from the external drive. I was taken to a grub command prompt. I tried typing in "boot," but I was told to load to the kernel first, which I don't know how to do, so I rebooted and booted from the internal hard drive in my laptop. Sabayon was listed as one of the options, so I chose it. I was unable to boot because I quickly ran into a "couldn't mount root block device error," which I assume means that grub is configured with the name of the external HDD that existed during the installation, but the external HDD seems to change names or IDs.

Maybe I'm wrong. Regardless, I don't know the solution. Any ideas?

[Fitzcarraldo]

This is probably because grub.conf specifies a device (e.g. /dev/sdb1 or whatever) for real_root, rather than the UUID for the device. I think the stock SL kernel is built with the disklabel switch (see Notes 5 and 6 in the SL Wiki article HOWTO: Upgrade kernel using genkernel for an explanation of that switch), in which case you can edit /boot/grub/grub.conf and replace the device path with the UUID (see e.g. Re: adding hard drives for details of how to find out the UUID).

[LewRockwellFAN]

Somehow I missed this thread with search and started a somewhat redundant thread, viewtopic.php?f=86&t=20331 . I then found this just stepping through this section manually reading titles. I'm totally confused here. grub.cfg begins:
"#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by /sbin/grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#"

[Fitzcarraldo]

Those posts predate SL 5.2, which was the first release of SL to have Grub2 installed. i.e. they refer to grub.conf from Grub1 (a.k.a. 'Grub legacy') rather than grub.cfg (notice the name change?) from Grub2. The way to configure Grub2 is different to the way to configure Grub1. In the case of Grub2 you should not edit grub.cfg manually.

[donnie]

There is section in grub.cfg, in the end of that file, that can be edited manually (list of operation systems to boot). That's what is written in comments there. But nothing changed until I run grub2-install again...

[LewRockwellFAN]

Those posts predate SL 5.2, which was the first release of SL to have Grub2 installed. i.e. they refer to grub.conf from Grub1 (a.k.a. 'Grub legacy') rather than grub.cfg (notice the name change?) from Grub2.

/me facepalms. I shoulda seen that. Thanks.

In the case of Grub2 you should not edit grub.cfg manually.

I figured out that much. Hard to miss the warning in the file header. But I've looked at the files that seem to be editable and I can't find anything that looks at all promising to change. I've got 4 out of 5 OSs on my system booting properly from the GRUB menu. Sabayon 5.2, 64 bit wasn't, but it started to work after updating GRUB and choosing "package manager's version". The 32 version on sdc1 starts to boot but then complains about the filesystem on /dev/sda1 not being usable. Not sure of the exact wording but that is the jist. Undoubtedly when I installed it that drive was the only one connected and that partition WAS sda1. But now sda1 is W2k and the appropriate target is on sdc1. I can boot it properly by entering /dev/sdc1 manually. Is there a file I can edit to correct this or should I wait for GRUB to update and hope that fixes it or should I reinstall the 32 system? Can I force all the files in question to use partition labels (maybe that's volume labels, not sure of proper nomenclature here) instead of sd[letter] nomenclature?

[Fitzcarraldo]

^You could try something similar to what I mentioned to the OP for his Grub Legacy installation: get Grub2 to use UUIDs instead of devices. Try replacing root=/dev/sd<l><n> with root=UUID=<uuid>. See the article Ubuntu Community Documentation - Grub2 for details.

You can find out the UUID of a specific partition /dev/sd<l><n> by using the blkid command:

Code: Select all

# blkid /dev/sd<l><n>

[totedati]

for an successful grub2 installation you need to pay special attention to two config files:

path_to_external_hdd_mount_point/boot/grub/device.map
path_to_external_hdd_mount_point/boot/grub/grub.cfg

is all you need .. grub.cfg is usually the easy part because grub2-install auto-regenerate this file at each grub setup .... but device.map can be tricky .... for my laptop, when i boot from an usb flash pendisk with only one internal hdd is:

Code: Select all

(hd1)   /dev/sda
(hd0)   /dev/sdb

/dev/sda is laptop internal hdd and /dev/sdb got to be my usb flash pendisk ... with an internal hdd and an external usb hdd should be the same ... but for an laptop with one internal hdd, one internal dvdrw device and one usb external hdd connected as the boot device, it should got a /dev/sdc* label .... you can check that ... if this is true, then you device.map should be:

Code: Select all

(hd1)   /dev/sda
(hd2)   /dev/sdb
(hd0)   /dev/sdc

and that's it all you need for an working external hdd boot setup ... this is because when you select an external usb device at boot to be you boot medium this means is first device detected, and automagically got (hd0) status no matter how many internal devices you laptop have ... is the first thing to start all other things moving ... the boot device ... this is why is so dificult this part of booting process ... you got a selected boot device, you find an correct MBR grub2 signature, then from this signature you can jump only on that device at address blablabla ... on this blablabla adress you find a second, bigger, grub2 signature like a very crude os, but more capable than the first signature because is no more that 440 MBR bytes code size constraints ... this tinny os is at an absolute address on boot device put in MBR code ...

this tinny os can have readonly ext2 filesistem capabilities ... or aes crypto muscles ... or lvm prescience ... from this tinny os image grub2 code first read boot device mbr partition table, find an active boot partition, jump to that boot partition, find /boot/grub path, and here grub.cfg file, read this file, and here what they see?

root device is set as /dev/sdc device because when you install grub at you external hdd, that hdd is /dev/sdc not so? and /dev/sda is you laptop internal hdd ... but now, because you boot from you external hdd, that external hdd is now you first device ... and now you have an broken setup ... damn!

in that little grub2 shell, is exactly that tinny grub2 os, from an broken boot attempt, you can check how is you partition permuted now, with an command like this:

Code: Select all

search --no-floppy --fs-uuid external_hdd_boot_partition_uuid

my bet is to be always: (hd0,1) ... almost ... if you boot partition is you first partition on you external hdd mbr table ... can be (hd0,2) .. or (hd0,3) ... but always (hd0,*) ... because you boot device is you first device detected ...

in my case, i can delete path_to_external_hdd_mount_point/boot/grub/device.map because is a little redundant is here only for safety, but for some configurations can be useful ... i think grub2 style:

Code: Select all

search --no-floppy --fs-uuid --set external_hdd_boot_partition_uuid

to find and set correct boot partition is enough to forget about device.map mumbling jumbling ... just use UUID labels in grub.cfg instead of /dev/sd* device paths and you are on safe side ....