Interesting recovery frustrations

[MR ZenWiz]

On Fri, Dec 17, 2010 at 6:28 AM, Tom H <tomh0665 at gmail.com> wrote:
>
> When reformatting?! Why not also include the possibility of swapping a
> disk out and ending up with a different hardware ID?!
>
How does this not fit into "physically moving the drive connectors?"
Don't confuse physical changes with software-induced modifications -
there is a significant difference.

> I recently had a box where the kernel module load order changed after
> an update and the device names changed.
>
That sounds quite unusual to me, but it is indeed on a par with a
hardware change that affects drive order - how often does a kernel
module change affect drive ids?  Rarely.

> So device names aren't more
> persistent than UUIDs or labels (at least for that reason). For a
> single install, filesystem UUIDs don't change except when you dual-,
> triple-, quadruple-, ...-boot and you allow mkswap to run during the
> install of the nth OS. The swap partition's UUID is then changed...

When you generalize from a corner case, you weaken your own argument.

> You seem to be agreeing with the earlier ranter about using device
> names and thereby deviating from Ubuntu standards in a worse way than
> enabling root because you can (CAN!) make a system unbootable.
>
If you insist on reading your own ideas into what I posted, you are
free to do that but it doesn't make your words mine.  If you're
*asking* if that's what I said, the answer is no.

What I said is that I prefer to use labels for device naming and
mounting. mainly because *I* decide what the labels are, not a
formatter or the OS or the hardware.  *I* prefer that level of
control.  Using labels I was able to recover and boot my Ubuntu.  If
I'd had to go through at least one other round of live CD booting just
to read the UUIDs and possibly get them wrong, I might have gone
completely mad.  My labels gave me a shortcut that worked.  Others are
free not to use that method, and if newer works for you, go for it,
but don't expect everyone to.