See also: https://a13xp0p0v.github.io/2018/07/07/kconfig-hardened-check.html

I fixed this bug, which unfortunately brought us another (already known) bug of the swap partition not unlocking properly.

@mladen.pejakovic That's a different issue that was already fixed a while ago.
The one in this bug is actually even older and has been in PureOS forever (we just didn't see it because initramfs updates aren't triggered that often, and it is not that severe in its impact).

What should actually happen here is / being decrypted with a password, and swapfs being decrypted with a keyfile on /.
Or, as a second option, swapfs being reformatted at boot time.

Testing migration can be tracked here:

@kyle.rankin I have followed up to the bug (CC'd you)

Maybe it can help you:
https://lists.debian.org/debian-kde/2018/08/msg00030.html
https://lists.debian.org/debian-kde/2018/08/msg00032.html
Hope it will help

Hi @chris.lamb I just wanted to check in on the progress with this. Looking at the official bug it looks like things have stalled a bit but maybe there are other things happening behind the scenes with people working on packaging that I'm not aware of.

https://forums.puri.sm/t/on-boot-lvm-is-asking-the-same-password-twice/3547

You can fix this by changing the parameters of whetever is your swap partition to /dev/urandom swap,cipher=aes-xts-plain64,size=256,
e.g.:
luks-aaaaaaaa-a86a-469c-812f-92b36f70113e UUID=aaaaaaaa-a86a-469c-812f-92b36f70113e /dev/urandom swap,cipher=aes-xts-plain64,size=256

I selected the default partitioning option.

This /etc/crypttab is wrong, one line should have been set to auto-format swap.
Did you do manual partitioning, or did you select the default option?

• I contacted another FTP team member so this has been ACCEPTED in good time.

Thank you! :)

The non-comments in /etc/crypttab are:

Hmm, swap should not even be password-encrypted...
What's the content of your /etc/crypttab?

After the update-initramfs and reboot, I always get prompted to decrypt the / partition first and then prompted to decrypt the swap partition second (checked the uuid's against lsblk to determine this). This order is always preserved.

@vivia.nikolaidou Uploaded.

I have seen on the live installer that sometimes when I enter the passphrase a second time to confirm, the installer crashes and needs to be re-launched. This behavior happens sometimes and is not consistently reproducible but it happens frequently enough (when installing to a libvirt VM anyways) for it to be annoying, maybe ~25% of the time. Matthias thinks my issue is related to T547 so recording the behavior here.

I just got confused because mentors.debian.net complains that 4.2.1 is too new

Thanks, reuploaded! I just got confused because mentors.debian.net complains that 4.2.1 is too new and needs 4.1.4, but I am indeed getting 4.2.1 from lintian in sid.

Just had a look - thanks! So, if you're running Lintian from sid then I don't understand why you still have:

Thank you @mak I have added the slideshow to my to-do list and will discuss about it with Tobias. See you on the other issue!

Yes indeed, I am running lintian from Debian sid.

@vivia.nikolaidou Please go ahead and drop the "contrib" etc. and let me know where I can do the review/upload. (Note that the very latest lintian is for 4.2.1... but I assume you are running Lintian from Debian sid...)

I don't have a straightforward way of reproducing this. Let me see if I can find someone who can...

@chris.lamb Sorry - was on vacation last week. :)

I'll once again raise my point regarding "Freedom harm" tagged issues. According to https://www.gnu.org/distros/free-system-distribution-guidelines.en.html:

I was so sure that there already was a ticket, and I even wrote instructions there... But that either happened way back with our makeshift bugtracker, or I must have dreamed it.

Neat :-)
Since the error is triggered by archive metadata, there is no way to ensure people have upgraded their system prior to fetching new metadata. We just have to rely on people upgrading their system regularly.

Running:

sudo apt full-upgrade

After the update errors (therefore, ignoring the error), resolved my issue.

@todd Just run the command I've shown above. Or update with GNOME Software, that should also do the trick.
apt update was actually successful (despite the appearance and exit code), you only need to update your packages with full-upgrade afterwards.

In the error above, I am trying to simply do:

sudo apt update

But get the error. So need to know the work-around to get it updated.

I've already fixed this in Debian days ago and ensured that the issue is resolved in PureOS yesterday.
If you upgrade PureOS fully (apt update ; apt full-upgrade) the issue should be gone.

Done, hashcat 4.2.1-1 is in PureOS now.

2018-08-26 10:28:51 - WARNING: clamav: Target version '0.100.1+dfsg-1pureos1' is newer/equal than source version '0.100.1+dfsg-1'.
This needs a manual dummy upload as described in https://tracker.pureos.net/T99#10198 to reset our package to what Debian ships.

Done.

Done.

This appears to work with the new kernel image and today's (8/26) update.

@vivia.nikolaidou Gentle ping :)

I don't think re-purposing this old bug for a blacklist removal request is a good idea - I was actually a bit confused to me to see seeing the bug appear again with this title...

Done. It's nice that we apparently can get rid of these diversions now :-)

Is this still an issue? Cryptsetup has been upgraded multiple times since this issue was reported...

2018-08-25 19:33:54 - WARNING: xarchiver: Target version '1:0.5.4.13-1pureos1' is newer/equal than source version '1:0.5.4.13-1'.
This needs a manual dummy upload as described in https://tracker.pureos.net/T99#10198 to reset our package to what Debian ships.

WARNING: p7zip: Target version '16.02+dfsg-6pureos1' is newer/equal than source version '16.02+dfsg-6'
This needs a manual upload as described in https://tracker.pureos.net/T99#10198 to reset our package to what Debian ships.

Done.

This is resolved in the latest OEM and Live images, please test them! (for the oem image: https://downloads.puri.sm/oem/gnome/2018-08-25/, the live image is currently building)

Since I am quite out of ideas on this one now, I reported the issue with all information that I figured out so far against cryptsetup at Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907201

As weird as it looks, this issue is the same bug as the OEM encryption issue.

Problem solved after upgrading to 4.6.0-2.
Many, many thanks!

A new image was built and I installed it (https://downloads.puri.sm/playground/2018-08-23/pureos-8.0-gnome-oem_20180823-amd64.hybrid.iso) in virt manager. After the install completed, I was prompted to reboot. Right after the reboot, I was prompted to enter the disk encryption password:

This is supposed to be fixed in libvirt >= 4.6.0-2, which PureOS already has.
Can you please ensure the package is up to date and has at least that version, and then try again?
Feel free to reopen the bug in case the issue persists (it should really be gone though).

The archive generally doesn't support downgrades - versions can only ever go up, otherwise our users will not actually get the changes.
So, if we have a version 0.9.3.2-1+pureos1 in PureOS, I can not sync 0.9.3.2-1 from debian, because 0.9.3.2-1 << 0.9.3.2-1+pureos1.
The archive will also *never* override PureOS-specific changes.
So what I did just now make an 0.9.3.2-1+x1 upload[1], because 0.9.3.2-1+x1 >> 0.9.3.2-1+pureos1. Since there is no "pureos" in the version string anymore now, the next time Debian gets a higher version of this package, the archive will just override the package I uploaded and we will be fully in sync again.

Sorry, I don't follow.

Done, but @jonas.smedegaard if the version number in PureOS is *higher* than the one in Debian, I can't sync stuff. In that case, an upload without the "pureos" version suffix has to be made to PureOS, which is a thing you can easily do as well and which doesn't need me.

yagf does not fallback-depend on a non-free package, only a non-existent one.

hashcat does not fallback-depend on a non-free package, only a non-existent one.

Ah: Dropping the fork was done long ago in T330.