I've gotten the script to lock the screen when run. There are problems using 'remove' however in the udev rule, I don't think that our Vendor ID is showing up. At lease when I run
udevadm monitor
the Vendor ID is not picked up and consequently the script is not run. I'll test via other means and other parameters.
I have made an upload - I will push the git repo to the Debian Python Applications Packaging team on salsa when I can see that it is in the NEW queue.
When I run the command on the command line
/usr/bin/dbus-send --print-reply --type=method_call --dest=org.gnome.ScreenSaver /org/gnome/ScreenSaver org.gnome.ScreenSaver.Lock
I get;
I added the debugging info and the file was not created when I removed the key, so I don't think the script is being run. I tested the script as root without the key and the script outputs info to /tmp correctly.
No need for apology - your concern is appreciated even if it turns to be unfounded.
Upon rechecking, flathub is not offered as a default source.
This sounds similar to issue T585.
This is most likely not a coreboot issue. I tested on a machine that has proprietary firmware and memtest did not work.
Hmm, now I found https://puri.sm/posts/music-player-lollypop-added-to-pureos-store-for-librem-5-phone-and-laptops/ .
It isn't already packaged, right?
@mladen I'm able to reproduce in case you need me to provide more details
I have started looking at packaging this - I can provide a packaging repo containing my work soon. I guess packaging in Debian is the preferred way, and not in pureos. I'll take ownership of that RFP.
Oops!
Why?
I'm not sure whether the 2 issues are related or not. I should have authored a new task and cross-referenced.
Noticed the same reproducible sequence of events in:
Interesting. Might be related to Calamares.
My feeling is that we ought not permit packages or apps to download code from external sources, at least not at install time. This seems like security risk.
I'm also experiencing this problem. After showing the Purism logo, the screen remains black for a couple minutes, then displays the same kernel panic.
I have a Librem13v4 with the 128GB SATA SSD.
In the cases where the /etc/crypttab is pasted (in the original post in this issue) I can see that both crypttabs have /
We need to determine where the issue is. Can we get a copy of /etc/crypttab? Also, can the customer boot into recovery mode? Is there any other information on the situation like log messages or output from 'journalctl -xe'?
I'm not sure what tokens do, but I didn't mean to cycle like that :-)
@noe.nieto While you are at perfect liberty to install any flatpack you want, it is not in your best interest to install flatpacks that:
Am looking into this, but not simple due to upstream changes requiring additional Python libraries packaged.
@jeremiah.foster @mak not that update-initramfs did not fixed issues, but it made it worse: customer now cannot boot even the older kernel version.
cryptsetup: WARNING: Resume target luks-36631c43-3d73-428b-ac97-b518d1838185 uses a key file
cryptsetup: WARNING: Resume target luks-36631c43-3d73-428b-ac97-b518d1838185 uses a key file
The user upgraded via sudo apt update && sudo apt full-upgrade and also did sudo update-initramfs -u -k all and here's the output:
Thank you for the feature request, but unfortunately we'll definitely not have cdrtools in PureOS.
There has been an old fight about its license change which I really don't want to start again. Also, the legal situation didn't really change and Debian, the FSF and Red Hat all agree on this particular legal issue.
Plus, to put it frankly, Jörg Schilling is one of the least fun upstream developers one could ever deal with.
@jonas.smedegaard Do you think it's worth packaging and if so who will be the maintainer?
@mak Can you make it happen?
I can do that, of course, but as I said already, this is happening for the 2nd time, after a new/clean installation from a USB flash drive with a PureOS8 ISO image. After installing some of the system updates, this issue appears. How can I be sure this would not happen again?
@mladen Can we ask the user to do an apt-get update && apt-get upgrade? Otherwise we need to get more information.
A user recently upgraded via Software Center and had this issue. He can successfully boot *4.19.0-2* but the newer kernel (4.19.0-5):
@gorgeous I suggest you do a re-install, you will save yourself a lot of time. Your installation seems very broken.
Similarly we need to update the welcome screen (language page) of GNOME Initial Setup. I'm happy to patch the app, but for that we need to ship a logo to dislqy in the OS first.
@mladen & @Erik_Leroux please help me with this issue! :(
Many thanks!
Thank you!
Just FYI - in latest PureOS live/OEM images memtest (and also HW detect) are not working from the Grub menu.
This should either be fixed or the menu entries removed from Grub.
Using the Qt-version on PureOS and the status icons aren't really needed. The popup for allowing a device looks a little bit out of place, but it works flawlessly.
@gorgeous Did you try this procedure: https://tracker.pureos.net/w/troubleshooting/broken_upgrade/#problem-2 (solution for problem 2)?
This has been updated a few days already, but the new images weren't fully tested yet (so aren't on the pureos.net page for download by default). That should happen this week.
Thanks for the heads up though!
@nicole you said "I am not sure if this issue relates to Coreboot," I was simply confirming that it does not / is a different issue altogether :)
That's what I wrote?
This is not Coreboot, it is a PureOS issue.
@nicole this isn't a coreboot issue. If you boot a Qubes 4.0.1 ISO (eg) and run memtest from there, it works perfectly fine.
Is there any workaround for this, any way to install PureOS on a UEFI system? I would like to try PureOS on my laptop but it seems I am stuck due to this issue.
@MrChromebox I am not sure if this issue relates to Coreboot. I see exactly this issue when e.g. booting from the OEM or live image and choose the memtest from the Grub menu.
And yes, I would also like to see this fixed since being able to run a memtest from a USB stick would be very helpful. I have not yet tested if this issue also applies to a PureOS installation.
(tested with latest OEM image 2019-07-14)
More detailed picture with messages on the 2nd attachment.
