I've tried reducing the QHD refresh rate from 60Hz to 50hz and this has been quite stable so far. Fingers crossed...

I've got my new monitor (a Dell U2719DC) and I've been able to reproduce the blanking issue reliably. I think your correspondent is correct that it's related to performance.

Ran GNOME OEM on my LMv1 and GNOME Live on L15v4:

This fixes it for upgrading Ubuntu as well from 18.04 to 20.04. Thank you so much.

I am also having this issue after trying the dd and Gnome Disks method. Both the January version of PureOS as well as the version from last night are not detected by the BIOS. On the other hand, I can boot live Debian and Trisquel just fine.

Nice! If nobody vetoes this image until next Monday/Tuesday, I will send this image to the factory and marketing people - we really have to update the default image, and especially that OEM username issue is causing very frequent support issues, so it has to go (not to mention the huge amount of security fixes that newer PureOS releases contain and that just aren't there yet with the current images).

I'll be able to test this next saturday

The image has been updated to incorporate the latest security fixed for a bunch of vulnerabilities in GRUB (less relevant for us if /boot is verified anyway, but still good to have, especially for custom installations).

This should have been resolved with the latest util-linux upload.

At some point the intent is to make this nicer-looking and better integrated, but until that point is there, we'll have this page :-)

They were signed with an expired key. refreshging that key from a keyserver fixed this issue.

Thanks!

https://master.pureos.net/raw/web/new.html

https://software.pureos.net/package/bin/byzantium/libglib2.0-0 currently says "This package is currently not installable!"

And a follow up. When the disk has partitions on it, the installer won't allow you to select 'Erase Disk'. I have to install gparted to delete the partitions before the 'Erase Disk' option is available. Don't know if this is a bug or on purpose.

@mak Tested 2020-07-22 OEM on my Librem Mini. It installs and boots just fine!

@all but especially @richard.kolla : Can you please test the 2020-07-22 image? There were now functional changes, only minor bugfixes from Debian and security fixes (so I expect everything to still work as before).

In T919#17068, @richard.kolla wrote:

[...]

Does the OEM initial setup work as expected?

Won't boot.

Any noticeable bugs/regressions?

I erase the disk, install on my SATA SSD with the bootloader going to the MBR of the same drive. Can't boot from the coreboot 4.12-2 boot menu. Will need to confirm with Carlsbad what settings they use when installing PureOS OEM and use those same settings to test.

OEM GNOME

Does the image boot cleanly?

Yes

Does the OEM installer work?

Seems to

Does the OEM initial setup work as expected?

Won't boot.

Any noticeable bugs/regressions?

I erase the disk, install on my SATA SSD with the bootloader going to the MBR of the same drive. Can't boot from the coreboot 4.12-2 boot menu. Will need to confirm with Carlsbad what settings they use when installing PureOS OEM and use those same settings to test.

But the Live image and the Plasma image still need testing

@mak I tested GNOME OEM https://downloads.pureos.net/amber/oem/gnome/2020-07-18/ on baremetal

Is this not something that can also be pushed to upstream g-i-s

This has been fixed in PureOS for some time now

This has been fixed in PureOS for some time now, but we'll still need an upstream solution. I'll likely push this change to Debian as well meanwhile, so Debian can benefit from the bugfix as well.

Tried it on Byzantium this morning, here's what I got: