This announcement confuses me, since I've been flashing UEFI firmware on linux-based Dell, HP, and IBM servers for many years. IBM's tools are particularly pleasant, since they're easy to integrate into configuration management tools.
I presume the "natively" here means that the Linux kernel has been taught how to do this, rather than some tooling written by the OEM being responsible for it.
Like the difference between installing the VMWare Toolbox on a Linux guest (which builds and injects proprietary kernel modules written by VMWare), vs. using open-vm-tools, whose modules live in the kernel tree to begin with and are maintained by the kernel devs.
AFAIK updating server firmware under Linux has been possible for years, so I'm curious why this required a kernel update, a bunch of new packages, and fixing hundreds of bugs. Is this a case of the standard way being 10x more complex than the proprietary way?
The new standard way is supposed to be used by all vendors, instead of a slightly different proprietary method separately maintained by each. So you'll have the usual "design by committee, with all committee members being direct rivals" bloat.
And it seems that this is one of the first actual hardware implementations of said method; the OS-side software implementation has so far only been tested against emulators. It's not that surprising to see bugs here.
And even when it wasn't possible, it was either done through IPMI web UI, through BIOS being able to do it itself off a fat32 file system mounted anywhere (including IPMI fake drives), or a bootable DOS-based CD (which also can be booted via ISO fed to IPMI).
Disclaimer: I run a medium sized dedicated server host. Hi.
What are those green ports on the back? They look like power supply connectors. Does this require an external PS? I clicked around on the page you referenced and didn't see anything that explained it.
We have like 5 of these in the office. They have like 20 ports on them. I have no idea what the majority of them do. I assume most of them are some specialized binary data transport that I've never used or seen, though I have some weird half memory of similar ports on an early 90s IBM PC.
But that's not really flashing under Linux is it? That just sticking the file somewhere their non-linux flash tool can see. Not saying that it's not helpful to be able to do so, it does remove Windows from the equation (did it myself just last night as it happens).
The UEFI approach also isn't "flashing under Linux". It's "Stash a UEFI capsule somewhere into RAM, suspend, have UEFI update itself on wake-up before returning control to the OS"
Now, having the firmware run a seldomly used code path on resume sounds scary to me: That _must_ be accompanied with some OS-level check (eg hashing) that the firmware didn't touch any memory that it didn't originally reserve.
Luckily Windows is doing that, so Linux can ride the coattail again (as is usual with Intel-originated firmware standards) - except if Windows is guaranteeing some unused memory, because then, some UEFI implementation exploit that, inadvertently breaking things on Linux (yet again).
> But that's not really flashing under Linux is it?
Indeed not. But if we are going to nitpick, my first question would be what value does being able to flash new firmware from inside Linux achieve compared to what we have today: a OS-agnostic bootable update-medium?
Oy vey folks, why not Google LVFS to see why it's interesting.
There's a new CLI tool and dbus api for discovering and installing firmware updates that are securely hosted by redhat. There is also native support in GNOME Software for surfacing the updates and making them available.
This means on a Dell server, you literally type: `fwupdmgr update` and all possible firmware is updated.
So literally every comment in the thread so far is missing the point. This doesn't require shelling in, putting it in the UEFI partition, orchestrating your infrastructure to reboot the servers into the EFI partition to install and then let it reboot back to Linux. You just type `fwupdmgr update`.
Even Dell's iDRAC server management cards don't allow for firmware upgrades this simple. You'll need their layers of additional (paid) management software to update firmware without having to manually download it from their website.
