- User Since
- Jan 16 2018, 6:03 PM (57 w, 1 d)
Thu, Feb 14
The cryptsetup-initramfs package has a README on configuring gnupg-sc, but I've found it's not entirely accurate and is too focused on configuring a *new* and non-root disk.
Just confirming that we can close this ticket.
Mon, Feb 11
This particular ticket is about the German keyboard layout issue where the pipe key does work, but sends an incorrect signal, not about the unrelated UK keyboard issue where the key does not send a signal at all.
It's not a firmware problem exactly. The keyboard is a *different* layout than the default US/UK/DE layout, it's a variant. In the US case it's a US alternate international layout. If you dig down into the keyboard options and set it to that, the pipe key works, however during an install everyone naturally picks the default US keyboard layout (or UK or DE, depending on the device) and almost every key works as expected except the pipe key.
Thu, Feb 7
Tue, Jan 22
My apologies, I have no idea where I got that number. I reviewed my own hand-edited file and it says "backslash"
This is the value I used and tested, and it's the value that we used for the other entries that were already in the file. If we were to change it for this case, we should also change it for the other, previous Librem 13 entries.
Jan 21 2019
Yes, this should go upstream like with the parent issue. I have tested this fix against my Librem 13 v4.
If it's better to open a new ticket than comment on this one that's fine, but having all the context of this ticket is useful. We now have a Librem 13v4 and so need to modify the same systemd files to add:
Dec 5 2018
It probably makes sense to keep this open until the package shows up in PureOS (having it in Debian is nice, but not sufficient). Once it makes its way into PureOS then sure, close the ticket.
Nov 29 2018
In the mean time could you add a task that erases/truncates /var/log/auth.log after that script runs?
Nov 21 2018
Thanks for the update. Let's leave this ticket open to track the work in bringing the updated cryptsetup package into PureOS. Once that package exists in PureOS we can close this ticket.
Oct 23 2018
I want TB to be packaged by PureOS and installed by default on PureOS unless there is some Free Software licensing issue that would prevent this (I don't believe there is).
Sep 27 2018
We do not need or want it. Specifically the problem with systems like vboot (and why we went with Heads instead) is that we do not want to require that the BIOS pass a signature check against a key that we control. We want the user to be able to flash with a custom BIOS if they so choose, even if we haven't blessed it with our signature.
Sep 25 2018
Sweet! So, what's the timeline look like for me to be able to test this on something?
Sep 11 2018
@mladen.pejakovic so far we don't have anyone in-house who is able to re-create this specific problem but clearly you are getting some kind of support request that motivated you to file this ticket.
@jonas.smedegaard are you able to recreate the problem listed in this ticket with your Librem 13 UK?
Sep 10 2018
This is why I'm trying to narrow everything down to specifically which models are having the specific issue referenced in this ticket. Today I've gotten two different explanations:
@chris.lamb Since you have a UK model, could you please apply the patch @mladen.pejakovic is referencing above and see if you can recreate this regression?
Aug 31 2018
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.
Aug 13 2018
Sorry, by "upstreaming" I meant "get packaged into Debian." At the time I wrote this in February I was hoping we could get this into PureOS relatively quickly and had assumed that getting this packaged into PureOS would be faster than into Debian so I wanted to do the fast thing first if it was indeed faster.
Jul 9 2018
The point about it just being a shell script is valid. I would be perfectly fine with including this script (or a similar forked script) directly into cryptsetup-initramfs, especially if that helps speed the process along.
Jul 5 2018
Just checking in on the status of this ticket. We are not yet at a place where this is blocking other activity but will be within another week or two.
Jun 27 2018
This problem seems to specifically point to the installer not changing its own active locale during the install process, but merely setting the default locale for the install on disk.
Jun 1 2018
This issue has been resolved.
May 31 2018
Apr 6 2018
Hmmm it worked the second time around... on the VM. Going to test on bare metal now.
Sorry, I mean the "Install PureOS" application that runs within the Gnome desktop crashed. By crash I mean the installer application disappeared. I will see how repeatable it all is.
I've had this application crash for me both when testing in a VM (at that point at the disk encryption password section) and also when trying directly on bare metal Librem 13v2, when trying to connect to wifi.
Apr 3 2018
It would be possible after the fact to even go as far as to reformat the swap partition to be a non-LUKS volume and treat it as regular unencrypted swap, if you wanted, but as @mak mentioned, it would be better to keep it as encrypted, but as a different kind of persistent encryption.
Apr 2 2018
Or if the attacker happens to read the contents of swap while the system is running. Since it isn't overwritten at each boot, it's possible imaging swap while the system is running would reveal old secrets that weren't securely wiped.
You make a good point. In this case it's a security tradeoff because suspend-to-disk creates a security vulnerability since secrets that were in RAM only (disk decryption keys, passwords) could be written to disk and potentially be recoverable.
The swap partition should be encrypted with a random LUKS key like in a standard Debian install instead of via a key file. It's a feature that encrypted swap is blown away each reboot.
Mar 7 2018
@netnut404 If you are willing to use X instead of Wayland, you can switch to that and follow my steps above to generate modelines for the resolutions you want.
Feb 14 2018
Feb 13 2018
I tried the setcap command but still got the same error on PureOS.
Feb 6 2018
More debug info:
I added more logging and tried again. here are the (sanitized) results:
I've uploaded virsh capabilities output as well
When you attempt to start a pureos live cd image in Boxes, you will get the following error in the terminal:
Feb 5 2018
After discussion, removing the PureOS tags as we don't want to risk tainting PureOS with the remaining proprietary software in our coreboot firmware. This project will remain on the coreboot side.
Given most of the work for this is not coreboot work, but PureOS work integrating an existing firmware image (which we'd treat as a binary blob) with fwupd, I don't know that this is really a coreboot project as much as a PureOS project.
Jan 26 2018
I prefer and would advocate for option 2 because it instructs sites that (mistakenly or not) use browser versions to determine how to behave that PureBrowser is most compatible with a particular version of Firefox (which it is, having been almost entirely derived from that browser, with some modifications), while also informing the site that the browser is not in fact Firefox, but something else.
Before the ticket is closed for good, could you provide a User Agent string workaround (if that would work, otherwise some other workaround) so we have steps to present to another user who runs into this or similar problems?
Jan 25 2018
From what I've read on https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/EDID/HOWTO.txt the kernel only includes EDIDs up to 1920x1080:
Jan 24 2018
I was able to get a Librem 13v2 to output at 2560x1440 by switching to GNOME on Xorg at the GDM login prompt for my user and using the steps from here to generate a custom modeline.
Jan 23 2018
The Ubuntu 14.04 Live disk was able to see the full suite of resolutions from my external monitor up to 3840x2160 @ 30hz and 2560x1440 @ 60hz. It uses the 3.19.0-25-generic kernel so perhaps we are seeing some regression with Skylake on more recent 4.x kernels.
I've tested this so far with a few other Live disks including Tails (4.14.12-2 kernel), Fedora 27 (4.13.9-300.fc27.x86_64), Ubuntu 17.10 (4.13.0-21) and Ubuntu 16.04 (4.10.0-28-generic). All of those live disks had the same 1080p limitation.