This solves such an important need, updating device firmware and bios’ was such a pain for the longest time, most manufacturers tend to give out only Windows executables- if you are lucky then some DOS compatible binary might be included, and then you could boot into FreeDOS.
BIOS's got better about reading their own firmware from VFAT, but still getting the driver was a pain, because there was a strong preference for .exe's on websites.
Seems much better now, I can run a small handful of commands and have my bios updated. It's still hard to know which motherboards/laptops are compatible with fwupd though.
It didn't just happen. Richard Hughes works with loads of different companies and gets them to provide the updates in the right format to work with LVFS, no easy task at all.
LVFS seems to be focusing mostly on laptop hardware, isn’t it? I am currently looking into building a Linux-based gaming PC in the near future, and none of the major motherboard manufacturers appear to be posting the BIOS updates there.
Am I missing anything? This is the first new PC I’m building in over a decade, so I’m not fully up to speed with all the latest developments
> As usual, I wanted to check if any firmware update is available
Updating HDD firmware is something you do to resolve a very specific problem, not ... just because it's available. People are blind to the fact that updates can and do introduce new bugs.
> Updating HDD firmware is something you do to resolve a very specific problem, not ... just because it's available.
It is important to check if there is an update and what has been fixed. Like with any software, it may introduce new bugs, but blindly suggesting to "not touch, if it's not broken" is harmful too. Some time ago Samsung rolled out SSDs that were self-destructing after very short period of time and fixed this in firmware. If your SSD breaks or start having problems it is already too late to update, you have to be proactive. And hardware vendors doesn't release firmware updates for nothing, in most cases there is very good reason for that.
That wasn't an actual "fix", it was just a workaround --- the flash they were using was far too leaky and lost its charge very quickly, so they decided to have the firmware constantly rewrite in the background. Even the updated firmware won't help for machines that are powered off for months at a time.
I think the manufacturers needed no encouragement, and at this point it would take multi-national intervention to get the genie back in the bottle. The poster you replied to simply recognized the situation for what it is: Samsung is still a going concern after releasing SSDs with firmware that would brick them after a relatively short service lifespan.
Just checking for updates is fine, actually installing every single firmware versions is bad.
This is because embedded firmware are less moving parts more tightly packed, which makes their failure modes inevitably catastrophic; they're incapable of progressively degrading like Electron apps, but the whole system always spontaneously crash into the wall and die from just one typo, and you don't want that.
It depends on what is in the changelog. If there are performance or durability improvements, you might want to change the firmware even if you are not facing a significant issue. The downside is the risk to data on the disk - don't do that (or anything, really) on a drive that holds the only copy of something important.
If the drive is being moved to a different array or machine and the data is to be lost anyway, the risk is very low and, if the process is easy (unlike this) it might be a sensible move.
I agree "just because it's new" is a poor justification to risk data.
More often than not, the changelog just states "performance improvement" or "bug fix", without any detail on what they've done.
For example, I've been bitten before by Dell due to plundervolt updates that removed the undervolting capability under the umbrella of "security fixes".
They can but the data on the chip is a combination of machine specific identifiers, config data, and BIOS code. If you chip flash it you have to get an image from some sketchy place and it will nuke your serial number etc. You can also have problems if your RAM is made by a different manufacturer. Chip flashing is a last resort.
HP has a bootable Linux CD that updates all the firmware on their devices, since the early 00's. We used to regularly update firmware across our entire fleet of servers during maintenance cycles. Never had a failure.
Well it is nice to stay current with the news about your harddrive. Wheren't there are some point some SSD from Intel or Samsung that would eventually brick themselves unless you applied some firmware?
I remember having patched some SSDs for this very reason the last time I worked on on premise bare metal systems.
A year or two after that I had an M4 that after a certain period of uptime would just stop responding to commands, thus acting like a dead drive until power cycled (a reboot was not enough). There was of course a fw update available and it did fix it, although I don't recall it being listed in the changelog.
It killed a whole fleet of processing unit in our lab back then which had been all put in service at the same time, ran 24/7 and then failed all within the same night.
> Wheren't there are some point some SSD [...] would eventually brick themselves unless you applied some firmware?
Yeah, that was a thing with older enterprise SAS SSDs a few years ago. HP, Dell, Lenovo, Cisco, etc, all affected as they all rebadge the available hardware manufacturer's drives. And several manufacturers have had bricking-firmware problems over the years.
number of personal and servers HDD firmware upgraded over three decades: a couple thousand.
Our storage systems at work regularly ship firmware updates with bugfixes. I have never seen a FW update introduce new bugs. But of course there has been the occasional HDD that didn't spin up during the (required) power cycle
It's just software like any other. It's vulnerable and it has defects. So it's very reasonable to at least check if there's an update available.
> People are blind to the fact that updates can and do introduce new bugs.
I do agree that this fact is often underappreciated - the single biggest cause of breakages are usually the rollout of changes themselves. But again, it's just like with any other software.
changelogs are generally useless and manufacturers hate having to release firmware updates, so the mere existence of an update is pretty strong evidence there's something seriously wrong
it's not like web or app dev where you can ship trivial upgrades every day for free
Case in point: We update the HDDs and SSDs on our storage systems regularly. Every month there's new disk drive firmware coming out for various (OEM) drives.
I have never seen a disk fw update introduce new bugs. Firmware development works quite a bit differently than regular software development. There's usually no new "feature" that can possibly be added to a disk drive. It's not like you're suddenly getting a new desktop environment on it.
But yeah, I have seen a handful of HDDs die during the mandatory power cycle because they wouldn't spin back up. And sometimes, disks fail at a higher rate after the firmware update, but that is not due to introduced bugs but rather because the error detection/reporting functionality has improved and is now reporting issues that it didn't before. For enterprise storage systems that is actually a good thing, because a predicted failure is always better than a sudden failure.
Case in point: A few years ago, the HGST Cobra drives were leaking fluid from the motor onto the platters. There was nothing that could be done, so the firmware was updated to move the heads more (to prevent fluid buildup) and the error detection was changed to detect the slowed head movement and report that via sense codes. Of course that caused more early failures, but that's better than having a handful disks fail all at once, and the disks would have failed anyway at some point.
Documentation of this seems to have disappeared into the ether, but I'm reminded of the time that glxgears (or a distro package of it?) briefly turned off FPS output by default, with the argument to turn it on being something like --i-acknowledge-that-this-tool-is-not-a-benchmark
Basically, people were complaining about "major regressions" in glxgears frame rates that were really just minor fluctuations in how long it took to clear and swap buffers, since glxgears does almost no actual rendering (by modern standards).
> The first one gives us our answer: the URL is stored in the registry. It’s actually written by the InstallShield setup.
I... I mean, I get why they did this, rather than building a proper userspace application... but who the fuck thought this would be something that's acceptable to ship to consumers? And what happens in case there are multiple different disk models installed in the same system?
If I understand it correctly, the URL lets you download a file that maps every Toshiba disk model to a firmware version (???). So having different disk models doesn’t change anything, the program just gets the file, checks which drive needs which version, and then downloads these firmware binaries and installs them.
They might just as well send any other .reg file that runs a program (e.g. by creating an autoboot entry, COM server, service, ...) that bricks devices.
I like that the author went very in depth reverse engineering the proprietary update program, but it boiled down to what amounts to a single or few ata commands that can be manually invoked on linux. it's a shame they don't just publish these commands for linux users, and let the windows users have the fancy bespoke tools.
>What’s interesting is the checksum at the end. It’s the CRC32 of the file, minus the last 10 bytes, which can be easily checked with the slice and crc32 tools of my hacking Swiss army knife rsbkb:
I want to know the story of how he realized it was the CRC of the file minus the last 10 bytes. That's gotta be an interesting thought path.
