Time to flash is now - but how?

Very likely. Because I have not used that package, I don’t know what the directory and script locations are. I think Step 5 will be slightly incorrect too (wrong script location).

PS You have a formatting glitch in the command in Step 1.


OK, maybe, in the absence of better documentation, I’ll just revert my post to the original steps, and mention the new method (awaiting clarification) at the bottom. Thoughts?

EDIT: In the meantime, I found it by searching the File System:


Have two procedures. One for “package available” and one for “package not available”. And don’t attempt to document the new procedure until you have a chance to run through the new procedure yourself. So the doco would necessarily be incomplete for now.

My guess is that if the package is available then the script will be in your path.


Revised the text. See what you think.

1 Like


Now we just need someone to run through it for testing.

1 Like

“Someone” who only recently flashed to byzantium, maybe…? :wink:


Nah, m8, my internet’s too **** - so that the procedure won’t actually work. I have to run the script “twice” - once to download the disk image and once to flash the disk image (where that first “once” might end up being “lots”).

The script offers options to separate out the downloading from the flashing.

I’m assuming that @Sharon has first-world internet and so won’t be concerned with that problem.

Also, I wanted to separate those steps anyway because after downloading and before flashing, I want to change the disk encryption master key (new random) and strengthen the slot encryption parameters. However that is only relevant if someone chooses the LUKS variant.

I wasn’t raising any of this, so as to keep the instructions at least somewhat concise and simple.


And actually David Hamner already demonstrated the commands working correctly in his video. I simply copied them from his blog post. (And added the bit you previously mentioned about designating the variant.)

1 Like

I guess it matters what a “s…l…o…w…” is.

of the two desktops, the one I will use to flash with, can get 300 - 350 Mbps.
Is that slow at my end too slow, medium. I still have a 300 “baud” modem tho :slight_smile:
I went out to get a Fem USB A to male USB C. I got groceries, wine and some wine and forgot the reason I went out. Darn! I can get other things ready till my ride comes again. Lots of reading to do here till then.

Thanks for the help

1 Like

What would your vote be between “LUKS” or whatever the other is?

That is not slow. Not even close. You are good to go with that !

LUKS means “encrypted” and the other variant is “plain” which means “not encrypted”.

My personal choice would 100% be encrypted (LUKS).

If you keep personal or private information on your phone (such as the contents of your text message exchanges, emails, … and your contacts … and, for poorly implemented applications, potentially also login credentials) and if the phone is lost or stolen then

  • With LUKS, your information is safe. Sure, you still lost the phone but the financial cost of losing information could be higher than the cost of the phone and then there’s the non-financial cost of losing information.
  • With the unencrypted variant, your information is potentially stolen too. (This might be acceptable if the above covers your threat model and you keep absolutely no information actually on the phone e.g. everything is cloud-based or e.g. you just don’t use it to hold or access private information.)

Edit: Adding: If you store private information on the µSD card then in order to protect all your information then you need both the root file system and the file system on the µSD card to use LUKS. The choice that you make during flashing only covers the root file system.

The downside of encrypted is that if you forget the passphrase for the encryption then you have irrevocably lost access to the information - and you would most likely want to choose a passphrase that is at least a little challenging (although that depends on your threat model).

For the threat model that most people face, choosing a medium complexity passphrase (something that you can easily remember and type, but not something trivial) and just writing the passphrase down and storing it somewhere at home is adequate to mitigate this risk.

If your threat model includes nation state adversaries, including your own government, then it’s a no-brainer that you would use LUKS.

I hope that helps with your decision.

By the way, it is quite difficult (let’s say impossible) to change your decision after the fact - other than reflashing and starting again from scratch. So it is important that you decide up front which variant to use. (I would even go as far as saying: just choose LUKS and use a trivial passphrase e.g. 1234 or space if you actually don’t want the hassle of a passphrase. You can always quickly and easily strengthen the passphrase later on.)


But any sensitive data that is stored on the µSD card is not encrypted, right?


By the way last time I flashed with the script it would be interrupted by too many server time outs. I think it was 10 at which point it stopped the download. I revised the flashing script to 4000 time outs and it successfully completed. Not sure what was going on, I did have a TOR proxy set so I removed that and will have to see if I still have that issue.


That’s entirely up to you !

It is true that the encryption status of the file system(s) on the µSD card is independent of the encryption status of the root file system. (So to that extent, you make a good point and my post did not make that point clear. My claim could come across as overly broad. I will update my post.)

So even if you choose the plain variant disk image, you still have all the LUKS functionality available, so you can still choose to encrypt the µSD card using LUKS. (In general, I think this is not a good choice. If encrypting the µSD card is warranted then the root file system should also be encrypted.)

Of course you may also have other encryption options available for the µSD card i.e. over and above LUKS. (The point is that the root file system must be encrypted using technology, the support for which exists in the boot file system. Any other file system has a wider set of encryption choices, based on what is supported by the system as a whole.)

And for any individual file, you may have other encryption options that go beyond file system encryption e.g. LibreOffice documents can be encrypted in isolation using a password or e.g. a Gnome keyring can always be (is always?) encrypted even when LUKS is not in use or e.g. Thunderbird (poorly) encrypts your stored email account passwords if you choose to use a master password even when LUKS is not in use (by contrast Geary stores those passwords in a Gnome keyring).


I had the same problem. The problem is exacerbated by having a s..l..o..w.. internet connection. See discussion prior to the following linked post for the workaround I used and, differently, that I proposed.

See Repo.puri.sm & arm01.puri.sm slow - #6 by guido.gunther that may document the correct workaround. As I have not tested that option to see whether it is more reliable (haven’t had to reflash again) I don’t know whether @amarok should include that?

1 Like

So, for instance:

If your connection is very slow or unstable you encounter issues while downloading, use:

sudo ./scripts/librem5-flash-image --variant luks --stable



Yes, but I believe

a) the instability is at Purism’s end (although instability at the customer end won’t help!), and
b) the flag actually influences what disk image you download i.e. latest stable build v. latest dev build.

To be honest, I’m not sure why --stable isn’t the default !

I would like to suggest that your instructions should unconditionally include that flag. My only hesitation is that I have not myself used that flag.

I don’t know whether Purism might, you know, have fixed the problem with internet connection stability at their end between the time that three different customers noted the problem and now. So we might be talking about a download problem that isn’t even a problem any more.

For the record, here’s what the source says about that flag

Whether to grab the latest stable image, otherwise the dev snapshot is fetched

Instructions for newbs might better suggest grabbing the latest stable image. Right?


OK, well, now I don’t know what’s best. Lol!
Maybe just leave it as is, unless someone posts an issue; then someone can advise them.


You can use either or. If Jenkins is down, use stable.

If the docu is done, I’m about ready. I can only assume using process of elimination that I might have a evergreen and would be doing easy coreboot because I don’t have a Librem Key, using updated PureOS desktop with all flash files as listed by docu on the Desktop.
Either way, I’ll let ya’all know how it goes.