on a haunch I switched the computer from UEFI boot to CSM legacy boot. that did the trick.

I do not. linux quit booting for me at one point, so I had to turn it off.

Do you have secure boot enabled in BIOS?

I did not know how to check it previously. Looked it up, and the SHA256SUM's do match. I tried using etcher to flash the file over to the usb, and I used whatever is native to mint. Like I said though, I did it for a linux mint iso and that one worked.

How did you "put" the PureOS ISO to your drive? Also, did you check it's hashes to see if it was downloaded correctly?

@chris.lamb Yes, it seemed to me the wording would be too complicated, but feel free to retitle if more descriptive title is needed.

UK keyboards apparently require (at least) a hardware fix. This is being tracked in T439.

What's the ETA in rolling this out?

What's the ETA in rolling this out? Will it require any PureOS changes?

Not a PureOS bug, fixed at hardware level.

Jup, we are in agreement - and you did say "academically", so I never though you actually wanted to make that change. But I wanted to make absolutely sure that I was just brainstorming here and had no actual intention of modifying user's group settings in a package - sorry for the confusion :-)

@mak Just to avoid confusion I wasn't suggesting we do that (and I think we are agreeing re. the metapackages vs base-files, no?)

@chris.lamb Obviously IMO no package should do this, but purely academically: The seed packages are inadequate, because they are purely metapackages - their purpose is to pull in other packages that make the actual changes and can be removed individually. We would need a package that is on every system though, and one that actually already influences the behavior of users and groups.
The only package that fits this would be the base-files package, because that one already sets group and path defaults and also is on every system.
Alternatively, the gnome-boxes package could do this, but it would be very unexpected for users to see that the group configuration they have set changes for all users due to installing a package.

@mak I think I agree. (I wonder though, academically,what _would_ be the package for that?)

@chris.lamb Modifying the groups of existing users is evil(tm), and just like writing into $HOME, I don't think we should do that.
Instead, GNOME Boxes could maybe show a nicer error message, so users can add themselves to the group explicitly if they want to.
The groups in which users are is a choice of the administrator who might have intentionally left them out of the kvm group, and we shouldn't change that automatically for every user via a package.

@mak Can you additionally comment on doing that for existing users? There doesn't seem to be a perfect package for this (pureos-minimal is sub-optimal as that's a germinate-based thing, and base-files feels too low-level to me..)

@chris.lamb Ah, I missed the first highlight.
Does adding a user to the kvm group imply any "weaker" security? If not, we can add new users created in the installer to the kvm group, but we likely will have to do that globally, so not only users created by Calamares are in the kvm group by default, but also new user created by our OEM setup wizard.

Fixed in https://github.com/lkorigin/laniakea/commit/a1fd518405a05ad908a5cf4f5cbe5df688b66d6d

@mak Another ping?^

Thanks! Can you link to the commit? :)

Can reproduce on PureOS, but not in Debian.

user I think :)

Done, the suites are now always ordered alphabetically.

I understand, my comment was meant to be, er, self-answering or something.

(I think I'm misparsing, we can get both with the above!)

User-friendly or paranoid? Why not both? Sounds great :D

Assigning to @mak , at least to start off :)

Thanks for your input :)

Is it possible to just make the name friendlier? Perhaps name it on installation ($SYSTEMNAME-disk) or display it like a credit card: "disk ending -1234".

I could have sworn I fixed that already...
Should be rather trivial to address, in any case :-)

Thanks for addressing this problem so quickly!

In T422#7589, @Wayne wrote:

There are now two threads in the Purism forum regarding these issues. In this post:
https://forums.puri.sm/t/new-librem-13v3-won-t-boot-to-disk-login/3064/10?u=wayne

https://gist.github.com/lamby/e45c7a221defe75db026ee529d00c789/raw

I have Librem13v2 with *UK* keyboard.

@chris.lamb Jup, in fact, the arm64 package was already there when I looked at it. See http://software.pureos.net/builds/package/eb2f2109-0755-5fc0-b32f-ad5c5274a56c/1/ for its build logs.

Thanks @mak !

@mak Ah, so we would have (eventually) got an arm64 package (and then it would have migrated) - we would have just have had to wait?

As a side note, I am now a happy user of "GNOME Packages", which does work in Wayland.

@chris.lamb Be patient ;-) Migrating a completely new package taes at least two dinstall runs, so a few hours was just not enough time ^^
@d3vid The website takes a few minutes to update after a new package has been published, so you might have caight the new package immediately after it was migrated, but before it was actually registered in the database as being in green as well.

Just got these changes from an apt updated and rebooted. Works like a charm, thanks!

This package has arrived in green (got it via apt even though http://software.pureos.net/package/source/green/fontconfig still lists -4).

@d3vid That is a blocker, but I adjusted the code again to ignore the arm64 architecture - we don't have enough build power at time to ensure that we can build every single package on arm64 (although in this case, plymouth built without problems).

http://software.pureos.net/package/source/landing/plymouth migration excuses currently list:

Thanks for reporting - this is an (older) duplicate of T433; see there for the current status.

It's in landing now at least. Curious why it hasn't actually migrated given that the excuses mention that the priority was elevated?

Unfortunately a few hours on http://software.pureos.net/package/source/landing/fontconfig is not showing -5 as being in landing or green. There is no reason why it shouldn't migrate if -4 is already there (no change of dependencies AFAICT). Can you help?

Done, if the package can migrate, it should migrate instantly.
Its status can be monitored at http://software.pureos.net/package/source/landing/fontconfig

Would that be because it is not yet in buster?

In T434#7672, @mak wrote:

The system doesn't seem to know that revision yet, I'll bump the packages urgency in advance.

The system doesn't seem to know that revision yet, I'll bump the packages urgency in advance.

This is fixed if you have plymouth-themes 0.9.3-3pureos1 (just uploaded) and fontconfig 2.13.0-5 (see T434 - needs fast-migrating into green).

re-closing this issue for now

Not related to T429a after all I think. I think I have a fix, just need to get back to my Librem machine to test.

Ah, wait, it *is* an unrelated issue: https://bugs.debian.org/897572

Or is this an entirely unrelated issue? Could do with some guidance here :)

Unfortunately, neither the udev rule nor the "setkeycodes 56 43" works for me. Any ideas?

I think it doesn't matter what keys you hit (as long as you press something) it will eventually timeout to some degree.

Re-opening. I just installed plymouth from green and it still has this behaviour.

https://github.com/systemd/systemd/pull/7826 is in our systemd

So, I can reproduce this. ctrl-alt-f2 actually seems to work for me (in the sense that it restores the gui prompt)

@chris.lamb Thanks for the suggestion. I tried only Alt-F2 and it works no better (or worse) than button mashing without it.

@d3vid Can you try Alt-F2?

1. Rough starting point (comments welcome)