What would be the best file system to use on an SD card inside the Librem 5? I have a 256 GB SD card. I want to encrypt the SD card content. I read this article, but I’m also interested in your recommendations and opinions.
I’m using f2fs ( Flash-Friendly File System) with encryption and compression:
sudo mkfs.f2fs -O encrypt,compression -l<label> /dev/<sdcard> sudo mount -o compress_algorithm=zstd,compress_extension='*' -L<label> /mnt/ fscrypt encrypt /mnt/
The motive for F2FS was to build a file system that, from the start, takes into account the characteristics of NAND flash memory-based storage devices (such as solid-state disks, eMMC, and SD cards)
Depends what you are doing with it.
I’ve put a bunch of publicly-available multimedia content (write once, read many) so no need for encryption and no special requirements. So I went with
I’m mounting it with the
This should be:
sudo mount -o compress_algorithm=zstd,compress_extension='*' -L<label> /mnt/
-o got lost in the copy/paste, thanks for the heads up
I’ve corrected it my post
I have a 256 GB SD card with a single partition which is a LUKS container, the container is formatted as ext4 with no journal.
The LUKS container gets automatically decrypted and mounted at boot. Initially I had it mounted at /home/purism/uSD but I’m currently experimenting with having it auto mount at /home/purism so it’s the source of my entire home directory. Seems to be working fine, although that is just based on how it feels through using it rather than any technical bench marking. The phone is not my daily driver and I suspect the card sees quite light usage.
I suggest you read the existing discussion on this as it works mostly but not 100%: Quick and Easy User Personas
Note comment in that topic (possibly for you but in any case for other readers): Make sure to use the
nofail option - otherwise you can potentially make your phone unbootable unless you then manually intervene.
Thanks for the heads up, I had seen the thread before and, yes, I have the
nofail option defined for the mounts in both cryptab and fstab.
Your comment got me thinking that I should probably revisit this, when I set it up I was, like many, stuck in the house so if the phone refused to boot it was no real problem. Now that I’m moving around a little more often, the idea of being out and about and getting stuck at a getty prompt would be a little more problematic.
The solution for my setup wasn’t as involved as I expected to be.
I left the entry in
/etc/crypttab for the LUKS container on the card as is.
I removed the entry in
/etc/fstab for the decrypted partition and moved the mounting operation to a systemd service unit set to run after the
systemd-cryptsetup service decrypts the container.
Initially, the service unit just made a simple call to mount the decrypted container directly but this seemed to work most of the time but fail every now and again. I’d guess there is some race condition going on here, I ended up setting the service unit to call a small script which will wait, if needs be, for the decrypted container to become available before attempting to mount it.
The phone will now reliably fully boot with no problems regardless if the card is installed or not or even if a different card is installed.
If your SD card is behaving as your home directory, how does it behave when you boot and the SD card isn’t present?
When the SD card is not present the home directory of the root (/) filesystem becomes available.
Oh I see. So I guess in that way you could have different personas? Is there a way to make the root home inaccessible if a home directory exists on the SD card?
The way I have it setup, if the decrypted container is available it is mounted as the home directory, as soon as it’s mounted the the home directory of the root file system becomes inaccessible.
I would think it would be quite trivial to achieve if you wanted to mount the card somewhere to check it’s contents before deciding if it should be mounted as home, subsequently mounting it as home would then make the home directory of the root file system inaccessible.
I’m asking in regards to the “personas” concept, so you could have a “travel” home and a “home” home. It sounds like maybe your setup would achieve that.
Yes it could, an approach to the personas concept is also covered in the Quick and Easy User Personas post linked previously.
Yeah, the one that has the giant warning about needing the SD card present in order to boot. Your solution doesn’t require that.
Yeah, sorry, the article has an update which links to a “part 2” which I thought had overcome that issue. I must admit I didn’t read it too thoroughly as it didn’t interest me that much, part 2 sort of solves the problem in a round about way but is a little vague on the details.
Oh I didn’t know there was a part 2. Yours does sound more elegant though.