Cannot reinstall grub on laptop's new disk - HELP!
I have just upgraded the hard drive in my T60p laptop, using my tried and tested method of:
a) .tar.bz2 up all filesystems to a safe place
b) swap the old drive out
c) recreate all the partitions on the new drive (as ext4)
d) set the "bootable" flag on /dev/sda1 (/boot)
e) update all filesystem UUIDs in /etc/fstab and grub.conf
f) reinstall grub
However, the T60p is refusing to boot off the new drive. It boots successfully off the Fedora 14 Live! CD, and all new partitions are then fully visible with all their contents intact. However, if I try rebooting without the Live! CD then there's a flicker of activity on the disk light and then the boot stops with a blank screen and a flashing cursor, without ever having reached the GRUB menu.
The Live! CD has an option to boot off the local drive, and this doesn't work for me either. The new drive also appears correctly in the BIOS's list of bootable devices.
I am thinking that there must be something wrong with how I am using GRUB:
a) Mount the root filesystem on /mnt/root
b) Mount all other filesystems, including /sys, /proc and /dev, into /mnt/root
c) chroot /mnt/root
grub> root (hd0,0)
grub> find /grub/stage1
grub> setup (hd0)
f) unmount all filesystems, and reboot.
However, this isn't working. Can anyone spot anything that I might be missing, please? I've already tried both "setup (hd0)" and "setup(hd0,0)" without success, and have confirmed that GRUB supports ext4 partitions in Fedora 14.
- mount the filesystems,
- grub-install /dev/sda
I didn't need to use --recheck, as it happened. What's bothering me now is that I thought that this was equivalent to what I was already doing, so that fact that this worked but my attempts all failed shows that grub-install must be doing something extra. Does anyone have any ideas what the "extra bit" might be, please?
Then it is called different on fedora, they need such a script that is trigged by every kernel install/remove.
Fedora's script adds and removes Fedora kernels from grub.conf, but my own additions are always left intact. So I guess it edits the existing file "in-place", rather than regenerating it from scratch each time.
My server running Debian has an update-grub script that completely rewrites menu.lst based upon a template of options for each minor kernel version, so I'm guessing that Debian is using GRUB 2.
No, Grub 1's update-grub only rewrites the part that is defined using the BEGIN/END comments - that the dynamic part, when write your own things outside it will not be affected. Grub 2 uses a file called grub.cfg, menu.list ist definitely Grub 1. Grub 2 ships with update-grub and uses /etc/grub.d scripts to fill it up. Usually one of those scripts parses the /etc/fstab for / and /boot entries and writes the config file correctly. When os-prober is installed it will add other distributions/windows as well.