<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><font face="Helvetica, Arial, sans-serif">Thank you Gilles for
this very quick and interesting answer (the kind I expected!) :
from now, I need a few time to read more about secure boot and
its signature's management...especially considering those info :<br>
- DK 8.8 (rpm version from Fedora repo) didn't open either the
database before succeeding after windows boot<br>
- Firefox and Thunderbird encounted the same issue with their
profile access (which has been solved in the same way)<br>
- rights management through shared NTFS partition could be
tricky<br>
- ...<br>
<br>
And I need to read more about SELinux/AppArmor too....!!!<br>
<br>
NB : from a practical point of view, disabling Secure Boot on a
pure Linux is ok, but on a dual boot W11/Linux, it's a mess to
have to go through BIOS settings at each OS switching (but it's
not the point here, assuming the issue is permanently solved...)<br>
<br>
Many thanks again,<br>
<br>
Best Regards<br>
Olivier</font></p>
<div class="moz-cite-prefix">Le 16/12/2025 à 05:22, Gilles Caulier a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAHFG6sEwxEcEWa712-Y640jJkWasdZMJ6JnPe20GBjYgTwWFQQ@mail.gmail.com">
<pre wrap="" class="moz-quote-pre">Hi,
Here’s my explanation of the issue and possible solutions:
1. Likely Cause of the Issue
Secure Boot: The BIOS update likely enabled or altered Secure Boot
settings (even with CSM disabled). Secure Boot checks the signatures
of executables at startup. As the digiKam AppImage is unsigned, Linux
may block access to certain files, such as the SQLite database.
File Permissions: After a BIOS/UEFI update, file
permissions—especially for shared NTFS partitions—can be
misinterpreted or changed by Linux, especially if the system reboots
with different security settings.
AppImage and Secure Boot: AppImages are not always compatible with
Secure Boot, as they lack recognized signatures by the UEFI firmware.
2. Why Does It Work from Windows?
Windows does not enforce the same signature checks as Secure Boot on Linux.
Launching digiKam from Windows likely reset file permissions or
repaired the SQLite database (e.g., recreating lock files or fixing
metadata).
3. Solutions for a Pure Linux Setup
A. Disable Secure Boot (I do it on all my Linux computers)
Reboot and enter your UEFI menu (usually by pressing F2, F12, DEL, or ESC).
Locate the Secure Boot option and disable it.
Save changes and reboot.
Test launching digiKam from Linux.
B. Check and Fix Database Permissions
C. Check SELinux/AppArmor
If SELinux is enabled, it might block database access. Check logs with:
sudo dmesg | grep -i digikam
sudo journalctl -xe
Temporarily set SELinux to permissive mode for testing:
sudo setenforce 0
(Remember to re-enable it later with sudo setenforce 1.)
D. Repair the SQLite Database
If the database is corrupted, try to restore it from a backup
Voilà for a first approach to solve your problem...
Best regards
Gilles Caulier
Le mar. 16 déc. 2025 à 00:14, olivier mimet <a class="moz-txt-link-rfc2396E" href="mailto:omimet@free.fr"><omimet@free.fr></a> a écrit :
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">
I just made a BIOS upgrade today, and at first boot, OS started as usual (Fedora 43) but DK (appimage v8.9.0) advise me I've no more rights to access the DK database (SqLite).
I get easily a recovery by launching DK 8.8 from a windows partition (thanks to my dual boot, with shared NTFS data partition), which start properly (without any message...) at first attemp, restoring thus access to the DK database back in Linux ....
NB : Unlike legacy BIOS, I'm not so familiar with UEFI BIOS upgrade/boot (it's my first UEFI config., but I suspect Secure Boot to be involved in this behaviour (CSM is deactivated)....
My question is : can somebody explain what happens, and how to solve it within a pure linux config. (I suppose that a dual boot is not mandatory to upgrade BIOS without preventing DK to start on a pure Linux config.! )?
Thank you very much.
BR
Olivier
</pre>
</blockquote>
</blockquote>
</body>
</html>