Quick and Easy User Personas


I have simplified this process using a different approach and have written a simple yad shell script to automate it. You can check that out in my new forum thread here:


I have found a bug in this process, namely that without the sdcard the desktop environment doesn’t start up as I had thought. This is due to systemd being too clever with how it handles automatic dependency creation when it parses /etc/fstab, so that it disables the desktop environment if the micro SD card is missing. I’m researching alternatives and will update this post when I find an appropriate one.

Please do not follow these instructions yet until I discover how to resolve this issue so it can handle the case of a missing microsd card without disabling the desktop environment!

I will remove this warning once I discover the resolution to this issue.

Post-WARNING instructions once I resolve the issue

The subject of traveling with the Librem 5 came up again recently in this thread which led to my discussing the ideas of using replaceable “user personas” on the phone. I discuss the idea in more detail in this article, but to summarize, user personas allow you to compartmentalize your identities. You can have your regular “default persona” with personal files, contacts, accounts, and settings, and set up a new “travel persona” that has only the files, contacts, accounts settings you need to travel.

In my opinion it’s safest to travel such that you can always comply with border officials without losing sensitive data. You aren’t as good a liar as customs/border officials are at detecting lies. Attempting to smuggle things past them, using spycraft like duress codes that erase data, or preventing them from inspecting your computers could lead to more trouble, detention, confiscating your devices, and depending on the border, criminal penalties or deportation. With a travel persona, you can comply with searches safely without losing sensitive data. You can then restore your default persona either inside the border or once you get back home, depending on your threats and capabilities.

There are a few different ways one could implement user personas but they all revolve around the fact that likely all of your sensitive files and settings live inside your home directory (/home/purism on the Librem 5). So to swap personas you could backup your current home directory, erase it, reboot, and you’d have a new blank account. You could then set that account up the way you want, back it up, and then erase and restore the home directory to whichever persona you want to use at the time.

I even thought about working on a simple GUI tool to help automate the backup and restore process, but after thinking about it, I’m starting to think the simplest approach for most people might be one where their home directory lives on a fast microSD card. That way, everything that constitutes a unique identity on the Librem 5 is removable:

  • MicroSD card
  • OpenPGP smart card (so you can store GPG secrets tied to a particular persona securely)
  • Cellular Modem (IMEI)
  • SIM card (IMSI)
  • WiFi card (WiFi MAC)

Given you can potentially fit a lot more data on microSD cards than onboard storage anyway, I had already started using a large, fast microSD cards for media and other large files, so it makes sense to just move the whole home directory over there.

I just tested this approach and it seemed to work for me. Here’s what I did:

NOTE: My microSD card is formatted as ext4 and mounted at /mnt/sda1, if you want to do something similar but mount your microSD elsewhere, you should adapt my steps to wherever you are mounting your microSD card.

Also, before you try these steps, please backup your important files to some other media than the microSD card you will be using for this exercise, just in case! We document two different approaches here and here.

Sync Files Over

sudo apt install rsync
sudo rsync -avxh /home /mnt/sda1/

Because I have a lot of files, the first time this ran I didn’t bother with shutting down applications or anything as it was going to take awhile. Then once it completed, I shut down any open applications and refreshed any files that may have changed:

sudo rsync -avxh --delete /home/ /mnt/sda1/home/

Set up fstab

We need to tell the /etc/fstab file that it should bind mount the home directory from the microSD card over the top of the existing home directory. Edit /etc/fstab and add the following line (modify to account for where you mount your microSD card):

/mnt/sda1/home/purism /home/purism none auto,bind,nofail

Including the entry I added to mount my microSD itself, the changes from the factory default would look like:

/dev/sda1 /mnt/sda1 auto auto,nofail 0 2
/mnt/sda1/home/purism /home/purism none auto,bind,nofail

It is CRITICAL that you add the nofail option to any microSD card-related entries in /etc/fstab, that way if you boot without the microSD card it will fail to mount but still continue the boot process. Without the nofail option, the boot will stall and you will have to modify the file system from a remote computer to remove the mount point from /etc/fstab.

