Lenovo To Make Their BIOS/UEFI Updates Easier For Linux Users Via LVFS

[Schugy]

Thanks for the news. My Ideapad G50-45 that was once sold with FreeDOS will never get Spectre and Meltdown fixes then.
Vendor: LENOVO Version: A2CN23WW(V1.05) Release Date: 07/08/2014

I used the pre installed FreeDos and h2offt-d.exe.
h2offt-d.exe Win213.bin -all -bios
That was surprisingly easy. Now dmidecode|head -n 37 shows Version: A2CN45WW(V2.13).

[edwaleni]

As all things opensource, this happens mostly when someone actually posts a bug report and/or contributes code, I'm sure that for a random cheap device you probably won't do that, but people trying to get powerful or decent laptops to work with Linux will want to do that. https://01.org/linux-acpi/documentation/patch-flow

As long as it isn't totally "panics on boot"-grade fucked up, anyway.

Well, blow me down. There was a BIOS update for my el cheapo Lenovo out on the support site. Came out in April 2018.

Effect? The ACPI boot errors are now gone. I am stunned.

[starshipeleven]

Very good. That is exactly what I see. ACPI alerts.

As all things opensource, this happens mostly when someone actually posts a bug report and/or contributes code, I'm sure that for a random cheap device you probably won't do that, but people trying to get powerful or decent laptops to work with Linux will want to do that. https://01.org/linux-acpi/documentation/patch-flow

As long as it isn't totally "panics on boot"-grade fucked up, anyway.

[edwaleni]

ACPI bugs can be "fixed" by linux kernel by working around it. That's most of the job of the ACPI maintainer, see and integrate all various dumb workarounds for dumb ACPI bugs and stuff.

Very good. That is exactly what I see. ACPI alerts.

[starshipeleven]

I didn't see boot alerts on it until the kernel reached 4.10 and I know that will never get fixed.

ACPI bugs can be "fixed" by linux kernel by working around it. That's most of the job of the ACPI maintainer, see and integrate all various dumb workarounds for dumb ACPI bugs and stuff.

[edwaleni]

All normal distros load updated CPU microcodes on boot if available, and the G50-45 is using an AMD processor so it is not affected by Meltdown.

Besides, it's a sub-500$ laptop, you should be already be happy that they didn't fuck up the firmware so bad that Linux kernel panics on boot (as happens way too frequently with HP laptops nowadays).

EDIT: for the sake of making it more clear, I mean that unless you are using a nutjob distro your laptop will be OK even if the board firmware will never be upgraded again.

(As far as Meltdown/Spectre) I don't think a sub $500 Lenovo is a vector for anybody, especially one running Linux as it represents 0.1% of the models' user type. Now, Windows, that is a different story.

My sub $200 Lenovo running Linux will never see a BIOS update as it was made for Lenovo under contract. I didn't see boot alerts on it until the kernel reached 4.10 and I know that will never get fixed. If I had a $1500 HP Elite Book and Linux refused to boot or had a lot of panics, I would probably see it differently or buy something else.

[pal666]

Hmm, pretty much no package/application that's available in distro repos is distro specific, what makes this special? There are also already plenty of binary/blob packages available.

all packages in distro repos are distro specific. maybe source tarballs were not specific, but they are not in the repos(directly)

[pal666]

Are they even trustworthy? They injected spyware / malware in their UEFI blobs in the past. Their hardware is nice, but their firmware is trash.

but you are already running their trash spyware/malware from factory, just more buggy and less secure than current update

[starshipeleven]

Hmm, pretty much no package/application that's available in distro repos is distro specific,

Yeah, let's ignore the fact that they were compiled from source with specific library versions found in specific places, a specific compiler version and (for more important programs) with downstream distro-specific patches.

More often than not this means that they will break or at least be unstable if you try to use a distro's binary in a different distro, as the actual compiled binary shipped by the distro isn't really exactly the same as the one shipped by another.

Say using a Ubuntu binary on Arch, or vice-versa.

Why you think Flatpack and Snap packaged applications are a thing? Because they allow to install applications that don't have these limitations and can be installed/updated reagrdless of what the rest of the distro is doing. And of course they come from repositories that are not controlled by your distro's maintainers (which is the whole point).

what makes this special?

Already said. Having each distro deal with "packaging" hundreds of firmwares (basically just wrapping the blob in a package) for random devices would be duplication of effort for no good reason.

It's the same exact stuff that comes from hardware vendors, and has exactly 0 need to interact with the rest of the OS as it's just downloaded by the tool, checked and then sent to the UEFI board firmware for processing, unlike other blobs shipped with the distro (see below) that need to actually be integrated with the distro itself.

There are also already plenty of binary/blob packages available.

And all those shipped by the distro have customized installation scripts/tools to install them properly, as the distro are different and the blob alone does not work if it is in the wrong place.

For example, the firmware blobs loaded at runtime from Linux-firmware https://git.kernel.org/pub/scm/linux...ware.git/tree/ upstream repo will have to be placed in different path depending on what path the distro uses for storing firmware blobs loaded by the kernel.

[aaahaaap]

Because it's managing firmware that is not distro-specific as it is using standard UEFI interfaces to install it, and is also a blob.

There is little reason to have it go through the usual packaging and testing and QA of each distro.

Hmm, pretty much no package/application that's available in distro repos is distro specific, what makes this special? There are also already plenty of binary/blob packages available.