9.10 does not boot - error: no such device - failed to boot default entries

[alphabootis]

Problem

Karmic 9.10 does not boot after recent system update (update manager):

error: no such device : ba123456-7890-abcd-efghijklmnop
Failed to boot default entries
Press any key to continue

On pressing any key error message is repeated.

Same error occurred after the initial installation of 9.10 on various laptop models.

Note: In my case error only occurs when karmic 9.10 is installed on 250 GB Western Digital hard drives. On SAME laptops Error does NOT occur when karmic 9.10 is installed on 60 GB Hitachi hard drives.


Workaround

- boot system from from karmic 9.10 CD
- start terminal
- start nautilus file manager as admin (sudo nautilus)
- in nautilus select laptop's internal drive
note: I had to first start nautilus as user in order for it to show internal drive
- go to /boot/grub/grub.cfg
- right-click grub.cfg and choose properties
- select tab permissions
- change permissions of 'owner: root' from 'read-only' to 'read and write'
- right-click grub.cfg and open with gedit
- find the following entry:

### BEGIN /etc/grub.d/10_linux ###
menuentry "Ubuntu, Linux 2.6.31-14-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 ba123456-7890-abcd-efghijklmnop
linux /boot/vmlinuz-2.6.31-14-generic root=UUID=ba123456-7890-abcd-efghijklmnop ro quiet splash
initrd /boot/initrd.img-2.6.31-14-generic
}

- simplify entry as follows:

### BEGIN /etc/grub.d/10_linux ###
menuentry "Ubuntu, Linux 2.6.31-15-generic" {
set root=(hd0,1)
linux /boot/vmlinuz-2.6.31-15-generic root=UUID=ba123456-7890-abcd-efghijklmnop ro quiet splash
initrd /boot/initrd.img-2.6.31-15-generic
}

- safe grub.cfg
- change permissions of 'owner: root' from 'read and write' back to 'read-only'
- restart system
- ubuntu should now boot from first internal drive (hd0)


Community

I'm a Mac/Windows user. Ubuntu is new to me and I love it. However, this error is very severe and produces a really negative experience for new users. I would actually not even be surprised if this error had been deliberately introduced by someone who is not too fond of the Linux Community. Anyway, it would be great if the experts here could help us newbies and protect the community.

Could someone please post a shell command version for a clean workaround?

What is the exact nature and background of this error?

A recent system update just reactivated the error by replacing the modified grub.cfg with the flawed grub.cfg, i.e. my system didn't boot after the update. The problem is obviously not solved. Is there already a bug report for this error?

What is this this UUID all about? Is it something that was invented to protect our privacy? Anyone?


Thanks!

[drs305]

If you can't access your system, from the Grub 2 menu: Press ENTER after each line; # are just clarifying comments - do not type them.

c  # enter command line mode
set root=(hd0,1)  # to set sda1 as root
linux /vmlinuz root=/dev/sda1 ro
initrd /initrd.img
boot

Once into the system, open /etc/default/grub:

sudo gedit /etc/default/grub

You can try disabling the UUID function to see if that solves things for you (uncomment it):

GRUB_DISABLE_LINUX_UUID=true

Update Grub2:

sudo update-grub

[alphabootis]

I changed grub.cfg as described above and my system now boots and works. However, the grub2 menu is no longer being offered.

Also the next system update that will overwrite my modified grub.cfg with the original flawed grub.cfg will leave my system unbootable again.

What is the root of the problem and how can it be solved?

[drs305]

I changed grub.cfg as described above and my system now boots and works. However, the grub2 menu is no longer being offered.

Also the next system update that will overwrite my modified grub.cfg with the original flawed grub.cfg will leave my system unbootable again.

What is the root of the problem and how can it be solved?

Normally you change the settings in /etc/default/grub to affect the menu display. The two lines to change so you see your menu are (with settings so you see the menu):

#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT="10"

Run "sudo update-grub" to make the changes permanent.

If you don't want to run update-grub for fear it may put back in settings that might make your system unbootable again, the line in /boot/grub/grub.cfg that the above settings change are:

if [ ${recordfail} = 1 ]; then
set timeout=-1
else
set timeout=10
fi

As for the cause, there have been some problems with the UUID feature of grub. I thought they were resolved but some may linger. There was also a new kernel released recently which may be causing problems unrelated to the grub menu (but probably not for what the OP posted).

[jesper_eskilson]

I have the same problem (I think), but I've installed Ubuntu using wubi, so my root fs is a virtual disk on a windows NTFS drive, and I can't get the proposed fix to work. Here's what I did:

First, when booting the machine I get the windows boot loader, and I select "Ubuntu". This brings me into the Grub command shell (with a "sh:grub>" prompt). In the grub command shell, I typed:

