Announcement

Collapse
No announcement yet.

Cannot reinstall grub on laptop's new disk - HELP!

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Cannot reinstall grub on laptop's new disk - HELP!

    Hi,

    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
    d) grub
    grub> root (hd0,0)
    grub> find /grub/stage1
    grub> setup (hd0)
    grub> quit
    e) exit
    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.

    Thanks for any assistance here,
    Cheers,
    Chris

  • #2
    This works with grub 2 (and basically grub 1 too):

    Comment


    • #3
      Thanks, that worked!!

      Originally posted by Kano View Post
      This works with grub 2 (and basically grub 1 too):

      http://kanotix.com/index.php?module=...=Grub2recovery
      Basically:
      - mount the filesystems,
      - chroot
      - 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?

      Comment


      • #4
        well you have to run update-grub because your uuids most likely changed, depending on your layout you might have to fix /etc/fstab - especially with uuids in it.

        Comment


        • #5
          Hmm, it must be something else.

          Originally posted by Kano View Post
          well you have to run update-grub because your uuids most likely changed, depending on your layout you might have to fix /etc/fstab - especially with uuids in it.
          Fedora uses a (patched) GRUB 0.97, and besides, I updated the UUIDs in /etc/fstab and grub.conf manually.

          Comment


          • #6
            Thats stupid, your grub.conf is generated.

            Comment


            • #7
              Maybe with GRUB2, but I've never noticed with GRUB 0.97

              Originally posted by Kano View Post
              Thats stupid, your grub.conf is generated.
              GRUB 0.97 has no "update-grub" script.

              Comment


              • #8
                Then it is called different on fedora, they need such a script that is trigged by every kernel install/remove.

                Comment


                • #9
                  I suspect that Fedora's script works differently

                  Originally posted by Kano View Post
                  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.

                  Comment


                  • #10
                    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.

                    Comment

                    Working...
                    X