Time to flash is now - but how?

Yep. Knock yourself out.

Definition 3 - US -:
used to tell someone to go ahead and do something

“Do you mind if I use this exercise machine first?” “Knock yourself out.”

Also used in this Muppets song: Muppets - Ben Vereen - Jump Shout Knock Yourself Out Theme Song - TelevisionTunes.com

1 Like

New, probably not last errors still

uuu (Universal Update Utility) for nxp imx chips – lib1.2.91

Wait for Known USB Device Appear…
Error: Unknown Command:FB: reboot

2024-03-21 12:58:04,107 INFO Cleaning up.
Traceback (most recent call last):
File “./scripts/librem5-flash-image”, line 538, in
File “./scripts/librem5-flash-image”, line 521, in main
flash_image(uuu_target, args.debug)
File “./scripts/librem5-flash-image”, line 351, in flash_image
subprocess.check_call([‘uuu’, uuu_target])
File “/usr/lib/python3.7/subprocess.py”, line 347, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command ‘[‘uuu’, ‘./tmp_librem5-flash-image_u0hff3br/flash_librem5r4.lst’]’ returned non-zero exit status 255.

I hope I live long enough to see this to the end :face_exhaling:

1 Like

Unfortunately, I don’t know how to troubleshoot the error.

1 Like

Not sure if this is relevant, but installing uuu today myself (as a test) indicates version lib1.4.193.

I’m on Linux Mint 21.3, which is based on Ubuntu 22.04. PureOS and Debian may have different versions… and it might not matter anyway.

I didn’t actually follow through to see if flashing would be successful. I wonder if your loose USB-C port might be the culprit.

1 Like

Really? I think I know. The script says
ERROR: Unknown Command:FB: reboot.

To me it means there is a commend to “reboot” and that command is not recognized by the script. So, IMO, the script needs some very serious intervention.

That “loose” cable is not confirmed. It’s only that at times, moving the phone, the screen has blinked off a few times, and froze before. I swapped out to another cable that hasn’t produce the same so far.
The part of of the Post 16 (Step x Step to flashing) that says

and then Step 5 sub part that says:

is where being a octopus would be handy, but it’s the only time the phone was moved and there was no screen blinking, script didn’t stop until the error. Actually, the script continued right after the error with:

2024-03-21 12:508:04,107 INFO Cleaning up…

Had nothing to do with the error. The error is caused by scrip readings command that wasn’t/isn’t there. So, there appears a need to fix that too. This is really over the top of annoying. But I can get 2048 score!

1 Like

From the UUU Error During Flashing" is only similar error during flashing.
That post suggests using “–stable”

I do not understand any of it, just that it’s related.

If someone knows where --stable goes, and what it does?

Ghosted huh :rage: Great.

1 Like

That’s very well possible.
At the moment this isn’ t a priority.
First you need to succesfully flash the L5. So far this seems to a big hurdle :worried:


If I read that reply correctly you should enter:

./scripts/librem5-flash-image --debug --dir ~/data/librem-images/ --stable

1 Like

In order to get luks, would I add the following
--variant luks
to the end of the command line you provided as in:

./scripts/librem5-flash-image --debug --dir ~/data/librem-images/ --stable and add –variant luks


1 Like

You only need that if you want to have your phone’s data being encrypted.
It’s a personal choice.
Choosing for encryption (=luks) means that you have to enter an aditional code or password when booting the L5.
I do not use it, but some say that it is a security issue.

1 Like

Thanks. Yes, I know what it does. my question is more about do I add it to the end of the command line you provided?

1 Like

I’m not completely shure, but I would place it at the very end of that line.


I have Luks on the phone when I received it and if someone does steal the phone, I hope it breaks their head too. Better than a glitter bomb.

Thanks for confirming where the Luks line goes.I’m going retry again now to flash it. But, it’s a command that fails and haven’t seen anyone look in to it.

