Prev: pen drive without format and can not find it
Next: Incredibly useful Firefox addon: Hyperwords
From: Paul E Condon on 14 Mar 2010 13:20
On 20100314_142055, Tzafrir Cohen wrote:
> On Sat, Mar 13, 2010 at 11:13:14AM -0500, Tom H wrote:
> > > When I install a 2nd/3rd distrib on a HD, I have made it a practice
> > > to set up fstab so the existing distrib are mounted automatically.
> > > Repeated use leads to all functioning distrib to be crosslinked.
> > > But when a distrib must be reinstalled because something drasticly
> > > wrong happened, or whatever, access to that replacement distrib in
> > > all the older distrib is broken because the UUID of the partition
> > > is changed.
> >
> > You could make a note of the UUID before the re-install then re-apply
> > it to the partition with
> > tune2fs -U <uuid> /dev/sdaX
>
> However you *must* take a note. This is not something you can remember.
> As opposed to a partitioning scheme, that you can remember.
>
> UUIDs are also a fine method for making your life interesting when you
> want to recover a system backed up on a different hardware.
>
> For instance, I had a digikam images database on a system whose
> motherboard had some issues. No problems. I copied the whole thing to a
> new home directory (of the same user, same UID, same path) on a
> different system. However digikam fails to use the database. It insists
> I have the incorrect UUID. Natually it does not allow me to fix things.
>
> This is intended to protect against using the wrong DoK (but will
> "protect" you from copying the database to a different DoK). And
> couldn't have been disabled from the user interface at the time.
>
> It took me a few hours of digging in the code and file format to figure
> out how to fake a non-UUID database.
>
>
> So make sure you don't have the UUID listed in a host of places on the
> disk when recovering the system to a different media. {Or|And} just try
> to avoid it, if you can.

This is a more scary example of the dangers of the current UUID
situation than mine. Once the UUID is exists, there is no way to keep
developers from using it stupidly. I'm not surprised its digikam that
has this problem. I once swore by it as a way to have access to my
photos under my control. But now ... this just one more step away
from my vision of reality.

But you could not have used tune2fs on the new system to be equal to
the UUID on the old (failing) system? (rather than changing the value
of UUID recorded in the database) No fix to the database, just user
lie to the software. Real people always have the option of lying. One
might even say that communicating false information to a computer is
not lying, but merely instantiating a virtual reality.

Paranoid thought: Maybe the computers of the world communicate with
each other. When they are supposed to be idle, they are actually
exchanging UUID values of their internal components to be sure that
those values are, in fact, universally unique.

--
Paul E Condon
pecondon(a)mesanetworks.net


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/20100314171156.GF2170(a)big.lan.gnu
From: Tom H on 18 Mar 2010 00:40
>> You could make a note of the UUID before the re-install then re-apply
>> it to the partition with
>> tune2fs -U <uuid> /dev/sdaX

> However you *must* take a note. This is not something you can remember.
> As opposed to a partitioning scheme, that you can remember.

True but it should be common practice to keep easily accessible copies
of all disk "metadata" (fdisk -l, tune2fs -l, vgs, lvs, pvs, mdadm
--detail, ...) for every box.


> UUIDs are also a fine method for making your life interesting when you
> want to recover a system backed up on a different hardware.

> For instance, I had a digikam images database on a system whose
> motherboard had some issues. No problems. I copied the whole thing to a
> new home directory (of the same user, same UID, same path) on a
> different system. However digikam fails to use the database. It insists
> I have the incorrect UUID. Natually it does not allow me to fix things.

> This is intended to protect against using the wrong DoK (but will
> "protect" you from copying the database to a different DoK). And
> couldn't have been disabled from the user interface at the time.

> It took me a few hours of digging in the code and file format to figure
> out how to fake a non-UUID database.

This is not relevant. The digikam software misusing UUIDs and not
accounting for your use case has nothing to do with using UUIDs to
mount disks through fstab.


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/6d4219cc1003172137q769751dav520e01e0bbaed4b7(a)mail.gmail.com
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: pen drive without format and can not find it
Next: Incredibly useful Firefox addon: Hyperwords