I am running a Librem14 (5.10.0-9-amd64) and was experiencing this same issue. Instead of purging gufw I needed to purge ufw. Before purging I noticed the ufw service was in a masked state after removing the package with apt. I also cleaned up /etc/ufw after the purge. I used the iptables rules in this bug report as a workaround and saved those to /etc/iptables/rule.v4 and .v6 so iptables-persistent would see them and rebooted. This fixed my issue, the networking was restored and the machine no longer would hang after decrypting the drive.

A user found out possible cause:

@mladen Feel free to direct people to enter more details of their issue here, I get notification quickly.

Reopened to collect other issues and hopefully other solutions.

@jeremiah.foster some people still report the issue, even though they have the latest ca-certificates (both on amber and byzantium). Any way to troubleshoot this further?

On my amber instance here, running an upgrade just of ca-certificates would work but I've already done it and get an expected result;

$ apt upgrade ca-certificates
Reading package lists... Done
Building dependency tree       
Reading state information... Done
ca-certificates is already the newest version (20200601~deb10u2).
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Updating ca-certificates is the same as updating any other package, simply do

@jeremiah.foster could you please explain how to update ca-certificates?

@guido updated the tag on screenshot

We consider byzantium to be stable now. Awesome list btw!

Screenshot works for me (it's not adaptive and only capturing the full screen works) but I use it all the time.

This is resolved now - please test the images available on https://downloads.pureos.net/byzantium/ (preferably the latest ones built ^^) as I could only test this on a few systems and configurations that I had available. The images should support UEFI, as long as secure boot is not enforced, as the necessary pieces are not signed.

lo0 You may be right. My original URL was tested and now fails. I'm having trouble connecting to the new URL however so cannot confirm.

@jeremiah.foster I believe the sonic url is actually https://mirrors.sonic.net/pureos/repo/pureos/

Updating ca-certificates on Byzantium solves this issue.

Amber works now but Byzantium still fails.

...or in this case, package repos (plural) as this issue affects both Amber and Byzantium.

thanks, @evangelos.tzaras - but you guessed correct: please only close when done from a user perspective, i.e. when fix has reached target repo.

With https://source.puri.sm/Librem5/debs/pkg-phosh/-/merge_requests/21 merged this can be closed (unless it's preferred to wait for a new release incorporating those changes reaches the archive)

My understanding was that in Debian they updated the buildd chroots. In any case, Stelios writes; "very likely an issue client side. a few days ago intermediate lets-encrypt certificates expired ,workaround on older debian systems was to drop the line DST from /etc/ca-certificates.conf and run update-ca-certificates its not a server side issue its a client side issue".

We certainly can't update the system's certificates store, as that would mean people couldn't get the update that lets them get updates again :-P

It looks like updating the certs for repo.puri.sm is the workaround. Asked systeam to do this and then we can test again.

More here: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1944481