Having problems with Grub2 booting Ubuntu from my External Hard Drive

Question

I installed Ubuntu on my external hard drive but it won't boot on my laptop. What do I do?

I did some reading and traced the source of the problem to Grub2. Apparently, Grub2 doesn't use the device's UUID, and uses the linux directory instead (/dev/sdf2). This means that whenever I plug my E-HDD into a system that has a different number of drives connected to it, I won't be able to boot without editing the boot command. I don't understand it too well but that's what I got from what I read.

Is there any way to fix this?

Here's my grub config (trimmed to show example kernel entry). I have no idea why it's not using UUID. I didn't tweak it once...

### BEGIN /etc/grub.d/10_linux ###
menuentry "Ubuntu, Linux 2.6.31-20-generic" {
        recordfail=1
        if [ -n ${have_grubenv} ]; then save_env recordfail; fi
    set quiet=1
    linux   /boot/vmlinuz-2.6.31-20-generic root=/dev/sdc2 ro   quiet splash
    initrd  /boot/initrd.img-2.6.31-20-generic
}
menuentry "Ubuntu, Linux 2.6.31-20-generic (recovery mode)" {
        recordfail=1
        if [ -n ${have_grubenv} ]; then save_env recordfail; fi
    linux   /boot/vmlinuz-2.6.31-20-generic root=/dev/sdc2 ro single 
    initrd  /boot/initrd.img-2.6.31-20-generic
}

Answer 1

The problem was that my device.map was not configured properly which led to grub using the ubuntu names, e.g. sdf2, rather than the UUIDs of the hard drive. the fix was to update device.map and then update grub2. It is done by running 'drivemap', i think, then update-grub. I'm not too sure on the command to update device.map because i did this about a week ago, but yeah. This is just in case anyone runs into my problem.

Answer 2

OK, you're right that that's not grabbing UUIDs, which strikes me as odd.

Here's how a kernel entry should look (this is from my Ubuntu 9.10 VM, slightly tweaked but this should be fairly stock):

menuentry "Ubuntu, Linux 2.6.31-20-generic" {
    recordfail=1
    if [ -n ${have_grubenv} ]; then save_env recordfail; fi
    set quiet=1
    insmod ext2
    set root=(hd0,1)
    search --no-floppy --fs-uuid --set b22c7fe9-4354-40bf-b9bf-87a469289f6e
    linux /boot/vmlinuz-2.6.31-20-generic root=UUID=b22c7fe9-4354-40bf-b9bf-87a469289f6e ro
    initrd        /boot/initrd.img-2.6.31-20-generic
}

The /boot/grub/grub.cfg file is generated when something runs update-grub from the scripts in /etc/grub.d and variables in file /etc/default/grub.

---

• Now, there is a variable in the default file, GRUB_DISABLE_LINUX_UUID, that if set to true will give a root=/dev/sdXY value to the linux kernel line (instead of a root=UUID=... value). I don't think that's your problem, but check your /etc/default/grub file to make sure. You should see these lines (the # at the beginning of the line means it's commented out):

  # Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
  #GRUB_DISABLE_LINUX_UUID=true
  

  If you see GRUB_DISABLE_LINUX_UUID without the # at the beginning, insert it, save the file, and run sudo update-grub to regenerate grub.cfg. Then check grub.cfg again to see if it looks right.

---

• If the defaults file looks OK, next check your drive's UUIDs themselves. It's possible that the drive UUIDs aren't set correctly, or aren't getting detected correctly. uDev has the job of creating symlinks in the device tree for disk UUIDs; check them:

  $ ls -l /dev/disk/by-uuid
  total 0
  lrwxrwxrwx 1 root root 10 2010-04-18 04:15 b22c7fe9-4354-40bf-b9bf-87a469289f6e -> ../../sda1
  lrwxrwxrwx 1 root root 10 2010-04-18 04:15 e1c64ac1-186d-4c15-8833-6072ac6421df -> ../../sda5
  

  If this doesn't show you a partition you're expecting to see, you might need to check the filesystem directly with tune2fs (manpage) (replace /dev/sda1 with the right device name):

  $ sudo tune2fs -l /dev/sda1 | grep UUID
  Filesystem UUID:          b22c7fe9-4354-40bf-b9bf-87a469289f6e
  

  If this is missing, you can recreate it with:

  $ sudo tune2fs -U random /dev/sda1
  

  Now re-check the tune2fs -l output, and then check /dev/disks/by-uuid again. You may need to reboot before uDev picks up the changes. The update-grub scripts should now pick up the UUID, so re-run it and check the new grub.cfg to see if it looks right.

---

• If none of these are panning out, you may need to dig a little deeper. Let's check our assumptions:
  • How is your boot drive partitioned? (fdisk -l)
  • How is your boot drive formatted? (ext2/3/4? FAT32? NTFS?)
  • Did you install via Wubi?