Ubuntu
partman-target package

The policy to mount system disk with UUID is bad

Bug #321324 reported by Roland Orre
4
Affects Status Importance Assigned to Milestone
partman-target (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

Binary package hint: partman-target

See also bug 320872 where I added this bug as a comment.

The current policy to use UUID for the system disk instead of the good old devices is a really bad idea.

1) Disk cloning is now a real hassle, as you have to edit both /etc/fstab as well as /boot/grub/menu.lst to make the system sane again.

2) To make backups of ones disk has the same problem. My way of backing up my laptops is to have a perfect mirror, so if something happen I just swap disks and boot from the backup.

3) I really don't see the point, only disadvantages with, having the standard partitions mounted with UUID.

UUID is great for removable storage devices, but certainly not for the system disk.

Please give us back the easy to handle devices in fstab and menu.lst! Each time I install a new system now I have to manually edit /etc/fstab and /boot/grub/menu.lst to remove these stupid UUID references. I'm also running a course in Linux at the moment, and I would be glad if I could tell the students a good reason for things to be in a certain way, but UUID in fstab is just annoying.

If you don't want to remove the UUID, then at least make it selectable (and default not UUID) in the installation.

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

1) Is it really that much effort to have to edit 2 files?

2) That might be more tricky, but can't you just edit the UUID, or use something like rsync to backup files (which is what I do)

3) You say you don't see the point with UUID's and you only see disadvantages? Well, point number 1 for UUID's - devices don't always enumerate in the same order (especially with removable hardware about), so you can't gurantee that your device nodes will be the same on every boot. UUID's (and LABEL's) are a lot more reliable than device nodes.

You are free to edit your fstab to use device nodes as opposed to UUID's if you so wish, but it shouldn't be default

Changed in partman-target:
status: New → Invalid
Revision history for this message
Roland Orre (roland-orre) wrote :

I really don't agree with you. I have run Linux since 1996 and never ever have the device nodes of the boot disk got any other numbers than /dev/hda or /dev/sda

For the removable devices I do agree, but disks attached with IDE or SATA are not considered to be removable, and certainly nothing you normally boot from.

So, it seems to be time to head for another distribution then if you are that stubborn about this.
You could at least make it selectable in the installation. Now, it will be a real hassle for all beginners.
It is even said in the /boot/grub/menu.lst that you shouldn't edit, how helpful!

So, you really don't like the idea that you can have cloned disks which are all bootable?

About the backup, of course I'm running rsync between my main disk and my mirror.

Revision history for this message
Colin Watson (cjwatson) wrote :

I don't intend to change this significantly. UUIDs do have their problems, but so does every other available method. That said, I do intend to fix bug 320871 for Jaunty, which will make it easier for system administrators to assign labels. Labels aren't appropriate for automatic assignment, though, so UUIDs will remain as a fallback.

I'm afraid you're demonstrably mistaken that the boot disk can never change its device name. If nothing else, it's not that long since most IDE controllers were taken over by the PATA subsystem in the kernel, which changed nearly everyone's /dev/hda to /dev/sda. That was the impetus for us implementing UUID support. Even beyond that, enumeration order is not guaranteed to be stable if you have multiple disks.

I posted a verbose summary of the issues here, which you can explain to your students if you like:

  http://lists.debian.org/debian-boot/2008/12/msg00338.html

Changed in partman-target:
status: Invalid → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.