set root=(loop0)
linux /vmlinuz root=/dev/sda1 ro
initrd /initrd
boot

Loading the kernel works, but then it fails with the error message "Target filesystem doesn't have /sbin/init", and suggests that I pass "init=" to the kernel when booting. I tried passing "init=/init", but that didn't work.

Any ideas?

[drs305]

I have the same problem (I think), but I've installed Ubuntu using wubi, so my root fs is a virtual disk on a windows NTFS drive, and I can't get the proposed fix to work. Here's what I did:

First, when booting the machine I get the windows boot loader, and I select "Ubuntu". This brings me into the Grub command shell (with a "sh:grub>" prompt). In the grub command shell, I typed:

set root=(loop0)
linux /vmlinuz root=/dev/sda1 ro
initrd /initrd
boot

Loading the kernel works, but then it fails with the error message "Target filesystem doesn't have /sbin/init", and suggests that I pass "init=" to the kernel when booting. I tried passing "init=/init", but that didn't work.

Any ideas?

You would at least have to have "initrd /initrd.img".

I installed wubi yesterday and played with the command line until I found what I needed to enter. The results are here:
http://ubuntuforums.org/showpost.php...3&postcount=62
If that doesn't take you directly to the post, it is post #62.

Of course, this may get your Grub 2 to try to pass control to the kernel, but if there is a kernel problem or something else, it isn't something Grub can probably fix unless you are using extra command options such as "vga=791" on the linux command line.

@ashto - the last sentence probably applies to you as well.

[wmrojer]

I have the exact same problem as the original poster.

I've done a 2 fresh install of Ubunti 9.10 on a system with 2 IDE disks. On the 40GB WD disk grub2 finds the correct root device but on the 120GB Seagate disk it fails.


I've done several clean installs on both disks, and the result is the same every time. Works on the 40GB disk, fails on the 120GB disk.

The search command results in the error message "no such device d8e4a234-9bfe-4517-8e0e-320a333d03d7"

search --no-floppy --fs-uuid -set d8e4a234-9bfe-4517-8e0e-320a333d03d7

But the linux command seem to work just fine.

linux /boot/vmlinuz-2.6.31-14-generic root=UUID=d8e4a234-9bfe-4517-8e0e-320a333d03d7 ro quiet splash

Setting

GRUB_DISABLE_LINUX_UUID=true

in /etc/default/grub only affects the use of uuid on the linux command, not the search command. So it does not have an effect.

Doing a ls command on the partition from the grub prompt shows that the uuid is correct.

I've seen on the grub2 wiki http://grub.enbug.org/ that there is both a 1.97 and a 1.97.1 version released. But I guess those haven't made it into ubuntu yet.

I hope that this bug gets fixed soon, but at least I know how to boot my system now.

[drs305]

I have the exact same problem as the original poster.

The search command results in the error message "no such device d8e4a234-9bfe-4517-8e0e-320a333d03d7"

in /etc/default/grub only affects the use of uuid on the linux command, not the search command. So it does not have an effect.

Doing a ls command on the partition from the grub prompt shows that the uuid is correct.

I've seen on the grub2 wiki http://grub.enbug.org/ that there is both a 1.97 and a 1.97.1 version released. But I guess those haven't made it into ubuntu yet.

I hope that this bug gets fixed soon, but at least I know how to boot my system now.

I saw a discussion of this topic by the devs this morning. So far the only way to automatically get rid of the "search" line is by modifying the grub-mkconfig library file, which can be done but would probably be overwritten by the next update to grub (not to be confused with update-grub). But removing the "search" line does seem to fix it in most of these cases.

Don't know when Ubuntu is going to update to 1.97 but I don't think there will be any really huge improvements for most users.

[olofcadiz]

Hi

I had the same problem and solved it on another way.
first I installed 9.04 and then upgraded to 9.10
After that everything is working perfect

olofcadiz

[seks727]

I'm no expert but I had a simular issue and followed the instructions in the first page. Here is a quick run down of what i did to get it working for me.

1. When you're able to high-light a grub option and click 'e' to edit.
2. Next, follow the instructions on the first page of this thread, deleting the items in red and blue.
3. Now, type Ctrl+x to boot.
4. Once ubuntu starts open the terminal and type sudo nautilus (enter your password when prompted), a new window will popup with root permissions (admin rights).
5. Next navigate to the /boot/grub/grub.cfg file right click>properties>permissions. From here you can set the permissions from read only to read and write.
6. Finally, open the grub.cfg file with gedit and edit the section described in page one of this thread and save.
7. Reboot to test.

Hope this helps...