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
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?
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?
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).