In T792#14834, @mladen wrote:

@gorgeous Did you try this procedure: https://tracker.pureos.net/w/troubleshooting/broken_upgrade/#problem-2 (solution for problem 2)?

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

Silly me. It's already packaged. But it looks terrible in Plasma. It's a Gnome client.

Only if it does not conflict with Purism's philosophy.

yes, this is yet another area of this Mozilla product (unsurprisingly, really) linking to Mozxilla resources.

@jonas.smedegaard i know you have been working on this issue of references of Mozilla and Firefox in purebrowser.

Also see https://directory.fsf.org/wiki/Review:Chromium-REV-ID-1 or https://directory.fsf.org/wiki/Talk:Chromium (the first link might be moved to the last one). Iridium Browser suffers from the same issues (this is described in the references). Also as described there, none of the lists is exhaustive, as we/volunteers from FSD lack some contributors specific for this issue.

This didn't change anything, but I did finally get an image of my screen after entering my decryption password, there are some statements about failed loading of firmware before PureOS boots. The least benign-sounding is:
[ 1.402310] i915 0000:0:02.0: firmware: failed to load i915/kbl_dmc_ver1_04. bin (-2)
Which I take it has something to do with the kabylake graphics processor, but may be completely normal for all I know? There's also a statement about failed Bluetooth firmware which I assume is normal.

Awesome, can we close this now?

I have this snippet you pasted here at the bottom of my /etc/pulse/default.pa file. It came in via the regular update process on June 4th (I didn't add it manually.)

May I ask that you try commenting out

Hi, any advice on getting the splash screen back by editing my grub.cfg file? It's not a huge priority at this point, but I would feel better if I could resolve this.

Thanks for the followup. Feel free to post status updates here about the upstream progress :-)

Thanks, @rinigus !

I suggest to close this - looks like pyotherside made it to PureOS

Sorry for late reply - haven't received any notification regarding it by email.

@EchedeyLR Thanks for investigating. Please however report any concrete findings as separate issues.

I think there is still a similar problem with Chromium like https://tracker.pureos.net/T663 due to Google dependence/promotion.

In T57#14719, @jonas.smedegaard wrote:

@mak Please stop block chromium - it does not contain non-free code and is no longer unclear about licensing.

If I remember, Chromium is not packaged on Trisquel due to more problems but I am not sure.

@mak Please stop block chromium - it does not contain non-free code and is no longer unclear about licensing.

See https://software.pureos.net/sw/linphone.desktop
(there is still a warning that the icon is upscaled, which could be fixed in the packaging)

This seems to be fixed now - sort of...

Thanks for reporting.

Thanks Jonas!

Since this bugreport may be used as inspiration for users wanting to work around the issue, I have adjusted the description to talk about adding file below /etc, because editing existing file below /lib is lost when package udev is updated.

Well, the message was a false and the actual culprit was a SQL query failing. The cause of that is fixed now, so this shouldn't happen again (but if it does, I'll look into it again). Not sure why exactly the database was in a wrong state though, but that's really hard to figure out at this point.
That's why the issue is resolved.

It should not be surprising that logfiles indicate that -1pureos2really60.7.1esr1 was rejected multiple times, because that is what I experienced and the reason I wrote "tried several times" in the description.

@jonas.smedegaard No, I mean the same file (without it being rebuilt) was apparently already uploaded and rejected before. Dak hashes the files to not process the same, already rejected upload multiple times (even if it has different names) - and to prevent people from just uploading the same thing over and over again.
That said, this case is really strange, as the upload actually wasn't known before, as far as I can see in the database.
I forced the package in now, it is available in the landing suite now (and will be built soon), but I'll keep an eye on this issue - could maybe be a bug in dak.

@mak: Failed again: "firefox-esr_60.7.0esr-1pureos4_source.changes is already known."

How do you mean the package was "indeed already known"? If you mean to say that you are certain that those releases had already been accepted preciously then what happened to them?

According to dak and the SHA256 hash of the package, the upload is indeed already known and would just be rejected again - can you rebuild the package again and do another upload?
TBH it is *really* weird that the package is rejected, as I would expect to find the originally rejected upload in the rejected queue, but that doesn't appear to be there.
So if your next upload doesn't succeed, let me know immediately! (I also made dak forget about the last upload attempt).

Yes, this is by design for extra security, as well as adding the convenience of not having to enter in unlock passphrases two different times at boot (once for /, once for swap). The downside is that it removes the ability to resume from hibernate.

I've not experienced any issues with recent updates, including update to cryptsetup packages.

Note see also https://tracker.pureos.net/T753

In the first case described here, updating grub (sudo update-grub) had no effect. Problem remains

I don't know for sure. I'm taking a look at them right now and have downloaded and updated here. I'll report my experience with the updates.

Can we assume that today's update (6/17) for the cryptsetup packages to 2.1.0-5 does not address this issue? I have marked all those as 'hold' for now.

The code excluded in the Debian package is a separate upstream project added by upstream as a convenience code copy.