grub-install fails on rescue boot due to incorrect path
Figured I would try out this new forum! One long term puzzlement for me is summarized by this now closed bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=429785
When you rescue boot RHEL6 via DVD/CD, the grub-install script has an incorrect path to grub, so it fails to run. You have to sym link grub in and then it works as the bugzilla describes.
Am I missing something obvious as why this is broken out of the box?
daryl
Responses
Red Hat
Guru
3878 points
I'm confused by that bug. This has never worked, as long as I can remember, and it's not just because of the symlink issue.
If you want to reinstall grub in rescue mode, you have two choices:
-
With Chroot
- Make sure root filesystem is mounted at /mnt/sysimage and "boot" filesystem is mounted at /mnt/sysimage/boot
- Chroot in, i.e.:
chroot /mnt/sysimage - Run grub-install, e.g.:
grub-install /dev/sda
-
Without Chroot (or even any filesystems mounted)
- Create a temporary device.map file to map linux devnode names to bios device names for grub, e.g.:
echo "(hd0) /dev/sda" >dev.map -
Run grub with that file and then set the root device [
root (hd0,0)] and install grub [setup (hd0)], e.g.:bash-4.1# grub --device-map dev.map GNU GRUB version 0.97 (640K lower / 3072K upper memory) [ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename.] grub> root (hd0,0) root (hd0,0) Filesystem type is ext2fs, partition type 0x83 grub> setup (hd0) setup (hd0) Checking if "/boot/grub/stage1" exists... no Checking if "/grub/stage1" exists... yes Checking if "/grub/stage2" exists... yes Checking if "/grub/e2fs_stage1_5" exists... yes Running "embed /grub/e2fs_stage1_5 (hd0)"... 27 sectors are embedded. succeeded Running "install /grub/stage1 (hd0) (hd0)1+27 p (hd0,0)/grub/stage2 /grub/grub.conf"... succeeded Done. grub> quit quit bash-4.1#
- Create a temporary device.map file to map linux devnode names to bios device names for grub, e.g.:
In short: grub-install doesn't work because of the symlink it's expecting to be there, but in my experience it also won't work without a device.map file -- a file that it expects by default at /boot/grub/device.map.
EDIT:
Thanks to your question, I just overhauled our KCS solution on this topic. See it at How to re-install GRUB bootloader on the Master Boot Record(MBR) in rescue mode?
Pro
482 points
Thanks for the detailed response. After making the sym link,
grub-install --root-device=/mnt/sysimage /dev/sda
the command always worked for me. The chroot option is problematic as sometimes the /dev devices do not exist within /mnt/sysimage.
Just curious, why are the /dev devices sometimes existent and sometimes not?
Is it possible to mount -o bind /dev /mnt/sysimage/dev or something like that?
Red Hat
Guru
3878 points
Ah...... Indeed you're right about that working Daryl (just tried it).
I gotta say though: I can't imagine a situation where it's hard to get the device node files to show up in /dev. Assuming the rescue env automatically mounts things, the appropriate bind mounts will already be there. On the other hand, if you have to mount things manually, you can run the mount commands yourself, e.g.:
for d in dev proc sys; do mount -o bind /$d /mnt/sysimage/$d ; done
I guess what I'm saying is that if you've actually got the rootfs mounted, I just don't see why you would avoid chrooting in. I've never seen someone struggle with that.
In any case, I see what you're saying about the symlink Daryl and I think the next step for you would be to either open a new BZ against RHEL6 (everyone is entitled to do so) or to open a support case in the Customer Portal (and an engineer there can look into it, optionally opening the BZ for you).
Red Hat
Guru
25389 points
By the way Daryl, it's a good idea when you're posting to select the product that your question applies to. This will make it easier for other users to find. You can also add tags to further improve searchability. I'll add this to the RHEL product.