In T448#7988, @mladen.pejakovic wrote:

It appears that this is already described in forums: https://forums.puri.sm/t/kernel-panic-after-recent-update/3171/

It appears that this is already described in forums: https://forums.puri.sm/t/kernel-panic-after-recent-update/3171/

https://lists.puri.sm/pipermail/pureos-changes/2018-May/000299.html might be the culprit, but I can't see how.

(Do we have any more info? For example, which packages were upgraded?)

Fixed in 3.27.92-1pureos2 and filed the default group request in T447.

My apologies. The username is pureos and there is no password. :)

Fixed in 1.7.9-1 which is now in PureOS green. Enjoy :)

I tested it too, it fails again.

@chris.lamb Tested it. It's wrong login.

The issue was caused by allowing an openvpn-based vpn to start automatically on boot. The vpn config file ran /etc/openvpn/update-resolv-conf which ran /sbin/resolvconf (or exits if the resolvconf package is not installed). So in the case where the resolvconf package is not installed, there is no problem if you boot the system and stop the vpn. However, the resolvconf package was causing the default nameservers to be 192.168.237.*

Thanks!

This is the output from GNOME Boxes:

I use Debian unstable on my laptop.

Yes, it works, it's now building properly. thank you very much for the soooper prompt fix!

@Uhino Could you try "user" with no password?

Fixed for a while already, I forgot to close the bug report.
Thank you for reporting the issue!

This should be fixed now (and ideally won't ever break again).

This has been resolved for ages now, thank you for reporting the issue!

It's fixed, and tested. Make sure you delete the flashrom directory so it gets checked out cleanly (rm -rf coreboot/flashrom/) then retry, it should work now.

I get the same problem when i tested in virtualbox. Try'd multiple username and password combination but no luck. What is the default login?

Yes, it's a library dependency (libusb) while flashrom is being compiled by the script. It's unrelated to the kernel (though the kernel also uses libusb and is affected by the same issue).
It looks like this was fixed in flashrom 11 days ago and the commit is here : https://review.coreboot.org/cgit/flashrom.git/commit/?id=291764a70e6d8b212680e311bfb0825abf2b9a2f
I'm now testing it and I should have it fixed and the script updated within the hour.

thanks for looking into this @kakaroto, the error is popping up while building the coreboot from your script, so would it not be an issue with library dependencies installed ?

I don't think the patch to the kernel is relevant here since coreboot has nothing to do with the linux kernel. I think the patch needed has to be on the flashrom project itself. I'll have a look and see if that was recently fixed upstream, then I'll update the flashrom we use in the build_coreboot script, and test it.

Heh, you must have missed see the oodles of scrollback on Riot me begging folks to open a suitable number of issues, whichever they are? :p

(just for the record: @chris.lamb in a chat discussion I was unaware of the existence of T439 and possibly Kyle was too, since our discussions was on whether it would be sensible or not to _open_ an issue regarding UK keyboards or maybe better to instead use a wiki for that.)

@heather.ellsworth wrote:

the problem is that PureOS induces the use of private extensions because it uses the Mozilla store. and this is pretty bad (see the pictures below).

@heather.ellsworth Thanks for providing input on chris' keyboard issue - but since that is *not* a US keyboard it confuses matters to share that info here. Perhaps discuss with @kyle.rankin where to put your info as he has some ideas on where to most appropriately put it.

Hmm.. so I have been running a script just after reboot that does some post startup things, including setting the keycodes. If I disable the running of that and reboot, then it appears that my keycodes are magically working again and I have no idea when this started working.

Hmpf, looks like we are detecting it fine and applying the correct keyboard_key setting (note KEYBOARD_KEY_56=backslash). Any other developers with a US keyboard lurking here?I have a UK keyboard so am now a little stuck :)

My systemd version is 238-4

My systemd version is 238-4

@heather.ellsworth Thanks for that. So, you shouldn't have to do that .. can you clarify which version of systemd you are running? Please run apt list systemd

Sorry for the late reply. I have a L13v2 with a US keyboard. After I reboot my Librem, I always do sudo setkeycodes 56 43 and that fixes the issue.

I spoke with the cryptroot maintainers in Debian and they are planning a bit of rewrite within the next week, so I won't immediately work on this as the patches won't apply.

@chris.lamb Ah, okay, makes sense. :) Sorry, retitled now.

@mladen.pejakovic Was asking you to retitle as you are the one who knew/knows the status of this. :) There's been enough confusion and/or missing info already, I don't want to add to that by an inaccurate naming.

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