# booting from uuid with grub

## alex.blackbit

hi,

i am confused.

since i have some problems with persistent storage names, i wanted to move to using UUIDs.

they work as expected in /etc/fstab.

but i can't get them to work in grub.

what do i have to do to use them ?

there are several web references that tell a syntax like

```
kernel /vmlinuz root=UUID=4a2464b4-c865-4681-b9d9-5d8aef1e2215
```

some others say that only works with an initrd.

i don't have an initrd, and i don't want to use one.

is it possible to use UUIDs in grub ?

----------

## Gentree

IMHO UUIDs suck . Basically for being totally unreadable to humans. 

yesterday I had a mate with a system that had had several mandrake/suse installations and needed fixig. I needed to see what's what.  I mounted the partition , looked at /etc/fstab and got a face full of UUID. Cool!

Also you lose the uuid if you reformat or resize a partition.

The current mode for handling virtually all periferals as /dev/sd* is the root of much of this. There may be ways around that situation depending upon hardware. Firstly use libata for ATA drives. This is NOT deprecated, use it.

If you're really intent on uuids I think you need to experiment with grub-2, make you own choice if that is "stable" enough to be used. I doubt it.

I suspect trying to making device names less volatile would be the better route.

 :Cool: 

----------

## alex.blackbit

thanks for your thoughts.

any info on booting from disk labels with grub 0.9? ?

----------

## sidarali

You need initird to use UUIDs.

In grub.conf when you specify root partition using uuid - kernel doesn't know what does that mean.

2 Gentree: I use UUIDs because on our fileserver hard drives connected to sata controllers appear before drives connected to motherboard sata ports - system drive sda becomes sdb while drive connected to additional SATA controller drive becomes sda. So each time we add hard drive to the system configs need to be updated.

----------

## Gentree

IMHO the best way to avoid that kind of insanity is to stop pretending everything connected to the machine is a scsi device. Use pata driver for pata drives not scsi-sata simulation.

hda is always hda   :Cool: 

----------

## i92guboj

Gentoo, not really.

hda will be hda as long as your kernel says it's hda. Just add another drive, change disk order, reconfigure your kernel in a different way or reorder some options in your BIOS and you will be stuck at the same silly problem each time. Thanks dog grub let you edit your boot options in real time, but that's not quite an optimal solution.

The real solution is to use an unique ID for a given device, that's absolutely the only way to make really sure that you are using the correct device, unless your box is completely closed to both hardware and software updates. 

There's absolutely no downside to using UUIDs, and your argument about them being unreadable is rather poinless, considering that "hda1" is not any more human readable. It doesn't tell you which disk are you using at all, the details will depend on the many factors I told you above. Unless you do a very careful study about the BIOS and the physical connections there's no way to tell what "hda" means. On the contrary, an unique ID will always belong to one (and only one) concrete device. People who continuously need to change their hardware configuration know what they talk about when they want and pray for UUID support in grub and fstab.

----------

## Gentree

 *Quote:*   

> 
> 
> PostPosted: Mon Apr 19, 2010 11:28 am    Post subject:
> 
> Gentoo, not really.
> ...

 duh, yes OK.

 *Quote:*   

> Just add another drive, 

 Err, no. hda will still be hda until I move it. 

 *Quote:*   

> change disk order, 

 Technically correct but improbably

 *Quote:*   

> reconfigure your kernel in a different way 

 Like what? Tell it pretend ide is scsi, that's what I'm suggesting to avoid. 

 *Quote:*   

> or reorder some options in your BIOS and you will be stuck at the same silly problem each time.

  Well you're scraping the barrel for this one. 

 *Quote:*   

> There's absolutely no downside to using UUIDs, and your argument about them being unreadable is rather poinless, considering that "hda1" is not any more human readable. 

 

```
root=UUID=4a2464b4-c865-4681-b9d9-5d8aef1e2215

root=/dev/hda1 

```

yeah right, no more readable at all !

I know where my ide drives are and I know which they are. I have no idea what the hell 4a2464b4-c865-4681-b9d9-5d8aef1e2215 is. IDE , SCSI, SATA, ext USB hard drive, a usb key .....

I have several partitions on most drives. What friggin use are a bunch of unintelligible UUIDs to me?

If I'm checking my hardware I can see where hda1 is by looking. I need to boot the system to "see" what a UUID is and even then I need to know the device name to find out!

