Reminds me when about ten years ago, working in an all-Linux company there was an issue with some Lenovo docking stations. I don't recall anymore what the issue was exactly, just that something wouldn't work properly when you plugged in a laptop with Linux. The problem was solved by a firmware upgrade, but upgrading the docking station firmware was possible only from Windows. So there was this one poor person in IT who had to install Windows on a spare laptop and then everyone would bring their docking station to them to upgrade the firmware...
That reminds me of an internal hard disk I had several years ago. I think it was a Seagate, but it might have been Western Digital. This was a retail drive bought at BestBuy, and the box specifically said that it worked with Windows, MacOS, and Linux, although it noted that their fancy add-on software only worked under Windows. No problem for me, because I didn't need the fancy add-on software.
A year later the drive developed some bad sectors. It was still under warranty so qualified for a free replacement. All I needed to do was get an RMA number and ship the drive to them.
But to get an RMA number you had to run their diagnostic software which, if it decided the drive really did have a problem, would issue the RMA number.
That diagnostic software was Windows only.
I ended up temporarily moving the drive to my Windows gaming box to run the diagnostic. I'm not sure what would have happened if I had been a purely MacOS and Linux household.
Hah, I know that pain. I'm optimistic about the future though. I recently installed Ubuntu on my new work laptop and soon after it offered to update the firmware of my Dell docking station. I was pleasantly surprised to see that.
Windows PE/To Go has been a thing for a while now, it's a shame you can only make bootable Windows USB disks using the enterprise editions. Though Macrium Reflect (and possibly others) will let you make a USB "recovery disk" that might run the firmware update programs you'd like to run.
I ran into that on my T470s. The last ThinkPad I've owned and likely will own, for a variety of reasons. I used to be a die-hard Thinkpad guy.
In my case, I was the only one in the company with a Thinkpad, so my process for upgrading the docking station firmware was:
"dd" off my drive to another box. "dd" on the copy of the disc I had saved when I got the computer. Boot it and set it up. Run all the updates. "dd" my drive image back onto the box.
The company I'm at now prefers buying Dell, but I had special requested that Thinkpad. It was kind of disappointing. It had two batteries, which made it slim, but sometimes one of them would be flaky. But not reliably flaky, so sometimes it'd just power off, but most of the time both batteries reported tons of life. And the docking station was basically useless (don't remember the issues, I just never was able to get a satisfactory docking experience from it). It had the ultra high res screen and that was nice.
> Reminds me when about ten years ago ... but upgrading the docking station firmware was possible only from Windows.
For me, it was less than 10 days ago. The battery on my Thinkpad X1 (that has 5 years onsite warranty) stopped charging. I run Debian, and had got rid of the Windows partition entirely. They demanded a battery report from Windows. It took a long time, but I was able to convince them the report from their extended battery test in the BIOS saying the battery had failed sufficed, and the battery was replaced.
The new battery lasted about 1 month, then it developed the same fault. Same story - after a day worth of arguing, they agreed to replace the battery.
That battery lasted 3 days, then developed the same fault. The story went the same way, right up until they said they fix it by replacing the battery to which I responded "I don't think that's a good idea". (By this time I had developed suspicion the USB-C chipset was somehow killing the battery.) The next step was to replace the motherboard until I filed a Windows battery report. No amount of pleading "hey, you have a report from your own BIOS saying the battery is faulty, it doesn't charge while in the BIOS when no OS is running, and it should charge while off when _nothing_ is running - what possible influence could Windows have on this" worked.
They sent a link me what they said was a "live Windows" USB recovery drive. It was a Windows program. I was able to run it Windows in an kvm instance. It wasn't "live Windows" of course - it was a "wipe SSD with a fresh install of Windows" USB. Not being keen on wiping all my work and risking a backup not working, I bought a new SSD, and let it wipe that. It took about a wasted day (I'm a contractor) to install Windows, let it upgrade itself, and then install the latest Lenovo drivers for everything (which they insisted on), then run the battery report. During the time the laptop started freezing - but it turned out unplugging the 4K USB-C Philips monitor fixed that, adding more evidence to my theory the USB-C interface was on the way out.
The motherboard is scheduled to be replaced today. I'm betting they won't bring a battery and replace the one the USB-C chipset has killed. They go to all this trouble to provide good diagnostics in the firmware, and then don't train their staff to use it. I'm sometimes gob smacked by just how much time these companies cost themselves.
I had run into the same problem with Kingston - no firmware on the web, update tool only for Windows. Had to ask local distributor to contact Kingston and ask for firmware. I was lucky to get it, but never bought another Kingston drive.
I don't understand how datacenter SSD manufacturer can so blatantly ignore Linux.
I agree. It is easy these days provided that your device is supported. I updated my ThinkPad nvme SSD (my model is from 2018) using the fwupdmgr command[0], which fetches supported firmware data from LVFS[1]. It improved temperature control for sure. So I would say it was worth it. But, as always, keep verified backups, just in case.
[0]: https://www.cyberciti.biz/faq/upgrade-update-samsung-ssd-fir...
[1]: https://lvfs.readthedocs.io/en/latest/
You ought to be able to flash the firmware on a mounted drive.
Anyone sane implementing the firmware flashing algorithm will either:
1. Just reject all IO requests from the point of the firmware update onwards. The system will see the drive disappear, but since you are using a journaling filesystem, it will be like you just pulled the power, and no data corruption will happen.
2. Complete all IO requests before the update, then update, then continue requests as before.
3. Save the firmware update, but only apply it at next powerup of the drive.
does that firmware update come with any changelog? I have the same drive for my database dev work and I somehow feel uneasy to update it without really knowing what will change, will my specific workload improve or tank due to some other edge case they might have solved or broken? I mean, the drive works fine, will it work even better? for what workloads exactly? All I could find was someone mentioning it works better in PS5. It's the same reason I don't update BIOS for my motherboad - it works and has been remarkably stable for over 5 years. Chances of me being pwned by APT using some BIOS vulnerability is less than be bricking mobo while updating it.
A quick search did not result in any official changelog, but some forum entries (e.g. [1] and [2]) suggest that random read + write performance under windows seems to have been improved.
Same situation here. Even a small risk of drive failure due to lack of experience with such systems is more than enough to keep me from giving it a try. If you can afford to lose the information on the drive though, might give it a go.
Is there any significant benefit of updating firmware? Intuitively it seems like the risk/reward is very skewed towards not doing it. I've never really updated the firmware on any component other than routers or motherboard/bios.
Sometimes an update just fixes some incompatibility with some specific hardware. If you are not using that hardware then there probably isn't much benefit from updating. Well, at least if you are either sure that you won't need to use that incompatible hardware later, or are sure that if you ever do need that hardware you will still be able to update.
Sometimes though an update fixes a more pressing defect. For example I updated the firmware on my Samsung 840 EVO drives several years ago because of this issue that caused significant performance degradation [1].
Another example is a firmware update I recently applied to my AKiTio Thunder3 Quad Mini Thunderbolt storage enclosure. The issue there was that when MacOS put drives to sleep occasionally the enclosure would report that the drive ejected. Getting the drive back seemed to require ejecting the other drives in the enclosure and then power cycling it.
This was annoying, but easy to work around by setting the OS to not put drives to sleep. All my drives were SSD so keeping them awake didn't use too much extra power. I ran like this while waiting for them to release a firmware update. After a couple years of waiting I stopped checking.
After a couple years or so of not checking, I remembered and checked and sure enough there was an update specifically for this issue. It was a bit of a pain because they had discontinued the Thunder3 Quad Mini a while back, and some time after that had stopped updating their firmware updater for it. It only ran on MacOS up through 10.15.7, and I was on 12.something.
I ended up using a USB SATA dock and an old spinning disk that was lying around to install MacOS 10.15.something on that and boot from it so I could run AKiTio's updater. Worked like a charm. It would have been a lot more annoying if I hadn't happened to have had the USB dock and old drive sitting around.
It looks like the author was mining a particular sort of cryptocurrency which needs a lot of drive space. I guess he was trying to squeeze as much performance out of his SSDs as possible.
For most applications I can't see why you'd really need to update your SSD firmware, unless the manufacturer messed up their wear-levelling or something like that in the release firmware.
As a software engineer myself, I would say yes, but I'm biased. I know no code is released perfect.
Then for something high performance like an NVM.e SSD, you could potentially gain a lot of performance, or lose it, depending on the manufacturer's goals for stability vs speed.
After a couple of decades of updating firmware on things whenever possible (including my car which had me leave the engine running sitting in the car with the window down for 2 hours in the winter), I'm yet to have a real issue.
That said, I also have the tools and skills to dump flash chips and would suggest doing that to anyone before an update of certain devices, or, you know, just don't do it, as you suggest.
I generally don't update firmware ever unless there is a problem. One exception is bios. Then if I have the occassional mysterious freeze/reboot I'll try it. Also if there is something like known ram size or particular hardware fix. But I can count those on 1 hand over 20 years. Also I suppose there are cases when you bought stuff just as it came out, there can be useful firmware updates after the first several months it is on the market.
Firmware bugs can shorten the lifespan or lower the speed of a drive. On the other hand, bugs can be introduced in new versions, and reverting to an old version is not always easy to do.
This is a very good take. I've seen products being bashed on because they don't push out regular updates. In my opinion, the less updates the software needs, the better it is.
I was confronted with this last Saturday and ended up following this how-to.
I simply couldn't believe that their tool required a PS/2 keyboard, when most modern Mainboards no longer have such a port.
In any case, updating the firmware didn't fix the issue that my 980 Pro NVMes (all 4 of them) only have a write speed of between 400 and 500 MB/s (read is at ~6.7 GB/s), using Ubuntu 20.04.
A WD_BLACK SN850 NVMe manages to write at 3.8 GB/s in the same slot (Ryzen 9 5950X on ASUS Pro WS X570-ACE)
BTW: I faced the same keyboard issue a month ago when I wanted to use another Samsung tool to erase a Evo 870 SSD for RMA with the Secure Erase feature.
> updating the firmware didn't fix the issue that my 980 Pro NVMes (all 4 of them) only have a write speed of ...
In order to see spec sheet read/write speeds you can/should bypass the filesystem and the buffer cache. On Linux you can write directly to the device node (make sure to enable O_DIRECT and make your write sizes big enough).
Maybe there's hope. I just got a regular 980 (not Pro) last week, which was showing around 660-680 MB/s write speed on both direct disk (and through file system). Just moments ago downloaded the new firmware and ran the installer, and suddenly: 1.8 GB/s on direct disk. I'm using dd if=/dev/zero of=/dev/nvme0n1 bs=1000M count=100 to test the direct access speed.
BTW, I followed the wget & cpio route from the how-to and ran the "fumagician" binary just fine on the headless box over ssh, no need to PS/2 anything.
It's too bad PCIe didn't define a firmware update mechanism, similar to how it defines Option ROMs. It would save manufacturers time and money if they didn't need bespoke firmware updaters.
Such a standard could define capabilities (firmware slots, online update, power cycle required, etc). The OS could handle it from that point.
This is unfortunate. Can't do simple things easily, or at all, unless you boot windows. My mouse looked like Christmas tree until I installed some electron app on windows.
There has to be a better way without the need to hack everything
I've ran a multitude of linux distro's on the 980, 860, and 860 pro for the last few years with no issues. 48 hours ago I finished buildning a Ryzen 5800x system on an ROG Strix B450-F motherboard and I've had no issues booting with the 980 & 860 Pro...860 Pro is a 2.5 SSD the rest are m2.
It could be that your ISO doesn't have the required drivers for the storage controller to see the actual SSD.
It's a pain that sysadmins knows all too well when deploying a corporate Windows image through SCCM/MECM, and why they need to often update the embedded drivers in the Preinstallation Environment.
95% of comments like these are from Windows users. Linux users generally know how to troubleshoot, fill out bug reports, come up with solutions(article is case in point), etc.
The much more likely reason is there is a Windows user in charge of the team. Someone who doesn't know what they don't know.
I have a PM9A3 U.2 drive, does anyone happen to know the update procedure on that thing? Everything Samsung when lifecycle handling seem like utter pain.
dvratil|4 years ago
tzs|4 years ago
A year later the drive developed some bad sectors. It was still under warranty so qualified for a free replacement. All I needed to do was get an RMA number and ship the drive to them.
But to get an RMA number you had to run their diagnostic software which, if it decided the drive really did have a problem, would issue the RMA number.
That diagnostic software was Windows only.
I ended up temporarily moving the drive to my Windows gaming box to run the diagnostic. I'm not sure what would have happened if I had been a purely MacOS and Linux household.
trulyrandom|4 years ago
ece|4 years ago
edit: Windows PE won't do .msi, but .exe should work: https://docs.microsoft.com/en-us/windows-hardware/manufactur...
trelane|4 years ago
linsomniac|4 years ago
In my case, I was the only one in the company with a Thinkpad, so my process for upgrading the docking station firmware was:
"dd" off my drive to another box. "dd" on the copy of the disc I had saved when I got the computer. Boot it and set it up. Run all the updates. "dd" my drive image back onto the box.
The company I'm at now prefers buying Dell, but I had special requested that Thinkpad. It was kind of disappointing. It had two batteries, which made it slim, but sometimes one of them would be flaky. But not reliably flaky, so sometimes it'd just power off, but most of the time both batteries reported tons of life. And the docking station was basically useless (don't remember the issues, I just never was able to get a satisfactory docking experience from it). It had the ultra high res screen and that was nice.
rstuart4133|4 years ago
For me, it was less than 10 days ago. The battery on my Thinkpad X1 (that has 5 years onsite warranty) stopped charging. I run Debian, and had got rid of the Windows partition entirely. They demanded a battery report from Windows. It took a long time, but I was able to convince them the report from their extended battery test in the BIOS saying the battery had failed sufficed, and the battery was replaced.
The new battery lasted about 1 month, then it developed the same fault. Same story - after a day worth of arguing, they agreed to replace the battery.
That battery lasted 3 days, then developed the same fault. The story went the same way, right up until they said they fix it by replacing the battery to which I responded "I don't think that's a good idea". (By this time I had developed suspicion the USB-C chipset was somehow killing the battery.) The next step was to replace the motherboard until I filed a Windows battery report. No amount of pleading "hey, you have a report from your own BIOS saying the battery is faulty, it doesn't charge while in the BIOS when no OS is running, and it should charge while off when _nothing_ is running - what possible influence could Windows have on this" worked.
They sent a link me what they said was a "live Windows" USB recovery drive. It was a Windows program. I was able to run it Windows in an kvm instance. It wasn't "live Windows" of course - it was a "wipe SSD with a fresh install of Windows" USB. Not being keen on wiping all my work and risking a backup not working, I bought a new SSD, and let it wipe that. It took about a wasted day (I'm a contractor) to install Windows, let it upgrade itself, and then install the latest Lenovo drivers for everything (which they insisted on), then run the battery report. During the time the laptop started freezing - but it turned out unplugging the 4K USB-C Philips monitor fixed that, adding more evidence to my theory the USB-C interface was on the way out.
The motherboard is scheduled to be replaced today. I'm betting they won't bring a battery and replace the one the USB-C chipset has killed. They go to all this trouble to provide good diagnostics in the firmware, and then don't train their staff to use it. I'm sometimes gob smacked by just how much time these companies cost themselves.
snvzz|4 years ago
Samsung is to blame for this.
[0]: https://fwupd.org/
ps|4 years ago
I don't understand how datacenter SSD manufacturer can so blatantly ignore Linux.
nixcraft|4 years ago
mkj|4 years ago
yrro|4 years ago
https://robots.org.uk/ToshibaX30X40FirmwareUpdate
ClumsyPilot|4 years ago
skrtskrt|4 years ago
ajb|4 years ago
Err no, that's when you boot from USB stick. Or do it from initramfs. Or anything, other than modifying the firmware of a drive you are running from.
5e92cb50239222b|4 years ago
londons_explore|4 years ago
Anyone sane implementing the firmware flashing algorithm will either:
1. Just reject all IO requests from the point of the firmware update onwards. The system will see the drive disappear, but since you are using a journaling filesystem, it will be like you just pulled the power, and no data corruption will happen.
2. Complete all IO requests before the update, then update, then continue requests as before.
3. Save the firmware update, but only apply it at next powerup of the drive.
merpkz|4 years ago
sirwitti|4 years ago
A quick search did not result in any official changelog, but some forum entries (e.g. [1] and [2]) suggest that random read + write performance under windows seems to have been improved.
[1] https://www.elevenforum.com/t/samsung-980-pro-firmware-updat...
[2] (in german) https://www.deskmodder.de/blog/2022/01/26/samsung-firmwareup...
ShamelessC|4 years ago
mariuolo|4 years ago
fareesh|4 years ago
tzs|4 years ago
Sometimes an update just fixes some incompatibility with some specific hardware. If you are not using that hardware then there probably isn't much benefit from updating. Well, at least if you are either sure that you won't need to use that incompatible hardware later, or are sure that if you ever do need that hardware you will still be able to update.
Sometimes though an update fixes a more pressing defect. For example I updated the firmware on my Samsung 840 EVO drives several years ago because of this issue that caused significant performance degradation [1].
Another example is a firmware update I recently applied to my AKiTio Thunder3 Quad Mini Thunderbolt storage enclosure. The issue there was that when MacOS put drives to sleep occasionally the enclosure would report that the drive ejected. Getting the drive back seemed to require ejecting the other drives in the enclosure and then power cycling it.
This was annoying, but easy to work around by setting the OS to not put drives to sleep. All my drives were SSD so keeping them awake didn't use too much extra power. I ran like this while waiting for them to release a firmware update. After a couple years of waiting I stopped checking.
After a couple years or so of not checking, I remembered and checked and sure enough there was an update specifically for this issue. It was a bit of a pain because they had discontinued the Thunder3 Quad Mini a while back, and some time after that had stopped updating their firmware updater for it. It only ran on MacOS up through 10.15.7, and I was on 12.something.
I ended up using a USB SATA dock and an old spinning disk that was lying around to install MacOS 10.15.something on that and boot from it so I could run AKiTio's updater. Worked like a charm. It would have been a lot more annoying if I hadn't happened to have had the USB dock and old drive sitting around.
[1] https://www.anandtech.com/show/9196/samsung-releases-second-...
topynate|4 years ago
For most applications I can't see why you'd really need to update your SSD firmware, unless the manufacturer messed up their wear-levelling or something like that in the release firmware.
alias_neo|4 years ago
Then for something high performance like an NVM.e SSD, you could potentially gain a lot of performance, or lose it, depending on the manufacturer's goals for stability vs speed.
After a couple of decades of updating firmware on things whenever possible (including my car which had me leave the engine running sitting in the car with the window down for 2 hours in the winter), I'm yet to have a real issue.
That said, I also have the tools and skills to dump flash chips and would suggest doing that to anyone before an update of certain devices, or, you know, just don't do it, as you suggest.
b112|4 years ago
There was even once a bug which, after X hours of SMART recorded usage, would cause the SSD to lockup every hour thereafter: https://www.reddit.com/r/buildapc/comments/oh18a/attention_c...
SSD firmware issues can be very serious.
stjohnswarts|4 years ago
2ion|4 years ago
In any case, I treat this as a high risk operation; no HDD/SSD firmware flashing without making sure the backup is working...
naoqj|4 years ago
dncornholio|4 years ago
qwertox|4 years ago
I simply couldn't believe that their tool required a PS/2 keyboard, when most modern Mainboards no longer have such a port.
In any case, updating the firmware didn't fix the issue that my 980 Pro NVMes (all 4 of them) only have a write speed of between 400 and 500 MB/s (read is at ~6.7 GB/s), using Ubuntu 20.04.
A WD_BLACK SN850 NVMe manages to write at 3.8 GB/s in the same slot (Ryzen 9 5950X on ASUS Pro WS X570-ACE)
BTW: I faced the same keyboard issue a month ago when I wanted to use another Samsung tool to erase a Evo 870 SSD for RMA with the Secure Erase feature.
wyldfire|4 years ago
In order to see spec sheet read/write speeds you can/should bypass the filesystem and the buffer cache. On Linux you can write directly to the device node (make sure to enable O_DIRECT and make your write sizes big enough).
EDIT: added a quote to clarify context
taneliv|4 years ago
BTW, I followed the wget & cpio route from the how-to and ran the "fumagician" binary just fine on the headless box over ssh, no need to PS/2 anything.
xenadu02|4 years ago
Such a standard could define capabilities (firmware slots, online update, power cycle required, etc). The OS could handle it from that point.
beebeepka|4 years ago
There has to be a better way without the need to hack everything
5e92cb50239222b|4 years ago
https://aur.archlinux.org/packages/samsung_magician-consumer...
There's still a better way where they do think so — "enterprise" SSDs:
https://aur.archlinux.org/packages/samsung-ssd-dc-toolkit
Vote with your pocket, support vendors that do care.
https://wiki.archlinux.org/title/Solid_state_drive#Firmware
steerablesafe|4 years ago
At least solaar exists for Logitech stuff. Too bad it's still not something Logitech provides, but the reverse engineering work of some volunteers.
https://pwr-solaar.github.io/Solaar/
anaganisk|4 years ago
shmerl|4 years ago
https://wiki.archlinux.org/title/Solid_state_drive/NVMe#Gene...
It worked for me with SK Hynix Gold.
2b|4 years ago
brycemice|4 years ago
5e92cb50239222b|4 years ago
> No supported SSD detected for Firmware Update
It also doesn't work if you flash the ISO and boot "properly" as Samsung expects you to do.
m-p-3|4 years ago
It's a pain that sysadmins knows all too well when deploying a corporate Windows image through SCCM/MECM, and why they need to often update the embedded drivers in the Preinstallation Environment.
kasabali|4 years ago
ysleepy|4 years ago
I get why samsung doesn't want to get sucked into this. It does suck though, at least the ISO should work.
SixDouble5321|4 years ago
The much more likely reason is there is a Windows user in charge of the team. Someone who doesn't know what they don't know.
anthk|4 years ago
tonoto|4 years ago
Heston|4 years ago
caycep|4 years ago
stjohnswarts|4 years ago
bit_flip|4 years ago
shmerl|4 years ago