[Digikam-devel] [Bug 175923] digikam uses wrong album root path/wrong disk uuid

[Milan Knizek]

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


Milan Knizek <knizek at volny.cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |knizek at volny.cz




--- Comment #23 from Milan Knizek <knizek volny cz>  2009-10-10 21:00:43 ---
This bug is marked as fixed, but I have experienced the same troubles with
1.0.0beta5 (rev. 1022810).

I have migrated my disk to LVM2, which resulted in changed UUIDs. On startup,
digiKam did not find the existing collection (in the same path as before:
/media/Data/Photo/Images - it is not a removable partition, even that is in
/media directory) and offered to mark it as "on removable drive" or "do
nothing". I chose the latter option.

Then, I manually edited digikam4.db UUID value in RootAlbum for the partition
having the actual images, but no go.

I had a first success with setting UUID of the first partition in the system
(/boot on sda2). digiKam opened fine and showed the albums/thumbnails in the
collection.

However, when I rescanned the collection for new images, the collection
disappeared immediately again (nothing in album list). During scanning, the
popup window showed two steps (Preparing for scanning, Scanning for removed
albums). The settings showed a different path (with /boot prefixed: the path
does not exist), while db still shows the original (and existing) path.

After that, I had no success changing the UUIDs in db.

Finally, I solved that by creating a symlink /boot/media to /media. On startup,
digiKam offered to set the lost collection as the one existing on
/boot/media/Data/Photo/Images.

Note that on each trial, I started with the original db restored from a backup.

$ ls -la /dev/disk/by-uuid/
drwxr-xr-x 2 root root 100 2009-10-10 21:20 .
drwxr-xr-x 6 root root 120 2009-10-10 21:20 ..
lrwxrwxrwx 1 root root  10 2009-10-10 21:20
d2c4afc9-c7e0-4ce0-89a5-d3989e14c5c3 -> ../../sda2
lrwxrwxrwx 1 root root  20 2009-10-10 21:20
6425bcd4-3bc1-4ff1-a167-e0afe92d1a00 -> ../../mapper/vg-swap
lrwxrwxrwx 1 root root  20 2009-10-10 21:20
6954fd86-3273-4361-9583-b46841303c2f -> ../../mapper/vg-root

The collection is on "vg-root" (which is mounted as /).

$ mount (I removed extra lines of tmpfs, etc)
/dev/mapper/vg-root on / type ext4 (rw,relatime)
/dev/sda2 on /boot type ext3 (rw)
/home on /home-bind type none (ro,bind)
/home/modeluser/.Private on /home/modeluser type ecryptfs (blabla...)

So, I can see two problems:
x Bug re. UUID from another partition still exists
x Scanning for existing collections on startup is done only on one partition
(sda2) and not on the other (vg-root).

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