If someone wants to use UUIDs they're free to do so. If you're booting from a number of different external USB drives , it may help. However, I'm suggesting not pretending everything peripheral on the system is a pseudo scsi may help limit the confusion.

----------

## i92guboj

 *Gentree wrote:*   

> If someone wants to use UUIDs they're free to do so. If you're booting from a number of different external USB drives , it may help. However, I'm suggesting not pretending everything peripheral on the system is a pseudo scsi may help limit the confusion.

 

Like it or not, it's the way things are going to be. Such is the trend in the kernel, and IDE drivers are going deprecated sooner or later. Im merely exposing facts, I have very little to gain from a discussion  :Wink: 

"hda" is not any more human than "foo-xlflggjhs-2" just like English is not any more human than Chinesse. The fact is that you know what hda is for you, but that doesn't grant it universal "humanity". Just look for hda in a dictionary and you will find it just next to "foo-xlflggjhs-2" (nowhere).

----------

## pigeon768

 *Gentree wrote:*   

> IMHO the best way to avoid that kind of insanity is to stop pretending everything connected to the machine is a scsi device. Use pata driver for pata drives not scsi-sata simulation.

  They're not pretending everything is a scsi device. They're pretending every disk connected to the machine is a disk. Which is a good thing.

----------

## SilverChild

FYI: UUID are tied to a partition not hard drive.

they also help when you have Linux installed on a USB powered hard drive and you never know when your drive will show up as sd[a|b|c|d|e|...]3. Using a UUID will always guarantee that you will mount the correct partition on the correct drive as your root and correctly mount any other mount points as well. That being said. If you don't want to use UUIDs then don't. I use them when I need them. The nice thing about Linux is what every way works for you is the right way!  :Wink: 

----------

## cyrillic

 *alex.blackbit wrote:*   

> there are several web references that tell a syntax like
> 
> ```
> kernel /vmlinuz root=UUID=4a2464b4-c865-4681-b9d9-5d8aef1e2215
> ```
> ...

 

This syntax works just fine with grub, and has worked for quite a long time.

The problem is that it doesn't work with your kernel, and that is why an initrd/initramfs is needed.

----------

## _Flame_

Try - "real_root=uuid"

----------

## Element Dave

 *Gentree wrote:*   

> IMHO UUIDs suck . Basically for being totally unreadable to humans. 
> 
> yesterday I had a mate with a system that had had several mandrake/suse installations and needed fixig. I needed to see what's what.  I mounted the partition , looked at /etc/fstab and got a face full of UUID. Cool!

 

Tools such as fdisk (-l), tune2fs (-l), dumpe2fs (-h) will give you more information.

 *Gentree wrote:*   

> 
> 
> Also you lose the uuid if you reformat or resize a partition.

 

You can assign the same UUID during format.  Resize would depend on the utility in question, but in either case you can assign UUIDs and labels to partitions after they're created; e.g., tune2fs -U <UUID> for an extx-formatted fs.

 *Gentree wrote:*   

> The current mode for handling virtually all periferals as /dev/sd* is the root of much of this. There may be ways around that situation depending upon hardware. Firstly use libata for ATA drives. This is NOT deprecated, use it.
> 
> If you're really intent on uuids I think you need to experiment with grub-2, make you own choice if that is "stable" enough to be used. I doubt it.
> 
> I suspect trying to making device names less volatile would be the better route.
> ...

 

You can always use labels...  You could even assign your disks labels such as /dev/[x]da* if you prefer that naming scheme..  Labels and UUIDs aren't exclusive either.

----------

## andrewwalker27

I think the idea of uuid's is good but, as I'm finding out to my cost, getting it working is as problematic as /dev/sd*. The reason I tried to use uuid was because my usb internal card reader screws up my /dev/sd* chain. Sadly decent up-to-date documentation of howto guides are hard to come by and setting up an initrd image is a nightmare if you don't really even understand why it's necessary.

What's really needed is a proper wiki page on how to set up Gentoo to boot grub using uuid's as that seems the way the rest of the Linux world seems to be going.

----------

## darkphader

 *sidarali wrote:*   

> You need initird to use UUIDs.

 

Sorry, that's incorrect.

----------

## s4e8

kernel >= 2.6.37, recognize the partition uuid, not filesystem uuid. older kernel don't support anything root by uuid.

partition uuid supported by EFI GPT, the correct grub commandline is 

root=PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF

----------

