gave up waiting for root device


Results 1 to 15 of 15

Thread: gave up waiting for root device

  1. #1
    Join Date
    May 2004
    Location
    Philly
    Posts
    81

    gave up waiting for root device

    I did an installation of Ubuntu 8.1 on my laptop. I ran the live CD first to check that everything was ok and got no problems. But when I try to boot I get this error:

    Boot from (hd0,0) ext3 e194-… long number

    Gave up waiting for root device.
    Alert /dev/disk/by-vvid/e194-… long number

    I tried a different hard drive with the same results. So I installed XP and everything worked fine.
    This makes me believe that all of the hardware is ok and I have some config screwy. Any ideas?

  2. #2
    Join Date
    Jun 2003
    Location
    People's Republic of North America (Former United States)
    Posts
    849
    A little Googling led me to this thread. It does seem to contain some answers:

    http://ubuntuforums.org/showthread.php?t=981159
    I equivocate, therefore I might be.

    My Linux/Unix Boxes:
    Home: Slackware 10, CentOS 5.3, RHEL 5, Ubuntu Workstation 9.10, Work: RHEL 5, CentOS 5

  3. #3
    Join Date
    Jun 2004
    Location
    Newcastle upon Tyne
    Posts
    2,978
    I think there may be a mismatch of the device name.

    The traditional partition name is still /dev/sdax. Ubuntu is among the first distros pioneering the by-uuid method based on a unique number generated for each partition. If this is not found the distro will not be able to locate its root partition.

    The way to investigate is to boot up a Live CD and print out the /dev/disk/by-uuid directory to see what partition names are picked up by Ubuntu and then check them with those listed in the boot loader file /boot/grub/menu.lst from the installed Linux.

    If the two match Ubuntu should work. The by-uuid names can be replaced by the traditional /dev/sdax without any bother to Ubuntu. I often do it myself when I have no time to investigate.

    As an example

    My Ubuntu's /dev/disk/by-uuid output looks like this
    Code:
    saikee@saikee-desktop:~$ ls -l /dev/disk/by-uuid
    total 0
    lrwxrwxrwx 1 root root 10 2009-02-08 01:38 0e0848ec-89a0-485b-9a3d-ddf9d6bfcf9a -> ../../sda9
    lrwxrwxrwx 1 root root 10 2009-02-08 01:38 16B834B1B83490EB -> ../../sda2
    lrwxrwxrwx 1 root root 10 2009-02-08 01:38 19edef3e-93d7-4070-95f1-ad53aa496720 -> ../../sda4
    lrwxrwxrwx 1 root root 11 2009-02-08 01:38 1e097bea-f2d8-424e-b347-b9644fc7ce20 -> ../../sda14
    lrwxrwxrwx 1 root root 11 2009-02-08 01:38 3b1c14a3-0196-4998-8d37-937a727dc74c -> ../../sda15
    lrwxrwxrwx 1 root root 11 2009-02-08 01:38 4115f099-1188-4b98-a42d-15c37075b4c2 -> ../../sda10
    lrwxrwxrwx 1 root root 11 2009-02-08 01:38 449f552a-b7c8-4a1b-906a-034e7915e5af -> ../../sda12
    lrwxrwxrwx 1 root root 10 2009-02-08 01:38 5a4a7454-593b-45b6-99c2-4b6fab2596e4 -> ../../sda7
    lrwxrwxrwx 1 root root 10 2009-02-08 01:38 6af3352f-71c1-455f-a011-77cab3666a33 -> ../../sda5
    lrwxrwxrwx 1 root root 10 2009-02-08 01:38 6da97301-a9a4-401c-a653-4302660cf5bc -> ../../sda8
    lrwxrwxrwx 1 root root 10 2009-02-08 01:38 80db91a1-b3f2-42b2-b3a2-9cb6e5f71b8b -> ../../sda6
    lrwxrwxrwx 1 root root 11 2009-02-08 01:38 ca1050f1-9511-4fd7-8ed8-ea312fb05f7b -> ../../sda11
    lrwxrwxrwx 1 root root 10 2009-02-08 01:38 D4E0E31EE0E30598 -> ../../sda1
    lrwxrwxrwx 1 root root 11 2009-02-08 01:38 e8a97d79-547b-4da5-a7e7-b4be8c7f7c8c -> ../../sda13
    The lines that boot Ubuntu of my /boot/grub/menu.lst are
    Code:
    title		Ubuntu 8.04, kernel 2.6.24-18-generic
    root		(hd0,5)
    kernel		/boot/vmlinuz-2.6.24-18-generic root=UUID=80db91a1-b3f2-42b2-b3a2-9cb6e5f71b8b ro quiet splash
    initrd		/boot/initrd.img-2.6.24-18-generic
    The information suggests my Ubuntu is in partition /dev/sda6. I can replace
    Code:
     root=UUID=80db91a1-b3f2-42b2-b3a2-9cb6e5f71b8b
    with
    Code:
    root=/dev/sda6
    in the Grub statement and the Linux will still boot normally (may need to revise the by-uuid reference in the /etc/fstab too).

    You can check yours the same way.
    Last edited by saikee; 02-07-2009 at 09:53 PM.
    Linux user started Jun 2004 - No. 361921
    Using a Linux live CD to clone XP
    To install Linux and keep Windows MBR untouched
    Adding extra Linux & Doing it in a lazy way
    A Grub menu booting 100+ systems & A "Howto" to install and boot 145 systems
    Just cloning tips Just booting tips A collection of booting tips

    Judge asked Linux "You are being charged murdering Windoze by stabbing its heart with a weapon, what was it?" Replied Linux "A Live CD"

  4. #4
    Join Date
    Jan 2003
    Location
    Austin, Texas
    Posts
    683
    Also, if you want to find out what the UUID is for a partition just use this command (replacing /dev/sdxx with the partition you are interested in, for example /dev/sda1):

    Code:
    sudo vol_id /dev/sdxx
    It will print out several lines of information about that partition. If you want ONLY the UUID you can use the -u option:

    Code:
    sudo vol_id -u /dev/sdxx
    "The author of that poem is either Homer or, if not Homer, somebody else of the same name."

  5. #5
    Join Date
    May 2004
    Location
    Philly
    Posts
    81
    I typed 'exit' and it booted up just fine. It even deteced the wireless card. I need to edit my /boot/grub/menu.lst

    It comes up with 3 as the default:

    ## timeout sec
    # Set a timeout, in SEC seconds, before automatically booting the default entry
    # (normally the first entry defined).
    timeout 3

    I tried both 1 and 12 and it still gives up. What if I put in ZERO or comment out that timeout altogether?
    Last edited by FrankBlourtango; 02-08-2009 at 12:59 PM.

  6. #6
    Join Date
    Apr 2001
    Location
    SF Bay Area, CA
    Posts
    14,936
    That's a different timeout.

    That timeout is the one that controls how long grub waits for the user to choose an OS to load. (After that timeout expires, grub chooses the default entry. Just like it says in the comment. ) Setting it to zero will either make grub wait forever, or make it choose the default immediately, I'm unsure which.

    However, none of this affects how long the initramfs waits for the by-uuid symlink to show up. (The symlink itself is created by udev.) That's the timeout that you need to extend, especially since it works if you simply wait a while longer and "exit" from the initramfs shell. It is possible that your distro's initramfs has a way to specify an extra time to wait for the root device to show up (e.g. some that I've seen will parse a "rootdelay=X" option from the kernel's command line, and sleep for X -- there's no standard on that, but try rootdelay=10 or so, and if that does make it sleep a while, you can extend the timeout if needed). Once you find a delay that works, then edit menu.lst.

  7. #7
    Join Date
    May 2004
    Location
    Philly
    Posts
    81
    Here is what I did to fix it. I added rootdelay=40 to the top entry in menu.lst like so:


    title Ubuntu 8.10, kernel 2.6.27-11-generic
    uuid a9d96802-b2f1-4a49-8fd5-a15ac8961217
    kernel /boot/vmlinuz-2.6.27-11-generic root=UUID=a9d96802-b2f1-4a49-8fd5-a15ac8961217 rootdelay=40 ro quiet splash
    initrd /boot/initrd.img-2.6.27-11-generic
    quiet

    Now she boots up just fine!


    Thanks for your help guys! Between JustLinux and Google we can solve all problems!
    Last edited by FrankBlourtango; 02-09-2009 at 10:47 AM.

  8. #8
    Join Date
    Jul 2002
    Location
    New Orleans, LA USA
    Posts
    986
    Sorry to hijack the thread... but reading through it gave me an itch I just have to scratch.

    What advantage are we gaining by going to UUID to make even the concept worth while?

    Code:
    kernel		/boot/vmlinuz-2.6.24-18-generic root=UUID=80db91a1-b3f2-42b2-b3a2-9cb6e5f71b8b ro quiet splash
    This is cryptic to me and means nothing at a quick glance.

    Code:
    kernel		/boot/vmlinuz-2.6.24-18-generic root=/dev/sda1 ro quiet splash
    This tells me the bus is either SATA or SCSI, the partition is the first partition on the primary master (or SD0) position. Short, simple, and straight to the point. Why on earth would any distro even consider a UUID that would only complicate (and potentially break) an already working system? I have to be missing something...
    "Whenever you find yourself on the side of the majority, it's time to pause and reflect."

    -Mark Twain

  9. #9
    Join Date
    May 2004
    Location
    Philly
    Posts
    81
    I don't get it either.

  10. #10
    Join Date
    Jun 2004
    Location
    Newcastle upon Tyne
    Posts
    2,978
    Our super mod bwkaz is very knowledgeable on this subject and will have a view but I try to put a few pointers here.

    As nowadays a motherboard can have at least two hard disk controllers of IDE and Sata. The latter can hook up some 6 to 8 disks. Putting external disks or jump drives through USB ports can increase also the number of block devices. It is out of control if one hooks up 8 to 12 internal and external hard disks, several USB devices and a few through the firewire port IEE1394a.

    Believe me if you remove one of two devices from the internal IDE/Sata controllers and the USB/IEE1394 ports the /dev/sdx can become uncontrollable.

    A simple example is if one has an IDE or Pata hard disk, a Sata hard disk, an external USB hard disk and another disk connected to an IEE1394 port. Most mobo detecting sequences will name them as sda, sdb, sdc and sdd. If the IDE/Pata disk is withdrawn the device names of sda, sdb and sdc with be given to Sata, USB and IEE1394 disk and there will no sdd. If the USB disk is removed or another one added the lastly detected firewire disk can become sdb or sdd respectively. This is just a start because Grub has its own hard disk by-number naming convention so the 2nd hard disk (hd1) can be anyone depending on how the hard disks are arranged. If this is not confusing enough every mobo allows the user to select any of the disk to be the first bootable disk (hd0). It can be a nightmare for the user to mutli-boot and I haven't even touched on the SCSI hard disks and eSata disks yet.

    The by-uuid method is the only sure method to address each partition because the by-uuid numbers are uniquely generated by the OS.

    I don't know the exact score but new MS systems like Vista are using this system too, so it may be a matter for Linux trying to be compatible with the new changes and not dropped too much behind.

    The traditional method of /dev/sdax still work satisfactorily if you do not regularly add and withdraw the disks from the PC or if you do you understand the hardware detection sequence and will to update the settings whenever necessary. I choose the latter because /dev/sdax is many time easier than using a by-uuid number like 80db91a1-b3f2-42b2-b3a2-9cb6e5f71b8b.

    One should be aware that the by-uuid device names are just alternatives to /dev/sdax as indicated in the /dev subdirectory so it is up to the individual to choose what he/she likes. Many distros are still quite happy with the traditional method. The kernel is of course deals with the traditional names in most commands.

    The by-uuid is not as horrible as I sound if you use only a few hard disks. The Red Hat family (Fedora etc) also uses a by-label method for as long as I can remember. Recent OpenSuse is keen to sell us the by-id method.

    The by-uuid or the other partition addressing methods only affect the booting configuration file /boot/grub/menu.lst and the Linux system file /etc/fstab (possibly /etc/mtab too which I never bother with). One can keep on using the /dev/sdax addressing. If there is a need to use uuid because the installer insists on it then check the device names in /dev/disk.
    Last edited by saikee; 02-10-2009 at 04:39 AM.
    Linux user started Jun 2004 - No. 361921
    Using a Linux live CD to clone XP
    To install Linux and keep Windows MBR untouched
    Adding extra Linux & Doing it in a lazy way
    A Grub menu booting 100+ systems & A "Howto" to install and boot 145 systems
    Just cloning tips Just booting tips A collection of booting tips

    Judge asked Linux "You are being charged murdering Windoze by stabbing its heart with a weapon, what was it?" Replied Linux "A Live CD"

  11. #11
    Join Date
    May 2004
    Location
    Philly
    Posts
    81
    Hmmm. That makes sense.

    My problem wasn't the scheme but the delay. I wonder what it is with laptops where that fails.

  12. #12
    Join Date
    Jun 2004
    Location
    Newcastle upon Tyne
    Posts
    2,978
    FrankBlourtango,

    Your problem may be transitory and specific to the CPU speed of the laptop, slow hard disk, size of the kernel or initrd file or other factors. Other faster machines on faster hard disk may experience no such error.
    Linux user started Jun 2004 - No. 361921
    Using a Linux live CD to clone XP
    To install Linux and keep Windows MBR untouched
    Adding extra Linux & Doing it in a lazy way
    A Grub menu booting 100+ systems & A "Howto" to install and boot 145 systems
    Just cloning tips Just booting tips A collection of booting tips

    Judge asked Linux "You are being charged murdering Windoze by stabbing its heart with a weapon, what was it?" Replied Linux "A Live CD"

  13. #13
    Join Date
    Apr 2001
    Location
    SF Bay Area, CA
    Posts
    14,936
    I have only one thing to add to saikee's explanation of the reason for UUID-based device names. It is possible (though probably extremely unlikely with current kernels and most people's setups) for exactly the same hardware configuration to assign different sdX device names to different drives on successive boots.

    The standard version of this is two different USB-connected disks -- they will get named (effectively) randomly from one boot to the next, because the USB bus enumeration is not forced to go sequentially. (At least, not AFAIK.) The /dev/disk/by-uuid/* symlinks, though, will always point to the correct partitions.

    Even in non-USB setups, future kernels may start randomly assigning disks to sdX names (the assignment order is not part of any official ABI). I will admit that this is probably fairly unlikely, but it's not impossible.

    In a setup where disks get randomly assigned to sdX names, you need to be able to ID the disk by some characteristic of the disk itself. That's the info that gets used to build the /dev/disk/by-* directories.

  14. #14
    Join Date
    Jul 2002
    Location
    New Orleans, LA USA
    Posts
    986
    That makes sense... I guess from my viewpoint the booting medium (unless a live cd/dvd/usb stick) will always be fixed - as in connected to the primary master, sd0 on sata, position 0 on scsi, etc. so setting a hard link both seems the most direct method and easiest to understand where things are pointing. Furthermore, if I were to add a second drive to multi-boot I would be conscious of what cable I connected it with and update my list accordingly. I never was a fan of booting from an external USB hard drive - strictly portable storage.

    To each their own... As long as systems allow both methods then I have nothing against the UUID system. If they try to move to UUID only, then you'll hear me squawking very loudly.
    "Whenever you find yourself on the side of the majority, it's time to pause and reflect."

    -Mark Twain

  15. #15
    Join Date
    Apr 2001
    Location
    SF Bay Area, CA
    Posts
    14,936
    It'll always be fixed for you; great! It will not always be fixed for the general distro installer, though.

    Also, there have been rumblings in the past about assigning sdX names randomly; I don't know if that's being seriously considered or not, but if it ever is put in, you'll have to have some better way to find all your devices. I should emphasize: that does NOT have to be the UUID (though systems that use it today will be unaffected); an individual can choose to use the manufacturer and serial # of the disk (if that info is available and reliable), or the physical path, or the FS label.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •