i now have 2.6.1+ds-1+deb11u1 and i cannot even log in.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Dec 17 2021
I have updated 6/12 and again 17/12,
i now have 2.6.1+ds-1+deb11u1 and i cannot even log in.
Dec 16 2021
Dec 15 2021
Dec 9 2021
Systemd v248 reverted the software workaround: https://github.com/systemd/systemd/commit/ba2b8f9
Dec 7 2021
Dec 2 2021
Nov 28 2021
Nov 22 2021
Nov 19 2021
Nov 12 2021
gnome-authenticatior already is packaged in Debian, but it is an old version; 3.32
Nov 8 2021
Awesome, thanks for the feedback.
I used the GNOME Disks and reset the passphrase with no issues, worked pretty smoothly, no issues since.
My L15 is still hummin along just fine.
@Wildfire yes, this is fixed in Debian Bullseye
Nov 4 2021
@mak
If time permits please have a look into updating base-files.
Nov 1 2021
To add to this: if initramfs-tools is replaced by dracut the resulting initrd will not include functionality to decrypt a LUKS root filesystem using a LibremKey.
I guess this is done now...
@joao.azevedo please note that bundling multiple issues makes them all harder to track - e.g. I would be uncomfortable assigning the issue report to myself if knowledgable about only a subset of involved issues, would only flag it as done when all parts were done, and would have a hard time noticing when all parts were done.
Assigning to you, @jeremiah.foster as you seem to be involved already and know at least some bits of it...
Sorry for the late reponse.
Unfortunately, PureOS does not support non-free environments like VMware. You are of course welcome to try use it in such environments, but we cannot help with issues you may encounter related to that.
Closing due to lack of info.
I guess Adrian isn't active on this any longer, so reassigning back you to, @jeremiah.foster
@ChriChri Just for some extra context:
available since some time (entered Debian 2018-12-21)
available in Debian since 2018-12-21
Oct 31 2021
Oct 28 2021
I have not been able to use nuitka at all because the only version available in byzantium depends on a too-new version of base-files.
@guido Your assumption about the version we want is correct, I haven't looked at the current version within Debian yesterday. Due this I was also not wondering about the not visible new Debian version on the synchronization dashboard, seems there is a issue on not detecting the higher version in Debian, Matthias will be the only person I guess which can demystify this.
@carsten.schoenert I think we want base-files 11.1+debu11u1 + pureos changs, yes but @mak should confirm. What puzzles me is that it doesn't show up at https://master.pureos.net/sync/landing
Oct 27 2021
Ah, I see it now: the older version mentioned by Carsten is the one currently in PureOS Byzantium.
which version of nuitka has such tight dependency on base-files, and why?
Seems your are right. That will require a update of base-files for byzantium.
Oct 25 2021
This seems to have been resolved in the intervening period - due to updates I guess.
Oct 21 2021
Oct 19 2021
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.
Oct 17 2021
Oct 15 2021
A user found out possible cause:
Oct 13 2021
@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?
Oct 11 2021
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.
Oct 9 2021
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.
Oct 8 2021
@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.
Oct 7 2021
@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)
Oct 5 2021
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