I have no issues on my end although i am using my Librem 5 without a sim card. I was using it for an hour with no issues whatsoever
1 Like
Edit: Fixed package version and URLs according to @dos’s suggestions below.
For the record, here’s how I just successfully downgraded the Byzantium kernel to the version that @dos suggested (6.6.40).
-
Download packages for the older kernel version 6.6.40 from PureOS’s GitLab CI artifact store:
cd "$(mktemp -d)" curl -LO 'https://source.puri.sm/Librem5/linux/-/jobs/437916/artifacts/raw/debian/output/linux-image-6.6.0-1-librem5_6.6.40pureos1~byz1+gitlabci1_arm64.deb' curl -LO 'https://source.puri.sm/Librem5/linux/-/jobs/437916/artifacts/raw/debian/output/linux-image-librem5_6.6.40pureos1~byz1+gitlabci1_arm64.deb' -
Downgrade the kernel to 6.6.40:
sudo dpkg -i \ linux-image-6.6.0-1-librem5_6.6.40pureos1~byz1+gitlabci1_arm64.deb \ linux-image-librem5_6.6.40pureos1~byz1+gitlabci1_arm64.deb -
To keep
apt upgradefrom undoing your downgrade next time you run it, set up a blocklist that tellsaptto ignore the two kernel versions 6.6.66 and 6.6.74 from now on:sudo mkdir -p /etc/apt/preferences.d sudo tee /etc/apt/preferences.d/50_no_known_bad_kernel.pref << 'EOF' Package: linux-image-librem5 linux-image-*-librem5 Pin: version 6.6.66pureos* Pin-Priority: -1 Package: linux-image-librem5 linux-image-*-librem5 Pin: version 6.6.74pureos* Pin-Priority: -1 EOF -
Confirm that the blocklist is configured correctly:
$ sudo apt update && apt list --upgradable […] All packages are up to date. Listing... Done -
Restart the Librem 5.
2 Likes
That’s a package compiled for another distribution version (dawn). I don’t think using it will cause troubles in this particular case, but I won’t guarantee it either and in general you really shouldn’t mix packages from various suites this way.
The link I posted has a version compiled for byzantium.
1 Like
Thanks for the pointer. I wasn’t even aware that the version I used was not packaged from Byzantium. It’s not obvious to me when looking at the list.
Can you help me understand how you determined that the URL I used not for Byzantium, and where I could have found the correct image starting from the link you posted? So I can get it right the next time.
1 Like
The PureOS archive does not retain old versions of packages that aren’t referenced by any suite anymore, so the whole idea of downloading it from there smelled bad from the beginning 
See:
2 Likes
That’s unfortunate. Good to know.
I was expecting PureOS maintainers to retain old versions like other distros do.
Fair enough. I was just trying to be helpful, and tested and found it working before I posted it.
Thanks anyway for making me aware of the mixup.
With that being said, I’m horrified of the thought that there’s no archive whatsoever except for the GitLab instance, which may purge build artifacts anytime. I’m slowly losing the little trust there’s left in PureOS. The only thing that keeps me from switching to Mobian is the fact that my phone is way too degraded to make the switch.
Edit: Fixed the instructions so they now use the version from the GitLab CI artifact store.
1 Like
I’ve downloaded it, gave it this name and it brings:
$ unzip 6.6.40pureos1.zip
Archive: 6.6.40pureos1.zip
creating: debian/output/
extracting: debian/output/linux-headers-6.6.0-1-librem5_6.6.40pureos1~byz1+gitlabci1_arm64.deb
extracting: debian/output/linux-image-6.6.0-1-librem5-dbg_6.6.40pureos1~byz1+gitlabci1_arm64.deb
extracting: debian/output/linux-image-6.6.0-1-librem5_6.6.40pureos1~byz1+gitlabci1_arm64.deb
extracting: debian/output/linux-image-librem5_6.6.40pureos1~byz1+gitlabci1_arm64.deb
extracting: debian/output/linux-librem5_6.6.40pureos1~byz1+gitlabci1_arm64.buildinfo
extracting: debian/output/linux-librem5_6.6.40pureos1~byz1+gitlabci1_arm64.changes
$ ls -l debian/output/
total 37036
-rw-r--r-- 1 guru wheel 8614292 17 jul. 2024 linux-headers-6.6.0-1-librem5_6.6.40pureos1~byz1+gitlabci1_arm64.deb
-rw-r--r-- 1 guru wheel 17702184 17 jul. 2024 linux-image-6.6.0-1-librem5_6.6.40pureos1~byz1+gitlabci1_arm64.deb
-rw-r--r-- 1 guru wheel 11417252 17 jul. 2024 linux-image-6.6.0-1-librem5-dbg_6.6.40pureos1~byz1+gitlabci1_arm64.deb
-rw-r--r-- 1 guru wheel 31160 17 jul. 2024 linux-image-librem5_6.6.40pureos1~byz1+gitlabci1_arm64.deb
-rw-r--r-- 1 guru wheel 6329 17 jul. 2024 linux-librem5_6.6.40pureos1~byz1+gitlabci1_arm64.buildinfo
-rw-r--r-- 1 guru wheel 2775 17 jul. 2024 linux-librem5_6.6.40pureos1~byz1+gitlabci1_arm64.changes
Is this the correct one? Because it’s from July 2024…
1 Like
I wrote to Support@ an email:
Date: Sun, 16 Mar 2025 08:30:15 +0100
From: Matthias Apitz <guru@unixarea.de>
To: Purism Support <support@puri.sm>
Subject: frequent locks after update to 6.6.66pureos1~byz1, 6.6.74pureos1~byz1
Hello Purism Support,
With the apt-upgrade on March, 13 came among other packages:
Start-Date: 2025-03-13 06:58:41
Commandline: apt full-upgrade
Requested-By: purism (1000)
Upgrade:
...
linux-image-6.6.0-1-librem5:arm64 (6.6.66pureos1~byz1, 6.6.74pureos1~byz1)
linux-image-librem5:arm64 (6.6.66pureos1~byz1, 6.6.74pureos1~byz1)
End-Date: 2025-03-13 07:01:35
Since then I face frequent locks of my L5. See also the forum at
https://forums.puri.sm/t/new-kernel-system-lock/27998
Such locks are fully reproducible with the following procedure:
- USB tethering a laptop
- run a SSH session from the laptop into the L5
- exit from SSH
- pull out the USB cable --> lock
What is the official advice of Purism's Support for this, either as a
fix or providing a way back to a stable version?
Thanks and Kind Regards
and got an automatic reply with a ticket number #7942.
2 Likes
I have been coming across the same issue. I think PureOS also keeps one older version of the kernel in /boot as well for occasions such as this. I always forget what the command is to downgrade to that kernel, though.
2 Likes
sudo flash-kernel <VERSION> --force
Though that’s only kept with major release granularity, so you’ll only be able to go back to 6.5.x this way if you have it still installed, which is very old at this point and may cause other problems when used with recent userspace.
3 Likes
Just like to notice that version ‘6.6.66pureos1~byz1’ works for me for a long time without new issues…
2 Likes
Could you please try to run this procedure:
Such locks are fully reproducible with the following procedure:
- USB tethering a laptop
- run a SSH session from the laptop into the L5
- exit from SSH
- pull out the USB cable --> lock
edit: It’s not even necessary to run the SSH session over USB tethered. Just connect (when tethering is configured), wait a bit and pull out the cable.
1 Like
It would happen to me even when just unplugging the charging cable, too.
There were also seemingly random freezes during light internet browsing and other normal use.
1 Like
I experience system hangs as well. Mainly when connecting to USB. I saw hangs both when connecting to my car audio via USB, and also when connecting to the USB of my laptop. Just connecting to a USB power supply does hangs (until now).
1 Like
I’m wondering how long will it take for Purism to come up with a solution. I don’t mean a fix, but deliver an older working kernel as an update.
1 Like
I now always do before ending the SSH over USB a command
sudo shutdown -r
This reboots the L5 and when the disk encryption key is asked, I pull-out the USB-cable.
1 Like
Hi,
Same problem here. I upgrade a few days ago:
(from /var/log/apt/history.log)
Start-Date: 2025-03-16 22:07:50
Commandline: packagekit role='update-packages'
Upgrade: ... linux-image-6.6.0-1-librem5:arm64 ...
The most obvious and repeatable problem is the LTE sharing through USB. Every time I plug my librem5 on my computer, it freezes. And Nothing obvious in the system logs.
I will try @dos fallback to 6.6.40. (july)
→ no more problem.
1 Like
I probably won’t be very helpful here, but I was catching locks even before the upgrade. If anything I can get for you to debug I will be more than happy. So far I have no clue why this is happening
2 Likes
From my experience the system seems to lock once connected via USB-C to another host (which I usually use for tethering my ethernet connection to it) - I can reproduce the lock like this. Only charging via USB-C does not seem to cause issues.
Hope this information helps.
2 Likes
There are two separate issues there.
One is random lockups and performance issues on Purism kernels 6.6.52 and above, which seem to happen only on some devices.
One is USB related lockup on 6.6.74. From a quick look it seemed to be already fixed upstream, but I have yet to look closer.
4 Likes