[Digikam-devel] [Bug 215486] collection not found in location on disk with uuid (lvm volume)

[Orestes Mas]

https://bugs.kde.org/show_bug.cgi?id=215486


Orestes Mas <orestes at tsc.upc.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |orestes at tsc.upc.edu




--- Comment #15 from Orestes Mas <orestes tsc upc edu>  2009-12-25 23:13:47 ---
Please don't close this issue yet. I'm in a similar situation, and I tink this
is a real problem.

I've experienced recently a disk failure. The disk contained my photo
collections, but fortunately I had backup copy of all photos + the digikam
database.

Now I've decided to build a RAID system on my desktop computer, to be even more
protected against another eventual disk failure. So I bought 2 identical disks,
set up a RAID array and created some LVM2 logical partitions over it. Finally,
I restored my backup copy (in fact, a backup of whole /home containing
/home/photos) and triedopened Digikam to check my collection, but digikam
complained with similar message as the one of the fisrst reporter (Simon).

The 2 options offered were to do nothing and to consider the collection being
in a removable storage. But this dialog should also offer the option to fix the
drive's UUID stored in the database, as in my opinion the situation I face is
not uncommon.

I'm also on kubuntu karmic, but I don't thing my HAL is broken, although I'm
not an expert in this field and I can be wrong.

I attach the output of "solid-hardware", and explain a bit my setup, for the
sake of clarity:

I've 2 identical, 1TB drives: /dev/sda and /dev/sdb. The two are formatted
identically:

GPT partition table
  1 small "BIOS" partition (sda1, sdb1) to make room for GRUB2
  1 big partition (sda2, sdb2) to serve as a RAID volume

The created RAID (/dev/md1) is used as a LVM2 physical volume, and this volume
is assigned to a "gv1" volume group. Finally, this volume group is divided into
3 logical partitions: root ("arrel" in my language), home and swap, mounted and
used the obvious way.

The backup copy, previously stored in a LVM2 logical partition with
UUID=5f5cb5e1-091b-4f05-a564-9bd29ab9c664 in the failed drive, now is restored
in the new /home partition, with UUID=16013925-4625-4763-9246-22f1b80a65f2, and
Digikam is complaining about that.

I think I'll be able to fix it editing the database (with some suitable tool)
and change the old UUID with the new one, but obviously the average user won't,
and so thisshould be considered a (data loss) bug.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.