Dang - more extra work than I hoped. I guess the script in the Ubuntu(?) repo is outdated.
I wonder if compiling it myself would be easier (ok, probably not)… we really shouldn’t need a specific distro to do this. 
2 Likes
There may be a workaround:
- Download the
librem5r4 plain byzantium image:
https://storage.puri.sm/librem5/images/byzantium/latest/librem5r4/plain/artifact/librem5r4.img.xz
- Download
uboot Build 85:
https://arm01.puri.sm/job/u-boot_builds/job/uboot_librem5_build/lastSuccessfulBuild/artifact/output/uboot-librem5/u-boot-librem5.imx
- Place them in the
$HOMEdirectory, then extractlibrem5r4.img.xz. - Run this command:
librem5-flash-image --stable --skip-download --dir ~/
3 Likes
Thanks! There we go, that’s exactly what I was hoping to do but I couldn’t find the dang image to download. Ended up looking at a Jenkins server, a lot of recent broken builds, couldn’t find something that looked like stable and gave up!
Will I be able to find sha256 checksums to verify the downloads? (Since that’s what brought me here really!)
2 Likes
Yes, the librem5r4 plain byzantium image checksum is provided within meta.yml:
gitrev: afaabdbe43650b83744922353f86027cd555c474
image:
size: 4500000256
sha256sum: 6cfc1c2671a76baf3fc72ca611856143e3b74c969239ac8a695ce881a1467672
For uboot Build 85, the checksum is provided within u-boot-librem5-git.txt:
https://source.puri.sm/Librem5/uboot-imx.git
0c1162a11d5f9736edde7a30cf0085f3e0277b47
2 Likes
Yeah. Something appears wack here - it still doesn’t match the new download either (the .xz file OR the extracted .img which was failing earlier). Original error seems to be legit.
The timestamps of the file and checksum yml are are slightly different too. I think we need someone from Purism to look at this and find out what’s going on.
1 Like
Okay, in the meantime, you can try using the actual latest image from April 2024:
https://storage.puri.sm/librem5/images/byzantium/2024.04/librem5r4/plain/artifact/librem5r4.img.xz
Contents of meta.yml:
gitrev: b44f37c67f402a59f721c56d904712650a535c5a
image:
size: 4500000256
sha256sum: 2d73bc8a2a8e01e425cfc773764d8d9dd96c91ad14d9f847d3df3f7642fe3965
3 Likes
Thanks that looks much better. I’m going to start a related thread in another forum for some commentary since otherwise it’ll veer way off topic.
3 Likes
I’ve updated the official instructions. They are now improved.
4 Likes
It should work either way but it has been broken in the recent past either way (for different reasons) i.e. no guarantee that it will work either way. I’m assuming that the plain stable hash will be fixed sooner rather than later.
I decided that “stable” should be more “true to name” i.e. more likely to be stable and working. So I left it there.
(Technically speaking, I wasn’t the one who added that. It was added by A N Other between my first batch of changes and my second batch of changes.)
Unfortunate. But the reality is that you do need another computer in order to carry out this procedure and most people will be doing it on a desktop / laptop with a full size screen. You can’t carry out this procedure on the phone that you will be reflashing.
2 Likes
Okay, well here are alternative instructions for installing the udev rules:
- Open GNU Nano, then copy and save the udev rules:
sudo nano /etc/udev/rules.d/70-librem5-flash-image.rules
SUBSYSTEM!="usb", GOTO="librem5_devkit_rules_end"
# Devkit USB flash
ATTR{idVendor}=="1fc9", ATTR{idProduct}=="012b", GROUP+="plugdev", TAG+="uaccess"
ATTR{idVendor}=="0525", ATTR{idProduct}=="a4a5", GROUP+="plugdev", TAG+="uaccess"
ATTR{idVendor}=="0525", ATTR{idProduct}=="b4a4", GROUP+="plugdev", TAG+="uaccess"
ATTR{idVendor}=="316d", ATTR{idProduct}=="4c05", GROUP+="plugdev", TAG+="uaccess"
LABEL="librem5_devkit_rules_end"
- Reload the udev rules:
sudo udevadm control --reload-rules
2 Likes
I believe you don’t even need the udev rules if you prefix the use of the script when doing the actual reflash with sudo which is what I did.
2 Likes
Are you aware of any updated tutorials for making sure your firmware is all updated?
1 Like
You are already aware of it:
I am certain there are more unlisted firmware, but instructions for updating them to their latest versions on the Librem 5 are not available.
2 Likes
Thank you. I could not build all of the dependencies from your previous helpful post. Therefore the “instructions” are incomplete or possibly inaccurate, from my perspective.
1 Like
Create a separate topic and I will address your issue.
1 Like
I am not aware of one. Unless you are actually experiencing a problem, it may not be a good idea to change firmware, particularly if you won’t be able to go backwards. In other words, your starting point would be to download the version that you currently have.
dos gave you two more.
I would be inclined to drop uboot off that list. Running the reflashing script should automatically get you the latest uboot and no further action is required.
The firmware jail is more complex if you have an original phone i.e. there is no firmware jail, and that isn’t the way to mess with the Redpine firmware. By contrast, if you have a phone that came with or was upgraded to a SparkLAN card then you have a firmware jail and that is the way to update the SparkLAN firmware. If you have an original phone then with care you may be able to create the firmware jail and make the necessary changes so that it is used with Redpine (but I haven’t bothered).
The BM818 firmware is only on that list theoretically, since Purism has not made any information public as to how you get an updated firmware file and how you get it into the modem.
So here would be my updated list:
- Smartcard Reader
- USB PD controller
- SparkLAN card (/ alternatively maybe the Redpine card if certain conditions are met)
- Touchscreen controller
- GNSS module
I have only tackled the first two on my phone.
1 Like
This was one of my very first posts on the Purism community forums, and has lost its ability to edit a long time ago. Maybe the post edit window could be extended to a more generous duration or changed to indefinite.
The instructions have been unofficially disseminated since:
Not by me it can’t. I don’t have that level of administrative access. I would recommend just making an updated post in that topic.
1 Like
None of this worked for me!
Looking for librem5r4 luks byzantium image
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/jenkins/__init__.py", line 462, in get_job_info
response = self.jenkins_open(requests.Request(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/jenkins/__init__.py", line 564, in jenkins_open
return self.jenkins_request(req, add_crumb, resolve_auth).text
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/jenkins/__init__.py", line 580, in jenkins_request
self.maybe_add_crumb(req)
File "/usr/lib/python3/dist-packages/jenkins/__init__.py", line 369, in maybe_add_crumb
response = self.jenkins_open(requests.Request(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/jenkins/__init__.py", line 564, in jenkins_open
return self.jenkins_request(req, add_crumb, resolve_auth).text
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/jenkins/__init__.py", line 583, in jenkins_request
self._request(req))
^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/jenkins/__init__.py", line 557, in _request
return self._session.send(r, **_settings)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 703, in send
r = adapter.send(request, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/requests/adapters.py", line 483, in send
timeout = TimeoutSauce(connect=timeout, read=timeout)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/urllib3/util/timeout.py", line 119, in __init__
self._connect = self._validate_timeout(connect, "connect")
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/urllib3/util/timeout.py", line 156, in _validate_timeout
raise ValueError(
ValueError: Timeout value connect was <object object at 0x7c18af9444d0>, but it must be an int, float or None.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/user/librem5-flash-image/./scripts/librem5-flash-image", line 538, in <module>
sys.exit(main())
^^^^^^
File "/home/user/librem5-flash-image/./scripts/librem5-flash-image", line 464, in main
image_ref = find_image(args.image_job, board, args.variant, args.dist, args.stable)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/user/librem5-flash-image/./scripts/librem5-flash-image", line 275, in find_image
return find_image_jenkins(jobname, board, variant, dist)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/user/librem5-flash-image/./scripts/librem5-flash-image", line 224, in find_image_jenkins
info = server.get_job_info(jobname)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/jenkins/__init__.py", line 475, in get_job_info
raise JenkinsException(
jenkins.JenkinsException: Could not parse JSON info for job[Images/Image Build]
–
If I use --stable it’s the same only preceded by:
Found disk image Build “stable” ‘Last stable librem5r4 build’ from Fri Jun 23 22:21:4
0 2023
before the output listed above. Even --skip-download and pointing to the home directory for manually installing the librem5r4.img alongside u-boot-librem5.imx and STILL yields the same results.
To note I am using Ubuntu but have also tried the suggested PureOS live USB option after much unrelated trouble getting balena-etcher to work only to find out there are no Wi-Fi drivers (not referenced in the suggested instructions) so that option is out the window (if it even makes a difference) unless I can figure out how to download/install drivers.
1 Like