Am 26.07.23 um 18:00 schrieb Chris Adams:
Once upon a time, Solomon Peachy <pizza@xxxxxxxxxxxx> said:
None of the other SSDs I have deployed (Samsung and Crucual SATA) are
updatable via LVFS, unfortunately. But, hilariously, both Samsung and
Crucial's official updaters appear to be self-contained linux ISOs. So
clearly the technical capability is there...
The difference is often the update method. fwupd supports a specific
standard way of applying firmware updates, but often things use very
proprietary methods. Some storage may not support applying updates
while be accessed for example (so have to boot from ISO/etc. to apply
while unmounted).
While there's a standard for updating UEFI firmware, lots of
motherboards still use older custom methods. Also, many are unable to
carry over config properly, so they reset all settings on a firmware
update (which is problematic and arguably a reason for making it harder
to do). I think most of the systems I've used that support fwupd UEFI
updates are able to do so without a config reset.
Which... having to have a config reset on a firmware update in this day
is so dumb. Very rarely do config options change (and even then, it is
typically "new options added", not old options changed), so there's
really no excuse for not storing the config in a forward-compatible way
and restoring those settings after a firmware update. Dell PowerEdge
servers have managed this for years, why can't they apply it to
everything?
And also, why can't Dell get PowerEdge updates into LVFS? :)
While reading this discussion, I tried it on my local Dell XPS and
was surprised that LVFS suggests a firmware update (bios) for my
model (it says that I'm 4 versions behind), albeit on Dell's support
page such updates are not listed (here I would have already the latest).
Not sure about the integrity / quality of the uploads to LVFS??
Does anyone know how to compare the artifacts on LVFS (.cab) with
the ones on Dell's support page (.exe, .rcv)?
--
Leon
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
