Les Mikesell lesmikesell@gmail.com wrote:
David G. Miller wrote:
Grub isn't so much the issue here as the difference in the rescue mode boot. I'm used to being able to boot the CD, chroot into the existing system and have pretty much normal access regardless of what was broken. Now that the system /dev directory is basically empty, things don't work when you have to mount the partitions manually. Is there a step to set up devices so the chroot will work?
I haven't tried this but were you looking at /dev *after* you did the chroot? It sort of makes sense to me that the running kernel would only populate it's /dev, not the chrooted /dev. Rescue mounts at least the root partition under /mnt/sys (or something like that). Before you chroot, you should probably also mount any other partitions you want under /mnt/sys and then chroot.
It makes sense for the boot code, but not for me afterwards... The real problem is that the rescue mode startup doesn't mount RAID1 partitions at all (this seems like a bug). The startup code might populate the chroot'ed /dev if it had done the mount - I just haven't found how to do it myself after doing the mount by hand. Thus there's no /dev/sda or /dev/sdb as you'd expect when you want to install grub.
Let me try explaining this a different way. After you let the rescue software mount the partition, *don't* chroot.
It's been a long time since I had to mess with booting in rescue mode but lets assume your old root partition gets mounted under /mnt/sysimage and you told the rescue software to go ahead and mount it. If your /boot is a separate partition, you'll need to mount it manually. Assuming you keep everything where it belongs, mount it under /mnt/sysimage/boot. Then run grub by doing:
/mnt/sysimage/sbin/grub --config-file=/mnt/sysimage/boot/grub/grub.conf
This way grub "sees" /dev for the running system but uses your real grub config file. You may want to confirm that grub.conf has what you want in it.
Cheers, Dave