> > If there is a key to unravel the info implicit in /dev/hdb3
> > (Primary partition on the Slave drive) from its UUID, would
> > someone please publish it.
The "old" system tells what drive and what partition it refers to.
UUID doesn't. If it did, I would complain MUCH less.
> create a file system, they all get a fresh new UUID.
But what if I don't want to? Say I have a 32-bit version of
Ubuntu with a separate /home partition. Assume that after that I
want to try the 64-bit version on a separate partition without
risking damage to my /home. so I just install all on the one
partition. If the install goes well, I need to change fstab so
it mounts my home directory, rather than the one it set up by
default. How, if UUID is all I have to identify it?
> you can
> change/create a new UUID with the filesystem utilities if you
> want. (like tune2fs, I believe, for ext3)
But it already has one, which is used (in the example above) by
an existing system.
> More bits = less chance accidentally duplicating a UUID from
> random creation.
That is _the_ issue, SFAIAC. I would not object to a rational ID
plus a random component, so there would be no duplication.
> I deal
> with system that have several hard drives on multiple
> controllers.. I assure you, this change is not only progress,,
> it's outright necessity.
Your server world is different from my desktop world. In my world
the trend is to fewer, but much larger, drives. In my world we
often have a "working" drive, and use the other
for "experimenting" - changing partitions and usage as desire
dictates. For us, UUID seems to present an unnessary barrier.
ubuntu-users mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users