I followed the Quick and Easy User Personas guide, and mount my sd-card to /home/purism.
This is the relevant section of my /etc/fstab
/dev/sda1 /mnt/sda1 auto auto,nofail 0 2
/mnt/sda1/home/purism /home/purism none auto,bind,nofail
Ever since the suspend feature became stable, whenever my phone wakes up from suspend, the sdcard gets mounted as read-only, which causes all sorts of problems.
Any help would be appreciated.
I’m affected by the issue as well and reported it here: https://source.puri.sm/Librem5/linux/-/issues/484
I also noticed this behavior. Sidenote: Don’t try to edit the /etc/fstab to mount it as write & read device on boot as workaround or at least don’t make it a requirement to boot. ^^’
I locked myself out of the device like this because it couldn’t mount my SDcard during boot properly. Maybe I just messed up the UUID by accident but I don’t think I did. At least reflashing the device was pretty much straight forward but it’s not something you want to experience. ^^’
Same problem here.
I used my Librem 5 as daily driver since I got it a few months ago. The “read-only” problem started only a few weeks ago. It happens multiple times a day which means that I usually have to reboot the phone first before being able to use it. Or disable suspend.
My workaround for this: I installed PureOS on a partition on the SD-card in addition to the installation on the eMMC (and added another partition on SD-card as /home). This way I can still boot from SD-card by pressing volume down on boot and repair the installation on the eMMC.
This read-only problem is very annoying. I also try to use my librem5 as a daily driver. As I drove with my car and Pure Maps and OSM Scout Server yesterday, the read-only problem happened as I stopped for 15 minutes. Maybe the plugged power to to the car socket did not get power in this time and a suspend happened. The librem5 display did not change any more while moving the car. After rebooting it worked again. I think this means, if you use the librem5 for navigating you must not enable suspend. (I will try that next time)
I wonder, that there are only so few comments to this topic. Because this topic is so annoying. Are there people, that do not face this read-only problem while using a sd-card and suspend enabled ? If so, which sd-card do you use ?
I use suspend for some weeks now as default. My SDcard remains writable after coming back from suspend:
purism@pureos:~$ mount | grep media
/dev/sda1 on /media/purism/6464-6631 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
purism@pureos:~$ touch /media/purism/6464-6631/ttt
purism@pureos:~$ ls -l /media/purism/6464-6631/ttt
-rw-r--r-- 1 purism purism 0 Jul 24 09:39 /media/purism/6464-6631/ttt
So maybe the problem is only with an encrypted sd-card. (/dev/mapper/crypt_home /home ext4 nofail 0 2) and with ext4 (you are using vfat).
Also if nothing is running I can suspend (most of the time) without problems. So maybe the problem only happens while writing to the sd-card.
Maybe I have to test when this problem occurs, and how I can provoke it.
Also I wonder why this never happens with the internal disk of the librem5. What is the difference ?
I haven’t come across this issue and I also use a LUKS encrypted SD card with ext4 format. I don’t use automatic suspend, but I do suspend it manually when I am going to be away from a power source for awhile.
I can confirm that it happens occasionally with the unencrypted ext4 partition too.
I’m facing with the same problem. A small investigation shows that the problem is quite old. Unfortunately, there is no CONFIG_MMC_UNSAFE_RESUME in the modern kernel. But, in fact, another solution has been found - adding the “expecting_media_change” flag. Moreover, the code was merged, but it disappears in the last kernel version. Why? I tried to revert it back and it looks like everything works! There is only one drawback - you must not remove sdcard during suspend, and this limitation is ok for me.
That’s not the same problem, what used to be UNSAFE_RESUME is the default behavior now.
Because it was not a correct fix and the problem it was attempting to resolve (which was related to runtime PM) has been solved differently.
It’s still a useful thing to note if it does actually workaround the suspend problem. Reading the code, I’m confused how could that happen though - but that may just as well mean that my understanding is incomplete 
In fact some additional investigating is needed… This is my patch and I can not find the exact commit that I used. But I can confirm that now my sdcard works well during suspend/resume cycles. What drawbacks can be expected by this patch?
You are right, it looks like the problem with sdcard exists despite the “fix”. I’ve got sdcard io error after a week of successful usage 
It looks like I’ve found a workaround for this issue.
Some context first: I use ext4 fs over LUKS encrypted partition located on sd-card as soon as I keep my personal files here and I’d like to be protected if I lose the phone.
Solution: LUKS has suspend option when all io operation stopped. So, I’ve created luks-suspend-resume.service with the next content:
[Unit]
Before=sleep.target
StopWhenUnneeded=yes
[Service]
Type=oneshot
RemainAfterExit=yes
# before suspend
ExecStart=/usr/sbin/cryptsetup luksSuspend <storage_name>
# after resume
ExecStop=/usr/sbin/cryptsetup luksResume <storage_name> --key-file=<path/to/your/keyfile>
[Install]
WantedBy=sleep.target
Do not forget to enable the unit. After that I have no issue with my sdcard. Another issues happened some times, but it is another history.