Move the old home directory out of the way

Now I’m ready to reboot into my new home directory, but since it is going to be mounted on top of whatever is in /home/purism, I want to move the old directory out of the way, and touch a file in the new directory so I can tell them apart:

sudo mv /home/purism /home/purism.bak
sudo mkdir /home/purism
sudo chown purism:purism /home/purism
touch /mnt/sda1/home/purism/new

Reboot and test

Now you can reboot the phone and when it comes up, you should have all of your settings as they were before, and if you look, you should see an empty file named “new” in your home directory. Once you feel comfortable with this setup, you can remove the old /home/purism.bak directory.

Congratulations, you now have your default user persona!

Creating additional user personas

To create an additional persona, format a new microSD card with ext4 on a separate computer and add an empty home/purism directory structure on it owned by the purism user:

mkdir -p /mnt/sda1/home/purism
chown 1000:1000 /mnt/sda1/home/purism

Then insert the microSD card into the Librem 5 when it’s powered off and then boot it, and you should be back to a default, fresh user with no settings. Just set up contacts, accounts and files you want to have for this persona and when you are done, you can power off the Librem 5 and replace it with the microSD card containing your default persona, and store the new persona somewhere safe until you need to use it.

Then to use the new persona, you power off the Librem 5 and swap the microSD cards.

What if my microSD card fails?

No storage lasts forever, and you should backup important files from your home directory on your phone to somewhere safe just like you should on a laptop. Since you are now using the microSD card as a home directory, it doesn’t make sense to store backups there as well, so you will want to copy backups over to a separate computer, a network mount point, a USB thumb drive, or some other option.

If your microSD card does fail, the file system gets corrupted, or there is some other problem, when you boot the system it will start with that empty /home/purism directory that’s underneath the bind mount, and you will be presented with a fresh “like factory” install and will need to recreate any settings.

Or if you took backups, just format the new microSD card with ext4, and restore the home directory on it and replace the failed microSD card.


Of course this would be a lot safer if the file system on the microSD card were encrypted. Once we complete support for unlocking LUKS partitions at boot, we would then extend the same approach to unlocking an encrypted microSD card.


:slight_smile: for those who are in for a WILD ride … you could also set up a temporary/permanent deportation persona at /home/deported and simply restore once the WILD ride ends … if EVER :sweat_smile:

great input btw Kyle ! as always ! :innocent: :smiling_face_with_three_hearts:

can this be a target for fund-your-app ? custom specification in the text field at the bottom of the page ?

i see that the votes are progressing at a turtle’s pace …

It’s already something we are actively working on and are hoping to release when we migrate the default phone image from PureOS Amber to PureOS Byzantium.


Love the idea/concept as well as the writeup, thanks for touching on the upcoming encryption work!

1 Like

i encrypted the sdcard via luksformat and

UUID=<uid> /sdcard ext4 defaults,x-systemd.automount,noauto 0 2

in /etc/fstab and

crypt_sdcard UUID=<blkuid> /etc/crypttab.sda.keyfile luks,discard,noearly,tries=1

in /etc/crypttab - this certainly needs to become simpler.


Wouldn’t ‘<uid>’ and ‘<blkuid>’ be specific to an individual sdcard in your example? I think the intent of this post is to be able to swap different sdcards (presumably with different uid’s) to be able to easily change personas.

I wonder if you can have multiple entries in fstab and crypttab that are identical except for different uid’s and luks key file for different persona sdcards. However, I can see how that might cause problems and might not be valid if they have identical mount points.

Also, as @Kyle_Rankin notes, it would be best to store the luks key on the removable smartcard instead of in the /etc filesystem… but I know that’s an issue with not having the ability to unlock it at boot time at the moment.

Note that I have found an issue with this approach, in that the system stops at a text login prompt if /home/purism is completely empty. I’m researching which files need to be copied over there and posted a warning at the top of my instructions. I’ll update things once I figure it out.


I think that is the intention of specifying a device in fstab by UUID rather than by device pathname.

for people looking for easier CLI help and what commands do or mean > https://explainshell.com/

also > https://pathname.com/fhs


Just to update this, the problem is not with an empty /home/purism directory, that behaves as it should and just sets you up with a fresh user. The problem is that systemd is attempting to be too clever with how it handles dependency management as it auto-parses /etc/fstab.

What’s happening is that setting this sdcard home directory to automount, means that when it’s missing, even with nofail set, systemd’s cleverness means that it marks the /home/purism mount point as failed, and since the desktop environment has a dependency on the home directory existing, it also fails.

So far I haven’t found a way to tell systemd to automount a home directory, but also not to trigger downstream dependency failures if that automount fails. While noauto,nofail would disable dependency management, it would also fail to automatically mount the home directory at boot like I need.

Still researching an alternative that isn’t hacky…


The upside is that an actual spy would find failover to the /home/purism directory on the eMMC drive too risky anyway. The last thing you want is leaking persona information, instead of being on the chosen uSD card, to the eMMC drive i.e. if it silently failed over, so the spy was unaware that compartmentalisation had been broken.

If you are going to provide a failover option then creating a small /home/purism in a ramdisk may be an acceptable answer i.e. enough to get the desktop environment up, allowing the spy access to tools that might get to the bottom of why the uSD card didn’t mount. That may be even more “hacky”. :wink:

1 Like

@Kyle_Rankin, could you perhaps craft a systemd .mount unit for this? I haven’t looked into or tried it but it was just a thought I had.

I kind of like the idea of a RAM disk home directory. It could be used as a guest account, or maybe someone who wants all of their communication to be ephemeral and not add wear and tear on any local storage device.

1 Like

Better not run Epiphany then. ~purism/.cache/epiphany tree contains over 400 MB (and ~purism as a whole is pushing up towards 500 MB). There are a couple of large SQLite databases or related files. gsb-threats.db gsb-threats.db-wal ?

I ended up reverting back to the local home directory. I ran into too many odd edge cases where the microSD card home directory may not get mounted properly after a reboot, which left me with a login prompt. I didn’t like the idea of being out somewhere without a keyboard to recover, so I reverted back.

To revert, I commented out the reference in /etc/fstab to the home directory bind mount, rebooted, then copied the files over from the micro SD card home directory to the local one, then rebooted again.

If someone else does want to store their home directory on a microsd card and it fails or they otherwise get in this situation, you can attach a keyboard (in my case I had a BT keyboard already paired ahead of time) and login to the shell prompt and comment out references to the home directory in /etc/fstab and reboot. Alternatively if you have a second microSD card you could put an empty home/purism directory structure there, which the Librem 5 would detect and mount if you had things set up like I do in the above instructions.


zram might help. Database files tend to have a lot of 0’s in them due to preallocation, and compress really well.

1 Like

and turn off the content cache. No point caching content on “disk” that is actually RAM. Better to cache directly in RAM as the browser will anyway - although your comment about zram could make that an interesting comparison depending on the internals of the browser.

I am fine with being dependent on a SD card or 2. It sounds like an .iso could be made (containing a blank /home) and Etcher could initialize a fresh SD card if a Linux computer is not available. I would rather limit the 32GB of eMMC to the OS anyway. For desktop OSs, 32GB is the minimum for /, assuming that /home is another partition.

1 Like

You could carry a range of spares e.g. a recent image of the real persona uSD card and some spares with a suitable initial state (empty persona, but at least the boot works). uSD cards are so small that it wouldn’t be an impost.

You are increasing your risk of failure ever so slightly though, since a successful boot depends on both disks working. Let’s say that a bad update comes through so that the uSD card stops being usable in this way. You and a few spies may be the only ones using this configuration. So the regression may not get picked up before release. No amount of spare uSD cards is going to fix that. Your only option would be to attach the BT keyboard, boot up, use shell to update the software forward (fix available) or backward (revert the bad update), then boot again - or anything equivalent to that.