Nope, not my department, that's @MrChromebox

I am fairly sure this has been fixed. @MrChromebox ?

Nope, this is Coreboot, so if at all then @MrChromebox

This has been addressed in the Librem14 but we will not retr-fix this for the older L13 or L15, I'm afraid. Closing.

That's four years old, I am fairly sure this has long been resolved.

Hmm... sounds a tad expensive to me? Are the other servers located at Hetzner still? Then having storage within their net will be way faster and they also offer pure storage boxes:

Something like this maybe:

This IIRC does not work with the Librem laptops since these do not measure the energy properly, instead just estimate based on discharge rate. And even if, it is really rough (even Thinkpads do a pretty bad job at it).

Do you have an AC power meter? That's what I used... let the system sit there idle, battery fully charged, look at power consumption. Then just change _one_ thing at a time, let it settle and become idle again, measure again.

That's a matter for the sys team. We would need to know how much more space would be needed, how much is available at the hosting site right now and if we require more, how much extra cost this would involve. If this is a matter of just reconfiguring something then sys team can handle this, if it requires something that increases cost please let me know the amount and I will try to get the budget.

Oh good!
Or also not so good, because then I wonder what people do with their laptops not getting more battery life... hmm...

@jeremiah.foster @mak Can you look into this?

@jeremiah.foster Can you please help with this?

This is getting weirder and weirder, just tried the same USB stick on a L15V4 I got in hands and it also does not detect the 4k@30Hz which makes me start to believe it is not software (i.e. PureOS) related. Need to investigate more.

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.

That's what I wrote?
This is not Coreboot, it is a PureOS 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)

That's pretty interesting!
It might even be that the "firmware" actually isn't real firmware but rather a set of config options. I have seen something like this for CSR based Bluetooth chips too. The settings would then also control the WiFi/Bluetooth coexistence which is probably the reason why it does not work w/o the blob in the Librems - the antenna switch does not switch it to the Bluetooth chip without it and thus the BT does not "see" any other devices around.
According to kernel sources our device is a
/* Atheros AR3012 with sflash firmware*/
The firmware it loads consists of two parts:
ramps_0x11020100_40.dfu
and
AthrBT_0x11020100.dfu
The "ramps" file is sysconfig the second is a RAM patch file for the in chip flash firmware.

Actually it is not the driver that is missing but a free firmware for the AR3k Bluetooth chip used.
You can see the failed firmware load attempt in the kenel messages:

Well, I can not say for all combinations but I have M.2 SATA + 2.5" SATA in my L13. In Seabios the M.2 SATA preceeds the 2.5" SATA drive, in Linux the 2.5" SSD becomes sda and the M.2 SATA ssd becomes sdb, this is what dmesg says:

The order that Linux detects the devices is also the other way araound, i.e. the M.2 becomes, if present, sda and the 2.5" SATA becomes sdb if M.2 is present. This should, if possible, also be reflected in Coreoot/Seabios. It is confusing when the first detected Coreboot/Seabios disk becomes the second one in Linux.