Grub Installer uses device name instead of UUID, leading to unbootable system

[Ubfan]

After completing a fresh install, the grub.cfg on the target system uses the device name as the root= kernel parameter instead of the UUID, causing the system to fail to boot if the devices are enumerated differently. Running update-grub on the target system regenerates the config file correctly using the UUID.

[Ubfan (ubfan1)]

As of Karmic (9.10), grub's use of UUIDs fixed the problem of being unable to boot the other operating systems. The devices are still wrong, but will make no difference unless the install is to a portable device like a usb stick which should be able to boot windows on any PC. In that case, fix the device.map file to make hd0 the actual root device, and rerun update-grub.

[Ubfan (ubfan1)]

Lucid (10.04) has fixed the bad device.map (got rid of it), fixed the comments mentioning devices on the other oses, and generally has rationalized the hd0 is sda, hd1 is sdb. Unfortunately, the /etc/fstab file now puts / on
/dev/sdcx instead of /dev/sdbx (or UUID as in Karmic). Since there is no sdc after the install media has been removed, this is certainly wrong. mtab is OK, using the correct sdbx mounts.
  Same procedure -- download iso, (on Jaunty) system/administrator/create USB startup disk, reboot from usb startup disk, install to USB hard drive. Avoid messing up the Windows MBR with the advanced button to fix where grub is installed. After the first package update, which got a new kernel, I think the grub.cfg file is now OK with all the correct devices. Only wrong device I can find is in the fstab for / (root).

[Ubfan (ubfan1)]

Maverick usb install media, whether created from Lucid or Maverick will still
create a non-booting target usb device (thumbdrive or usb hdd) because the
wrong device (sdc instead of sdb) is used. To recap, at install time, the
Windows internal hard disk gets sda, the boot media gets sdb, and the target
usb gets sdc. The grub paragraphs all are written to the target with these
device assignments, even though it is certain that the boot media will not be
present when you boot the target. Using a CDROM install media avoids this
problem since the drive is not given an interferring sdx device. The usual
fix is necessary: At target boot, edit the grub paragraph to reduce the
device references by one (hd2 -> hd1, and sdc -> sdb), for the first boot,
then after a successful boot, immediately sudo update-grub. Without the boot
media, the devices will be correct for the next reboot. fstab uses UUID, so is ok.

[Phillip Susi (psusi)]

Lucid and maverick should be using grub2, which should be using UUIDs to work this out. There should be no device.map. Are you using the alternate install or is this a normal desktop gui install? Can you attach your /boot/grub/grub.cfg and /etc/fstab?

[Ubfan (ubfan1)]

This problem goes back to grub1, and grub 2 did not fix it entirely. UUIDs helped, but they are not used for every disk reference. I use the normal desktop gui install, from a 2G "live" usb, to a 4G usb target on a standard Windows laptop, The created grub.cfg still has wrong device references for things like root=(hd2 instead of hd1 even though the UUID is used on the kernel line -- so it does not boot. At the first target reboot after installation, I edit the boot command to reduce the hd2 to hd1, and after successful boot, run update-grub to get the whole grub.cfg fixed.
   UUIDs are NOT used 100% of the time, Within the last 24 hrs, a Maverick install from a Maverick created live usb to a 4G pqi "smart" stick created fstab with /dev/sdc as /. (how can this even boot?) The grub.cfg file had the hd2 to hd1 edit to boot, and the kernel line did have the UUID.
  My first Maverick install was from a Lucid created live usb to a 4G hp (older) stick, and had to do the F6 ... text install. This created an fstab with a UUID, but the grub.cfg had /sdc on the kernel line, as well as the usual wrong hd2 references. Maybe this install was an odd ball given the manual intervention necessary to get the install to work.
  The cause is obvious, grub2 writes its first install configuration with all the devices, including the install media, which is not going to be present at the first reboot. hd0 is windows on the hard disk, hd1 is the usb install media, and hd2 is the target. Remove the install media, and hd0 is still windows, but hd2 does not exist, since the target is now hd1. I haven't been saving bad grob.cfg files for awhile, but I could do another install and grab one. As I recall, there were comments about the devices that were also referring to the sdc device for the linux boot paragraphs.

[Phillip Susi (psusi)]

The next line after the root should be a search command with the correct
UUID, so it does not matter if the device specified on the root line is
wrong. Is this not the case for you?

Also the comments referring to the device in /etc/fstab are just that;
comments don't matter.

[Ubfan (ubfan1)]

Certainly not the case with me. The root=/dev/sdc1 on the linux line overrides whatever the search UUID did. I just did a fresh install from a 2G usb stick created on a Maverick system with the normal desktop iso, to a 4G new pqi stick. I captured the grub.cfg (bad), fstab (OK), and the /var/log files in case you needed them. The first boot attempt fell into BusyBox after about a minute with the following error:
Gave up waiting for root device. Common problems:
-Boot args (cat /proc/cmdline)
  -check rootdelay= (did the system wait long enough?)
  -check root= (did the system wait for the right device?) <<<<<<NO IT DIDN'T
-Missing modules (cat /proc/modules; ls /dev
ALERT! /dev/sdc1 does not exist - Dropping to a shell
BusyBox v1.15.3 (ubuntu 1:1.15.3-1ubuntu5) built-in shell (ash)
Enter 'help' for a list of built-in commands
(initramfs)_

cat /proc/cmdline gives:
BOOT_IMAGE=/boot/vmlinuz-2.6.35-22-generic root=/dev/sdc1 ro quiet splash

The modules were:
usb_storage firewire_ohci, firesire_core, pata_amd, forcedeth, sdhci_pci, ac_itu_t, sdhci, sata_nv, led_class, ssb

The /dev directory contained sg0, sda, sda1, sda2, sda3 (the Windows disk), sg1, sdb, sdb1 (the 4G stick failing to boot)
and no sdc.

I select manual partition selection, select the sdc1, format an ext2 fs, no swap, the grub boot goes to the 4G stick on sdc (default after I select the sdc disk). The only disks shown are sda( the windows disk), and sdc(the target). sdb is the 2G install usb, and correctly is not a choice.

The original grub.cfg file created on the target, before any boot attempt is:
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
set default="0"
if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    save_env saved_entry
  fi
}

function recordfail {
  set recordfail=1
  if [ -n "${have_grubenv}" ]; then if [ -z "${boot_once}" ]; then save_env recordfail; fi; fi
}

function load_video {
  insmod vbe
  insmod vga
}

insmod part_msdos
insmod ext2
set root='(hd2,msdos1)'
search --no-floppy --fs-uuid --set 0ddfb60a-4791-45c9-85ec-c13c42c459af
if loadfont /usr/share/grub/unicode.pf2 ; then
  set gfxmode=640x480
  load_video
  insmod gfxterm
fi
terminal_output gfxterm
insmod part_msdos
insmod ext2
set root='(hd2,msdos1)'
search --no-floppy --fs-uuid --set 0ddfb60a-4791-45c9-85ec-c13c42c459af
set locale_dir=($root)/boot/grub/locale
set lang=en
insmod gettext
if [ "${recordfail}" = 1 ]; then
  set timeout=-1
else
  set timeout=10
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Ubuntu, with Linux 2.6.35-22-generic' --class ubuntu --class gnu-linux --class gnu...

[Ubfan (ubfan1)]

I do agree that if the UUID is used on the linux line, the "set root=" line to the wrong hd2 will not stop the boot.
I have just done 4 quick Maverick USB installs, and I think I recall that not all have had the sdc1 on the linux line. The install to a USB hard disk seemed to only have the set root=(hd2 "problem", which I automatically corrected at first boot. I don't plan on doing another USB/hdd install any time soon, but if you need me to, I will reinstall it to see exactly what happens.

[Phillip Susi (psusi)]

The set root line tells grub where to look, and can be wrong, since it is followed by the search line which has grub locate the disk by uuid. The root= parameter on the linux line tells the kernel where to look, and it should also be UUID, unless you have edited /etc/default/grub and uncommented:

GRUB_DISABLE_LINUX_UUID=true

Have you done this?

[Ubfan (ubfan1)]

No, I have never edited any default files to produce the sdc on the linux line. The problem is created by a pretty standard install, just doing a manual partition because I am afraid if I answer yes to "use the whole disk" the windows internal disk would be wiped out.

[Ubfan (ubfan1)]

I found the original grub.cfg file from a USB hard disk install. It does use UUIDs on the linux line, just the hdx references are wrong. This probably would have booted Maverick successfully, but maybe not Windows, which does the search with UUID, but used the bad hd1 for the drvemap. The fstab file also used UUID for the root and swap, just having the "leftover" comments about the devices being on /dev/sdcx at install (comments which no longer appear in the grub.cfg file).
grub.cfg from a maverick created 2G USB installer to a USB hard disk target -- only hx? references are wrong but may still boot linux.but probably not Windows:
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
set default="0"
if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    save_env saved_entry
  fi
}

function recordfail {
  set recordfail=1
  if [ -n "${have_grubenv}" ]; then if [ -z "${boot_once}" ]; then save_env recordfail; fi; fi
}

function load_video {
  insmod vbe
  insmod vga
}

insmod part_msdos
insmod ext2
set root='(hd2,msdos1)'
search --no-floppy --fs-uuid --set 158ce293-1d71-4883-b2e9-8a0d5dfc0170
if loadfont /usr/share/grub/unicode.pf2 ; then
  set gfxmode=640x480
  load_video
  insmod gfxterm
fi
terminal_output gfxterm
insmod part_msdos
insmod ext2
set root='(hd2,msdos1)'
search --no-floppy --fs-uuid --set 158ce293-1d71-4883-b2e9-8a0d5dfc0170
set locale_dir=($root)/boot/grub/locale
set lang=en
insmod gettext
if [ "${recordfail}" = 1 ]; then
  set timeout=-1
else
  set timeout=10
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Ubuntu, with Linux 2.6.35-22-generic' --class ubuntu --class gnu-linux --class gnu --class os {
 recordfail
 insmod part_msdos
 insmod ext2
 set root='(hd2,msdos1)'
 search --no-floppy --fs-uuid --set 158ce293-1d71-4883-b2e9-8a0d5dfc0170
 linux /boot/vmlinuz-2.6.35-22-generic root=UUID=158ce293-1d71-4883-b2e9-8a0d5dfc0170 ro quiet splash
 initrd /boot/initrd.img-2.6.35-22-generic
}
menuentry 'Ubuntu, with Linux 2.6.35-22-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os {
 recordfail
 insmod part_msdos
 insmod ext2
 set root='(hd2,msdos1)'
 search --no-floppy --fs-uuid --set 158ce293-1d71-4883-b2e9-8a0d5dfc0170
 echo 'Loading Linux 2.6.35-22-generic ...'
 linux /boot/vmlinuz-2.6.35-22-generic root=UUID=158ce293-1d71-4883-b2e9-8a0d5dfc0170 ro single
 echo 'Loading initial ramdisk ...'
 initrd /boot/initrd.img-2.6.35-22-generic
}
### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/20_linux_xen ###
### END /etc/grub.d/20_linux_xen ###

### BEGIN /etc/grub.d/20_memtest86+ ###
menuentry "Memory ...

[Phillip Susi (psusi)]

That config looks like it should work perfectly fine, have you tried it?

Again, it does not matter that the set root= line has the wrong drive because it is followed by the search command which sets it by locating the drive by UUID.

[Ubfan (ubfan1)]

 We both agree the second grub file will boot linux. I doubt it will boot windows, but don't care.
Look at the LINUX line from first grub.cfg file from a 4G stick install, four lines cut out below:

set root='(hd2,msdos1)'
 search --no-floppy --fs-uuid --set 0ddfb60a-4791-45c9-85ec-c13c42c459af
 echo 'Loading Linux 2.6.35-22-generic ...'
 linux /boot/vmlinuz-2.6.35-22-generic root=/dev/sdc1 ro single

It's the root=/dev/sdc1 part which makes boot fail, EVERY TIME. Surely you will admit that this overrides the search UUID business?

I do nothing to cause the device to be used instead of the UUID.

Installs to 4G sticks seem to get the device and will not boot without editing the grub commands.
Installs to a USB hard disk seem to get the UUID and will work for the first linux boot.

After so many bad installs to non-booting sticks, I tend to edit the grub commands at first boot and fix the obvious wrong items, and not to even try to see if the boot works. In addressing this bug, it is of interest that the problem is not consistently a problem with USB installs, since the USB hard disks will actually boot.

[Phillip Susi (psusi)]

> Installs to 4G sticks seem to get the device and will not boot without editing the grub commands.
> Installs to a USB hard disk seem to get the UUID and will work for the first linux boot.

Hrm... the system should not be able to tell the difference between a
usb flash stick and a usb hard disk; 10.04 and later should be using the
uuid either way. Can you reproduce this?

[Ubfan (ubfan1)]

Yes, I can recreate it.
I'll run a couple of Maverick installs tonight to some 4G sticks.
I'll use a Maverick created installer, and capture the grub.cfg, and fstab.
If I can, I'll grab the log files off the install media too.

[Ubfan (ubfan1)]

Recreated the problem of the sdc appearing on the linux lines in grub.cfg on an install to a 4G Patriot xmini usb stick.
fstab was OK with the UUID used for /, sdc1 only appearing in a comment.
I did copy the /var/log files off the install media in case they might be of interest.
Install sequence of events:
Booted the Maverick install media, at the "Try"/"Install" screen, i inserted the target 4G usb.
I was Not connected to the internet, and did not check off third party sw.
Selected "Specify partitions manually" instead of "use whole disk".
(I had previously taken the new 4G stick, and made one partition, starting at sector 8192, with h=4 and s/t=16.)
Selected sdc1, then the change button.
use as ext2, format, / selected
Boot loader automatically switched to the 4G stick on sdc from the windows sda disk.
selected install now
selected continue on the no swap warning
Set time zone to LA
selected USA keyboard
Filled out the name, user, etc, require pw to boot.
When install finished, I switched to a virtual terminal, and tared up the /var/log files.
unmounted the target. Rebooted to my normal linux environment (on a 4G stick), and copied off the grub.cfg and fstab from the just created target usb.

This result is the same as the previous install to a 4G PQI usb stick, which did not boot because of the sdc1 on the linux line.

The bad grub.cfg file with the sdc on the linux lines:
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
set default="0"
if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    save_env saved_entry
  fi
}

function recordfail {
  set recordfail=1
  if [ -n "${have_grubenv}" ]; then if [ -z "${boot_once}" ]; then save_env recordfail; fi; fi
}

function load_video {
  insmod vbe
  insmod vga
}

insmod part_msdos
insmod ext2
set root='(hd2,msdos1)'
search --no-floppy --fs-uuid --set 27731a50-39e4-41ad-92e8-52048248792a
if loadfont /usr/share/grub/unicode.pf2 ; then
  set gfxmode=640x480
  load_video
  insmod gfxterm
fi
terminal_output gfxterm
insmod part_msdos
insmod ext2
set root='(hd2,msdos1)'
search --no-floppy --fs-uuid --set 27731a50-39e4-41ad-92e8-52048248792a
set locale_dir=($root)/boot/grub/locale
set lang=en
insmod gettext
if [ "${recordfail}" = 1 ]; then
  set timeout=-1
else
  set timeout=10
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Ubuntu, with Linux 2.6.35-22-generic' --class ubuntu --class gnu-linux --class gnu --class os {
 recordfail
 insmod part_msdos
 insmod ext2
 set root='(hd2,msdos1)'
 search --no-floppy --fs-uuid --set 27731a50-39e4-41ad-92e8-52048248792a
 linux /boot/vmlinuz-2.6.35-22-generic root=/d...

[Phillip Susi (psusi)]

Ok, just to confirm now, when you install on a usb flash stick, grub.cfg does not use the uuid on the linux line, but when you install to a usb hard disk, it does?

[Ubfan (ubfan1)]

Correct.
It just occurred to me that a significant difference between the two installs is that the usb flash sticks only have one partition. I have always had at least two partitions on a hard disk (one for swap, plus the install partition, plus any others).

[Phillip Susi (psusi)]

Could you try booting the system ( press e at the grub prompt to edit the stanza and correct the root= part ) and then run sudo update-grub and see if that corrects it to use the UUID?

[Ubfan (ubfan1)]

grub edited just the sdc to sdb to boot, no other changes made.
Copied fstab and grub.cfg to desktop
sudo update-grub
The fstab was unchanged (OK), and the grub.cfg had the UUIDs used instead of the sdc devices, and the hd2 s were changed to hd1 s., correcting all the problems.
diff below from the above grub.cfg file:

$ ls
fstab fstab-orig grub.cfg grub-orig.cfg

$ diff grub*
41c41
< set root='(hd1,msdos1)'
---
> set root='(hd2,msdos1)'
51c51
< set root='(hd1,msdos1)'
---
> set root='(hd2,msdos1)'
73c73
< set root='(hd1,msdos1)'
---
> set root='(hd2,msdos1)'
75c75
< linux /boot/vmlinuz-2.6.35-22-generic root=UUID=27731a50-39e4-41ad-92e8-52048248792a ro quiet splash
---
> linux /boot/vmlinuz-2.6.35-22-generic root=/dev/sdc1 ro quiet splash
82c82
< set root='(hd1,msdos1)'
---
> set root='(hd2,msdos1)'
85c85
< linux /boot/vmlinuz-2.6.35-22-generic root=UUID=27731a50-39e4-41ad-92e8-52048248792a ro single
---
> linux /boot/vmlinuz-2.6.35-22-generic root=/dev/sdc1 ro single
98c98
< set root='(hd1,msdos1)'
---
> set root='(hd2,msdos1)'
105c105
< set root='(hd1,msdos1)'
---
> set root='(hd2,msdos1)'

