evtest output of first pressing backslash/pipe key (lower left corner) and then hash/tilde key (just left of return), with pristine udev:

Event: time 1536705976.250768, type 4 (EV_MSC), code 4 (MSC_SCAN), value 56
Event: time 1536705976.250768, type 1 (EV_KEY), code 43 (KEY_BACKSLASH), value 1
Event: time 1536705976.250768, -------------- SYN_REPORT ------------
'Event: time 1536705976.367113, type 4 (EV_MSC), code 4 (MSC_SCAN), value 56
Event: time 1536705976.367113, type 1 (EV_KEY), code 43 (KEY_BACKSLASH), value 0
Event: time 1536705976.367113, -------------- SYN_REPORT ------------
Event: time 1536705984.751884, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2b
Event: time 1536705984.751884, type 1 (EV_KEY), code 43 (KEY_BACKSLASH), value 1
Event: time 1536705984.751884, -------------- SYN_REPORT ------------
'Event: time 1536705984.868556, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2b
Event: time 1536705984.868556, type 1 (EV_KEY), code 43 (KEY_BACKSLASH), value 0
Event: time 1536705984.868556, -------------- SYN_REPORT ------------

The full contents of /sys/class/dmi/id/modalias (usable for udev matching):

dmi:bvncoreboot:bvr4.6-a86d1b-Purism-4:bd06/29/2017:svnPurism:pnLibrem13v2:pvr2.0:rvnPurism:rnLibrem13v2:rvr2.0:cvnPurism:ct9:cvr:

dmidecode -s system-product-name provides same result - if that is what you wanted.

Result of running dmidecode -s baseboard-product-name as root:

Librem 13 v2

@jonas.smedegaard Can you try with manually removing:

lshw reports motherboard as "product: Librem 13 v2" and "version: 2.0", and firmware as "version: 4.6-a86d1b-Purism-4" and "date: 06/29/2017".

@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.

Yes, my _problem_ is that pipe key gets mis-interpreted (see T443).

Yes, it is harmless.

Just to check is

volume group luks not found

Boot error another cosmetic thing or is there a problem in my fstab/crypttab (note computer boots fine)

@jonas.smedegaard are you able to recreate the problem listed in this ticket with your Librem 13 UK?

Thanks for the feedback.

Okay, it works, i had tried to upload files near 2 mb. I can upload files below 1 mb, etc.

I seem to recall mentions of filesize related to this: How big were the files you tried but failed to upload?

Hi tasty,

This package - when redistributed in PureOS - does not suggest installing any nonfree packages (only a non-existing package).

I use a Librem 13 v2 UK (see T443).

Today I've gotten two different explanations

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:

Kyle, alas I think you are regrettably missing a lot of back-and-forth on this issue. The UK Librem 13 does have this issue in the sense that I needed to apply a /keyboard firmware/ update to fix it. No systemd patch could have possibly fixed it. There is nothing for me to apply now given that I applied the "BIOS"-level update.

@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?

Librem 13 US models have a problem with their keyboard EC firmware, causing the pipe key to give incorrect scan code.

@mladen.pejakovic and @chris.lamb (cc @todd )

Resolving.

In T571#10542, @mak wrote:

Your PureOS is tainted.

Your PureOS is tainted. The only versions of gnome-software that we include in PureOS are:

gnome-software | 3.28.0-1pureos1 | green      | source, amd64, arm64
gnome-software | 3.28.0-1pureos1 | landing    | source, amd64, arm64
gnome-software | 3.28.0-1pureos1 | purple     | source, amd64, arm64

The PureOS specific change includes exactly a difference to recognized things from the pureos-main archive as free.
Please reinstall your system to ensure that you actually only have stuff we ship in PureOS, and make sure that no non-PureOS sources exist in your sources.list.
The output of apt list suggests a manual installation of a foreign gnome-software package (highly likely from Debian), but it could also be that it was updated once and the source it came from has been removed meanwhile (if you know that you manually updated gnome-software that is fine, in this case you would need to reset the package and can maybe avoid a reinstallation).

I can't reproduce this issue - the software is shown as "Free" for me.
Which version of gnome-software do you have installed? (apt list gnome-software)

Ah, the version in the screenshot indicates that it is the Debian package which gets installed.

Password Safe as shipped upstream contains code which has been removed from Debian redistribution due to its licensing.

What is displayed if you click on the red "Proprietary" field?

Also, i removed .gimp-2.8 directory from user and it does nothing.

Also, there is no output from terminal with no option and verbose, console messages and debug handlers enabled.

I agree, but it does show that it's a problem with your particular setup, what particularly is the problem and have you tried running from terminal

I have installed it from flathub and i have no problem, it works but i would want use official build, flatpak packages have a bad performance and flathub has propietary software on their repositories

I am using the official repository version.

Gimp works fine on my system latest version, do they offer it as a snap/flatpak

Dear all,

GIMP worked on my system four updates ago. ImageMagick it works but is very limited and i have no plans to change my default image editor.

https://forums.puri.sm/t/what-should-we-have-on-the-pure-browser-start-page/3792

gimp didn't come pre-installed on my system, but have you tried using a different image manipulator or an older of gimp?

Done :)

@mladen.pejakovic For what purpose? (What can he do here that I cannot?)

Done, GIMP is at 2.10.6-3 in landing now.

@chris.lamb Let's hand it over to Mak?

Hi tronkel,

Speficially Matthias has shared some info here: https://tracker.pureos.net/T99#10198

yes please.

Thanks @jonas.smedegaard. Want me to handle this? (I see I remain assigned..)

Seems Gimp 2.10 defaults to single window mode, and our fork can be dropped.

(NB. reply on that Debian bug report)

Tempted to close this issue as there is no clear "next action". Any objections?

@mladen.pejakovic Hey hey, what's the status of this? I'm just wondering what my next steps here — the ticket is currently assigned to me, but I have no obvious 'next action' as far as I can tell.

It's in debian testing now.

I have reported a problem
3-steps-needed-to-start-using-laptop-instead-of-2-steps-before
which Mladen linked to this tracker.

I have reinstalled GIMP without affect it.

Apparently, no problems on news user, only on the user created from the installer.

The website show now sign-in instead of Apache page.

The canaries use now science news from reuters.com, see at step 3:
https://github.com/purism/warrant-canary/tree/master/canaries

by filename information I mean the filename, such as: "pureos-8.0-gnome-live_20180826-amd64.hybrid.iso" which also contain useful information such as date (when iso was generated?)

I would describe the symptoms slightly different, but I'd say it has the same cause. (Assuming purism-power-optimisations)

This issue, as well as all reboot failures related to missing swap partitions are now addressed in the latest PureOS images.
In total, this issue and issues related to it consisted of 5 completely separate issues affecting various aspects:

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.