1 Like


To Anyone,
QUESTION : What needs doing to fix the flashing script:question:

FB: 0x18d1 0x0d02
Wait for Known USB Device Appear…

:bangbang::arrow_lower_right:Error: Unknown Command:FB: reboot:arrow_lower_left::bangbang:

Traceback (most recent call last):
File “./scripts/librem5-flash-image”, line 538, in
File “./scripts/librem5-flash-image”, line 521, in main
flash_image(uuu_target, args.debug)
File “./scripts/librem5-flash-image”, line 349, in flash_image
subprocess.check_call([‘uuu’, ‘-v’, uuu_target])
File “/usr/lib/python3.7/subprocess.py”, line 347, in check_call
raise CalledProcessError:arrow_left:(retcode, cmd)
subprocess.CalledProcessError::arrow_left: Command ‘[‘uuu’, ‘-v’, ‘/home/pure1/data/librem-images/flash_librem5r4.lst’]’ returned non-zero exit status 255.



You need udev rules to run the script without root permissions.

sudo ./scripts/librem5-flash-image --udev

From the instructions I already provided you via PM over a month ago:

The version of uuu that you are using (version 1.2.91) is quite old and predates the introduction of the FB: reboot command, hence the Unknown Command error.

Support for the FB: reboot command was added in version 1.4.43, so the minimum version of uuu required is 1.4.43.

From the 1.2.91 uuu version number I would guess that the PureOS version running on the desktop is PureOS 9 (Amber)? As the current version of PureOS is 10 (Byzantium) and should have uuu version 1.4.77 available to it.

To workaround this issue there are a number of options which include:

  1. Perform the flashing procedure from within a live image running on the host machine, a live image which can provide a more recent version (1.4.43+) of uuu

  2. From the host machine, locally compile uuu from up to date source code.

  3. Remove or comment out the FB: reboot command from the file containing the uuu command set. The FB: reboot command in this instance merely reboots the phone after the image has been flashed, by removing or commenting out the FB: reboot command from the cammand set it would simply add one additional step to the flashing routine which is that you would manually power cycle the device after the image has been flashed.


Does PureOS provide an easy upgrade method to byzantium?


I guess I should have written “the most recent PureOS version,” but I didn’t expect anyone to still be using amber. (EDIT: My failing, not Sharon’s. :slight_smile: )

1 Like

well i am not sure if they have something like ubuntu where you get a GUI app telling you that you can upgrade to a newer version of ubuntu.

if they don’t have something like ubuntu then that would be terrible from a security point of view as purism advertises there devices to all people and many of them would be stuck with a system that is filled with security vulnerabilities.

if you go to Download PureOS you get these instructions telling you how to upgrade from amber to byzantium

Replace "amber" with "byzantium" in /etc/apt/sources.list
1. You should get the following :

      deb https://repo.pureos.net/pureos byzantium main
      deb https://repo.pureos.net/pureos byzantium-updates main
      deb https://repo.pureos.net/pureos byzantium-security main
2. Upgrade the system

      sudo apt update
      sudo apt upgrade --without-new-pkgs
      sudo apt full-upgrade

3. Reboot to the new system

I don’t understand why the script doesn’t check if the person’s system has uuu and if they have the needed version to flash the librem 5.


The script is written in Python and I don’t think there is a simple way of getting uuu to tell you its version in a script or perhaps even to find out whether the uuu command exists. This is doubly so because the early versions of the script executed under the assumption that the user would typically not have the uuu command at all and that it had to be built from source (which is the way I did it the first time that I used uuu).

The instructions do nowadays however tell you just to install uuu - so uuu not even existing “can’t” happen.

So in some respects the easiest way is just to let it fail - but, yes, it would be nicer if it made an explicit check for the failure of the uuu command rather than let it generate a traceback.

OK, so @Sharon, please execute the following command on the host computer
lsb_release -c
and post the output here.