[Phillip Susi (psusi)]

I was able to reproduce this. I will do some more testing tomorrow to make sure, but I suspect it does not matter that the target medium is a usb device, rather than after the initial install, all systems use the disk device instead of UUID, and then it later is corrected to be the UUID when update-grub is run. This never happens though, if the device name changes when you reboot between install and the first boot of the new system.

[Sly_tom_cat (slytomcat)]

The same issue I found while installing Xubuntu 11.04 and Kubuntu 11.04 from flash drive on external HDD.

During installation the root is /dev/sdc1 (sda - internal HDD, sdb - LiveUSB - installation source) but while loading without LiveUSB the root became /dev/sdb1 and starting fails to the BusyBox.

If I change the kernel boot options in GRUB (pressing "e" in GRUB menu) I can load the system. The command update-grub makes the correct grub.cfg (with UUID root drive identification). After that the system is loading fine.

[Ubfan (ubfan1)]

The problem is still present with the 12.04 release.

[Ubfan (ubfan1)]

There is still a problem in the 12.10 release, but a different wrong device is now used -- sda instead of sdc. The target is now assigned sda (or hd0), the install media sdb (or hd1), and the hard disk sdc (or hd2). At the first reboot, the disk assignment is: hard disk is sda, and usb target is sdb. Fortunately, other installations on the hard disk refer to UUID, so may boot. The initial grub edits now become change sda to sdb, and the hd0 references to hd1. The fix remains the same, run update-grub upon the first reboot.

[donlassini (donlassini)]

I installed 12.10 on a totally blank computer with a new media and had the same problem.
It has a CF slot, hence I'm installing 12.10 on the CF card from a USB key.
At first reboot after installation, i get the same problem, namely
This is the case no matter if the usb key is inserted or not.

Using snippets from http://karuppuswamy.com/wordpress/2011/09/09/how-to-fix-grub-rescue-prompt-without-live-cd-for-grub2/ I am trying to at least boot once and get into a proper shell, and not just "grub rescue", but that's in vain.

I tried
>ls
(hd0) (hd0,msdos1)
>set prefix=(hd0,msdos1)/boot/grub
>insmod (hd0,msdos1)/boot/grub/linux.mod
error: attempt to read or write outside of disk 'hd0'.

*sigh*
I've always hated grub2.

[angelique (ange)]

Still present in 13.04.

[Steve Langasek (vorlon)]

This bug was last touched 9 years ago. We have been using uuids exclusively in grub for some time, and have not had recent reports of this issue. Presuming this is resolved and closing.

[Ubfan (ubfan1)]

Still present in Ubuntu 22.04 (original ISO). On a UEFI machine with one hard disk (sda), install media on USB (sdb), and a target USB (sdc, with sdc1 the EFI and sdc2 the root), run without network so no additional installations to force a grub update, the grub.cfg file still uses root=/dev/sdc2 on the linux kernel lines (default,advanced, and recovery). Remove the install media, and the created USB will fail to boot (gave up waiting for root on /dev/sdc2 which no longer exists, the reboot will have the USB on sdb as the only USB present.

Yes, the UUIDs are present in the search lines, but the parameter root=/dev/sdc2 on the kernel line overrides everything else. Of course, the bad grub.cfg gets dumped into the hard disk's EFI, since another ancient bug, 1396379, leaves the target USB's EFI empty (manually unmounted and remounted the /dev/sdc1 to prevent messing up the host system). These two bugs make it unnecessarily difficult to simply make a full Ubuntu USB.
Please change status back, no fix was ever released.

[Ubfan (ubfan1)]

Apparently a fix was included in the Ubuntu 22.04.1 ISO, since using that ISO results in the correct root=UUID=xxxx parameter on the grub menu's linux lines. In earlier testing of the problem, grub-mkconfig uses the (correct) device like /dev/sda2 in its output when the no grub.cfg file was present for the target kernel. When the grub.cfg file was present, grub-mkconfig just copied the kernel parameters to the output without any validation.

Three USB/USB installs were successful on machines with various hard disk configurations: 1) sda 2)sda, sdb and 3)nvme0n1. The USB install media and USB target were assigned names of the next free sdx letters after any hard disk assignments. In all cases, there was no use of root=/dev/sdx on the linux boot lines.