bookworm killed digikam import

[Maik Qualmann]

The problem is clear, the partition UUID has changed, so digiKam can no longer 
find your collection. The solution is simple.
Go to the digiKam setup under Collections. Use the "Update" tool button (round 
circle icons). Choose the correct base path of your collection or accept the 
default if it is correct. The new partitions UUID will be automatically 
updated in the DB and your collection will be available again.

For digiKam-8.1.0 I added an information dialog in the import tool in case the 
collection is not available for digiKam.

Maik

Am Dienstag, 27. Juni 2023, 20:48:34 CEST schrieb gene heskett:
> On 6/27/23 12:45, Maik Qualmann wrote:
> > The problem here is that no correct temporary file is created, only one
> > directory remains. Does the target directory/album "/Saw4Bruce/" even
> > exist? Have you possibly set a fixed download album that no longer
> > exists?
> > 
> > Maik
> > 
> > Am Dienstag, 27. Juni 2023, 17:22:12 CEST schrieb gene heskett:
> >> Digikam::FreeSpaceWidget::kBAvail: Did not identify a valid mount point
> >> for ""
> >> Digikam::CameraController::executeCommand: Downloading:  "IMG_0275.JPG"
> >> using  "/Saw4Bruce/"
> >> Digikam::GPCamera::downloadItem: Failed to open file "/Saw4Bruce/" "Is a
> >> directory"
> >> Digikam::CameraController::sendLogMsg: Log ( "IMG_0275.JPG"
> >> "/store_00010001/DCIM/140___06/" :  "Failed to download ‘IMG_0275.JPG’"
> >> Digikam::CameraController::executeCommand: Downloading:  "IMG_0276.JPG"
> >> using  "/Saw4Bruce/"
> >> Digikam::GPCamera::downloadItem: Failed to open file "/Saw4Bruce/" "Is a
> >> directory"
> 
> I've just discovered something. df just showed me that / is not on the
> disk I installed bookworm on, the / directory is on /dev/sdb! blkid has
> bit me in the ass again! So I going to name the #%^ drives and
> partitions so there is no damned confusion, but can I do that w/o yet
> another install. Probably not. This might also explain why I had so much
> instability with bullseye. Longest uptime I ever got with bullseye was
> about 10 days.
> 
> I don't understand this in any way shape or form, I installed to the
> drive plugged into sata 0, all other drives were unplugged, so how the
> hell did I wind up booted to /dev/sdb* when the /etc/fstab is now loaded
> with bad blkid's when the drive plugged into sata_0 is the only drive
> plugged into any sata connector during the install. And I let the DI
> partition and format the only drive that had a cable plugged in.
> debian is going to hear about this too.
> 
> The only place where this could have occured that makes any sense at all
> is the bios choice of which drive to see if it could boot.  So a reboot
> might be next after I check the boot flag on /dev/sda:
> root at coyote:~# fdisk /dev/sda
> 
> Welcome to fdisk (util-linux 2.38.1).
> Changes will remain in memory only, until you decide to write them.
> Be careful before using the write command.
> 
> 
> Command (m for help): p
> Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
> Disk model: Samsung SSD 870
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x32c1fa03
> 
> Device     Boot      Start        End    Sectors   Size Id Type
> /dev/sda1  *          2048    4098047    4096000     2G 83 Linux
> /dev/sda2          4098048  135170047  131072000  62.5G 83 Linux
> /dev/sda3        135170048 1543925759 1408755712 671.7G 83 Linux
> /dev/sda4       1543925760 1953523711  409597952 195.3G 83 Linux
> 
> Command (m for help): q
> So theoretically it should boot from /dev/sda
> I just installed gparted so I can nuke the boot flag on /dev/sdb and
> did. Now I'm going to reboot and pray with a stop to see what the bios
> can tell me.
> 
> 
> Cheers, Gene Heskett.