I recently got my Librem 5 phone back from Purism after a repair. Of course my phone OS was reinstalled and when I got it back I changed the encryption keys and then restored my data backup, which was pretty much my entire home directory. Prior to reinstalling the OS and restoring my backup I did not have this problem.
I use Nextcloud for things like my Contacts and my Calendar. Gnome, and thus PureOS, uses the Gnome keyring to store my credentials to my Nextcloud account in the ‘Login’ keyring, which I get prompted to unlock when I log into my phone for the first time after a reboot. Doing this automatically unlocks a second keyring called ‘Default keyring’ because that password is stored in the ‘Login’ keyring.
After I restored my data backup to my home directory, I had to set the ‘Login’ keyring as the default keyring instead of the one labeled ‘Default keyring’.
Here’s my problem:
When I log into my phone for the first time after a reboot, often my ‘Login’ keyring (where my Gnome Online Accounts credentials are stored) isn’t unlocked in time and thus my Contacts are not loaded. To further complicate things, my SMS messaging and Calls apps don’t show names, only numbers. I have to keep rebooting and hope things load in the correct order. Even so, I usually have to kill the ‘chatty --daemon’ process to get it to sync with my Contacts when it decides to work.
Also, when I log into my phone for the first time after a reboot, sometimes I get prompted to unlock the ‘Default keyring’ instead of ‘Login’ keyring.
What I think I need:
I think this is a race condition and I need a way to have this sequence:
Unlock ‘Login’ keyring → Load Gnome Online Accounts → Load Contacts → Start services like ‘chatty --daemon’
Is there a way to halt the chatty service until Contacts loads, halt Contacts until Gnome Online Accounts loads, and halt Gnome Online Accounts until the Gnome Keyrings get unlocked?
Maybe things don’t work well when there are two keyrings, even if you try to set which one should be used, there may still be confusion about which one is used for what.
How about, instead of having two keyrings, you try to remove one of them so that there is only one keyring? Perhaps you can export things from the one you are about to delete, and then import the contents into the other keyring. Just a thought, not sure if that would work.
Yeah, I could try that but it seemed to work in the past. Not sure why, but it was the default setup whenever I set it up for the first time.
TL;DR: after my phone wakes from suspend the /home/purism directory goes read-only and then the trouble starts
The long version:
It turns out there are a couple more variables that I didn’t consider. I think this behavior might ultimately be happening because I have my /home/purism partition on an encrypted SD card with suspend enabled.
My /home/purism directory is an encrypted partition on an SD card and I have suspend enabled. It seems like my phone sets this partition to read-only when waking from suspend on a received text message or phone call.
I can “fix” it by rebooting 3 times with the following procedure:
verify the /home/purism directory is read-only:
mount | grep home
output: /dev/mapper/sdhome on /home/purism type ext4 (ro,relatime)
reboot the phone
log on to the phone after reboot to get the /home/purism directory read-write again
ignore/dismiss the prompt to unlock the ‘Default keyring’ (note, the ‘login’ keyring does not prompt for unlock)
reboot the phone
log on to the phone after reboot and this time unlock the ‘login’ keyring as prompted
verify the Nextcloud account is available in the Settings → Online Accounts
launch Contacts and set Nextcloud as the primary address book in Preferences
reboot the phone because I can’t figure out how to restart the ‘chatty --daemon’ process as persistent and in the background
log on to the phone after reboot and unlock the ‘login’ keyring as prompted
should be normal now, verify Contacts and Chatty both show contact names instead of phone numbers
For the record, this is my entry in /etc/fstab for /home/purism: