bookworm killed digikam import

gene heskett gheskett at
Tue Jun 27 19:48:34 BST 2023

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.
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Genes Web page <>

More information about the Digikam-users mailing list