Occurs for me as well
3 Likes
8 hours in, also canʼt update from the repository.
2 Likes
I can also confirm for Crimson on AMD64:
sudo apt update && sudo apt upgrade -y
Reading package lists... Done
E: Release file for https://repo.pureos.net/pureos/dists/crimson/InRelease is expired (invalid since 8h 22min 15s). Updates for this repository will not be applied.
E: Release file for https://repo.pureos.net/pureos/dists/crimson-security/InRelease is expired (invalid since 8h 27min 42s). Updates for this repository will not be applied.
E: Release file for https://repo.pureos.net/pureos/dists/crimson-updates/InRelease is expired (invalid since 8h 27min 42s). Updates for this repository will not be applied.
4 Likes
Figured it was affecting all of Byzantium
1 Like
I suspect it affects landing and octarine as well, alongside the debug variants.
1 Like
What could be the cause you think?
1 Like
The errors are clear:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Origin: PureOS
Suite: crimson
Version: 11
Label: PureOS 11.x (crimson)
Date: Mon, 25 Mar 2024 08:22:30 -0000
Valid-Until: Tue, 02 Apr 2024 08:22:30 -0000
Acquire-By-Hash: yes
Architectures: all amd64 arm64
Components: main
...
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Origin: PureOS
Suite: crimson-security
Version: 11
Label: PureOS 11.x Security Updates
Date: Mon, 25 Mar 2024 08:17:03 -0000
Valid-Until: Tue, 02 Apr 2024 08:17:03 -0000
Acquire-By-Hash: yes
Architectures: all amd64 arm64
Components: main
...
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Origin: PureOS
Suite: crimson-updates
Version: 11
Label: PureOS 11.x Bugfix Updates
Date: Mon, 25 Mar 2024 08:17:03 -0000
Valid-Until: Tue, 02 Apr 2024 08:17:03 -0000
Acquire-By-Hash: yes
Architectures: all amd64 arm64
Components: main
...
I do not know why they are not being renewed, but if there is an urgent need to update packages, you can change the date and time.
1 Like
Since this is related to it affecting all current PureOS variants, I think this topic should be edited to be a PureOS issue instead of Librem5
2 Likes
When rolling back the date and time on Byzantium, I’m seeing a message about the IP not being found for Index of /pureos/ byzanium-security
As an error in certificate for the IP 49.13.57.135:443
1 Like
Pinging the IP results in 100% packet loss. I’m assuming the repo servers are down to fix the issue…
1 Like
Hi everyone! The repository was not updating for a few days because a SSL certificate expired on a server that the system has to query while building the repository metadata. For some reason, our monitoring did not pick that up (we will find out why), and Laniakea is logging the error but does not send a very visible notification - yet. I will change that now, to ping us on Matrix if that ever happens again.
I also reconfigured certbot again, this time automatic renewal should not fail.
We are very sorry for the inconvenience, and the metadata should be fully up to date again in a few minutes.
Best,
Matthias
14 Likes
Hi, I updated this morning and it came down a new kernel. On rebooting it, I got nearly a heart break when I saw the message “crypsetup…” for minutes until the boot continued with success. Don’t know what the L5 was doing.
2 Likes
installed a new kernel so you just wait and it should boot up, might require two reboots I noticed. It froze on the second reboot for me at login screen. Third did the charm.
1 Like
Myself, after this morning’s update I find the touchscreen unresponsive at “Enter disk decryption passphrase” screen, same as described in this post from 2 years ago: Anyone experience an issue with the latest update?
Would anyone know if the same solution from that thread works again now? I’m pretty close to giving up on telephony in general! 
1 Like
Better asking in the right thread: Can't turn on after latest update (kernel), no response to touch input, USB keyboard not working
(No worries, your post was first, but collecting same issue together. 
)
2 Likes
That’s no fun. There’s no reason I can see that it wouldn’t work, but there may be an easier way. My problem came about in a weird way, because the drive wasn’t partitioned right, so the fix necessary was probably more complicated than a normal corrupted file or something. It might be good to see if your problem came about for the same reason. Have you installed uuu and connected via jumpdrive before? There’s a way to replace some of your boot files that way:
I’d try fixing by replacing those files first. In any case, I’d check for freespace on your partitions to make sure it doesn’t happen again. I understand they implemented a fix to prevent the issue from happening due to a filled up boot drive, but it didn’t stop mine due to a filled up root drive. Fixing the partition prevented it from reoccurring.
1 Like
Oddly enough, my phone puked (i.e. didn’t respond to touch at encryption log-in) after a recent update too, so I went through the easier process through jumpdrive again. However, I did notice the files were a bit different than they used to be. Now every file, new and old, has its version number. e.g., there’s no vmlinuz nor vmlinuz.bak. There are however four files in the fashion, vmlinuz-6.6.0-1-librem5 and vmlinuz-6.5.0-1-librem5. I couldn’t find a quick way to have the boot sequence point to the older version, so I just copied the four 6.5.0-1’s over the 6.6.0-1’s, and it seemed to do the trick. Maybe someone has a more clever way of just pointing to the vintage file?
Sad side note - when I ran the update again (after I copied over and got it to boot fully), the reboot did the same thing - no touch response at the encryption login screen. But the copy-over worked just fine again. Guess I’ll just wait awhile before I update the phone again, and hope an updated update comes out that doesn’t have the same issue on my phone.
3 Likes
It’s different from most big computers that I have seen where those names will exist without version numbers as symbolic links to the names with the chosen version number (so theoretically it could be easy to revert) - although the previous version may be .old rather than .bak.
Strangely though I am running 6.6.0-1 and I am not experiencing the problem entering the encryption passphrase.
1 Like
I have the following files in /boot:
purism@pureos:/boot$ ls -ltr vm* Sys* init*
-rw-r--r-- 1 root root 26593288 Dec 8 05:26 vmlinuz-6.5.0-1-librem5
-rw-r--r-- 1 root root 4136206 Dec 8 05:26 System.map-6.5.0-1-librem5
-rw-r--r-- 1 root root 66055077 Dec 22 22:19 initrd.img-6.5.0-1-librem5
-rw-r--r-- 1 root root 26806280 Mar 17 14:42 vmlinuz-6.6.0-1-librem5
-rw-r--r-- 1 root root 4176893 Mar 17 14:42 System.map-6.6.0-1-librem5
-rw-r--r-- 1 root root 66096486 Apr 3 05:55 initrd.img-6.6.0-1-librem5
# cat /var/log/apt/history.log
Start-Date: 2024-04-03 05:55:07
Commandline: apt full-upgrade
Requested-By: purism (1000)
Upgrade: linux-image-6.6.0-1-librem5:arm64 (6.6.6pureos2~byz1, 6.6.22pureos1~byz1), linux-image-librem5:arm64 (6.6.6pureos2~byz1, 6.6.22pureos1~byz1)
End-Date: 2024-04-03 05:56:05
...
and the update on April 3 went fine for me too.
Maybe your /boot partition run out of space during the update? Don’t know why the updateer scripts can not check this before.
2 Likes
So, the space issue crossed my mind too, because I had the following versions of each file (not just the initrd):
And I also had even more versions of dtbs:
I did delete most of them, but I still had the same issue on the upgrade reattempt. Now I figure I’ll just wait until there’s two versions up, and hopefully jumping the current one will work?
1 Like