Disk by UUID not detected (initramfs), boot failure

I am unable to boot Ubuntu 10.04, with the built in boot shell giving out this 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?)
  — Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/disk/by-uuid/aa91b9fe-1e27-44d7-9c1b-72dd7d4e8575 does not exist.   
Dropping to a shell! 

BusyBox v.1.13.3 (Ubuntu 1:1.13.3-1ubuntu11) built-in shell (ash)   
Enter 'help' for list of built-in commands.  

(initramfs)

Update 1
This error occurred after I updated my 2.6.32-26 version kernel and booted directly in Windows.

The rootdelay solution did not work. Is there any chance that my disk's uuid got changed (maybe by windows), I could log in to my Ubuntu earlier but after logging into windows, and rebooting I get this error. As far as backing up is concerned, do I need to even if I have separate home and workspace partitions than Ubuntu installation?

Update 2
The update after which this happened was just an update (no new install) of version 2.6.32-26. So I guess this has something to do with last update of this version of kernel. Also since it was not a new install, no new menu entry was added. By any chance may this be caused because of my rebooting in Windows after the kernel update.

Update 3
Installed older kernel by chrooting through live USB, still the same problem with the kernel, so it seems the problem is not due to kernel update after all.

I have faced this problem earlier too but back then, I just considered reinstalling distribution easier (I used to distro switch a lot). But now I had configured it too far and so looking for some last resort.

Update 4
Reinstalled Ubuntu. Configuration was easier this time thanks to separate home and workspace partitions. Even tough I don't need the solution of this problem just now but if you know any possible solution please post here for future benefit.

I had the same issue like the thread starter and I solved it without reinstalling.

My issue occurred while juggling with a virtual installation based on a copied disk image. This resulted in a changed uuid and the copy wouldn't start. This is a rough sketch of what i did.

First boot using a rescue system (same version) and run a shell on your non-booting disk. Have a look at /etc/fstab and confirm the uuids there by issuing the blkid command for each device. Fix these entries as they're important.

Next we fix grub with:

• grub-mkconfig
• update-grub

Then run:

• update-initramfs -u /boot/initrd.img-2.6.YOURVERSION-HERE

This will create a fresh initramdisk for your version. If you don't know the exact version you were running have a look at the files in /boot/. Picking the highest version number should be safe.

After you exit the rescue shell the ubuntu live cd will offer you the last menu from where you entered the shell. Choose "install Grub" (or similar) there and enter the device where to put your boot sector.

On most systems (standard install) /dev/sda is a safe bet. Be aware: Windows- or other multiboot-systems might need other entries here!

Finally you should be able to boot from the repaired disk.

The problem seems to be that your hard disk, or the controller, doesn't respond quickly enough.

Try the following:

• When the boot menu comes up, having the top of the list highlighted, press e (for edit).

• You should see a long list of parameters. Add this one to it: rootdelay=130

• Hit Enter and then b (boot). Try to see if you system boots now. You can increase the value if that doesn't help first time (but not by much, 130 is already more than enough for any hardware that isn't broken).

However, it may also be your hard drive is failing. The first thing to do once you get back into your system is backing up your data. If you want to be safe, back it up using an ubuntu cd. I strongly urge you to do that, sooner rather than later.

As a matter of fact I have experienced disk UUIDs changing spontaneously once or twice. The change may be the result of a corruption of some sort. I would try the following:

• Boot your computer from a live medium;
• fdisk -l /dev/sda to find the partition you're looking for; or use cfdisk; or usegparted(replacesda` by your hard drive).
• blkid /dev/sda1 (replace sda1 by the partition you found); alternatively use vol_id;
• see if you can mount the partition (using the device file /dev/sda1);
• check if the UUID displayed matches with the UUID in your root partition's /etc/fstab;
• generate a new UUID using uuidgen and apply it to the partition using tune2fs -U;
• change the fstab entry accordingly.

It might seem unlikely that something as vital as the UUID changes without apparent cause, but it happens, probably because of a bug. See if changing the UUID to a new value helps.

When I saw this on my system, it was a matter of the wrong UUID being set as the boot root parameter in /boot/grub/menu.lst .

cat /proc/cmdline actually shows the boot parameters passed to initramfs -- if you see that initramfs is being told to mount a non-existent root partition, it's obviously going to fail.

update-grub did not update these parameters for me, but simply doing a manual replacement for the old UUID in the menu.lst fixed it for me.