Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

what happens when we uncomment GRUB_DISABLE_LINUX_UUID=true in /etc/default/grub.

share|improve this question
    
In my opinion the usage of UUID's for identifying partitions and volumes is bad practice and sometimes leads to disaster: those random generated identifiers are not robust at all , in fact they don't even survive a re-partitioning & re-formatting , which will result in an unbootable system and usable /etc/fstab entries .They are hard to type en don't convey any meaning about the partitions-content to the user . LAbels on the other hand , if well chozen will tell a lot about the partitions contents. All my partitions are labeled : like WIN7_C , XP_D , XUBUNTU_1204 , BOOT ,HOME_1204 etc ... Refo –  eric stockman Apr 21 '13 at 14:52
add comment

3 Answers

  • Well i think the comment above that line says it all
    # Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux

  • After uncommenting that line root= will be passed as device name and not UUID.

    linux /boot/vmlinuz-2.6.30-1-amd64 root=UUID=...
    to
    linux /boot/vmlinuz-2.6.30-1-amd64 root=/dev/sdX

  • However it is not recommended to uncomment that line,coz if you delete/create a new partition the partition table will get changed.
  • So that you cant boot into the system.
share|improve this answer
    
-1, uninformative. What's the effect of removing that paramter? What are the advantages and disadvantages? –  loevborg Dec 25 '10 at 18:53
    
@loevborg root= will be passed as device name and not UUID –  karthick87 Dec 25 '10 at 19:05
add comment

when uncomment it, the next time grub regenerates /boot/grub.cfg will put absolute device names instead of UUID- i.e. /dev/sdXY

so if you re-arrange partitions in partition table (for example insert/delete partitions) and partition numbers changed- grub can't find the kernel to boot

with UUID, even re-arranging the partitions won't break things

the con of UUID is that its hard to they are long and therefore hard to remember.

share|improve this answer
add comment

The real deal is about adding disks to your system. If your disk was previously /dev/sda, and was plugged into SATA1 as the only drive, and later you added a second drive, but plugged it in to SATA0, it would become /dev/sda, and your root= mapping would be invalid. UUID's don't have this issue however, since they are unique identifiers.

Also if you have several expansion cards, they are sometimes detected at slightly different times, resulting in different drive name assignments for the drives hanging off them. Again, UUID is unaffected. Also if a drive goes dead, sometimes another drive takes it's place, e.g. if /dev/sda dies, perhaps on next boot /dev/sdb magically becomes /dev/sda.. It happens.

I'd say the bigger the system it is or is likey to become, the more possibilities of a drive shuffle on boot..

Personally I don't care for using UUID's for root=, but I see where it has it's place.

share|improve this answer
    
Can you indicate what the true means? I mean what precisely does disable linux uuid do? –  DrSAR Apr 19 '13 at 19:49
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.