apt VS fwupd

And if that's not enough, you yourself seem to have been responsible that exactly this change was added to apt. If I may refresh your memory: https://github.com/pop-os/apt/pull/1 It even links to upstream Debian work mentioning exactly this method: https://salsa.debian.org/apt-team/apt/-/merge_requests/196

And no matter how hard it is, if it's possible to break it, someone will find their way to completely breaking the system. Look at what Linus had to do to break his Pop!_OS install - go to the terminal (which already renders it far out of reach for the average user), run sudo apt install steam, and ignore a giant error. And that wouldn't work anymore anyway, because Pop now uses a version of APT that completely forbids breaking the system unless specifically configured to allow it - so there is now an extra step in there, telling APT not to preserve pop-desktop.

This isn't locking it down. This is about providing sensible defaults like I mentioned before. For power users, the control is still there. It's easy enough to create the `/etc/apt/break-my-system` file so that you can shoot yourself in the foot if you wanted to. This is not similar to what ChromeOS or Android is doing at all.

ah, I thought you mean https://github.com/pop-os/apt/pull/1

- Improve the GUI package manager error message: https://github.com/pop-os/shop/pull/302 - Make the apt message more explicit and make the bypass much harder: https://github.com/pop-os/apt/pull/1

https://github.com/pop-os/apt/pull/1/files Here is the code change. Note line 311.

They have already committed a fix that improves things dramatically.

And they already issued a "fix" to prevent people to easily "break" it.

And their fix for the issue Linus had is downstream only. Not a word said about working with Debian on this.

UEFI firmware can not be updated in legacy BIOS modeSee https://github.com/fwupd/fwupd/wiki/PluginFlag:legacy-bios for more information.Use fwupdmgr --help for help

A similar bug, but featuring a different file and checksum, from today.

The more user-friendly distros have support for updating the UEFI secure boot dbx (forbidden binaries) database via fwupd, but due to the circumstances around this update, they currently don't/don't do it correctly. MS isn't doing it automatically themselves yet either so we're not any worse off. There's an open issue around handling this. I suspect it'll take a couple of months before this to-be-written support finds its way into distros. It's complex, annoying and the result of it going wrong is a system that can't boot Windows and can't boot from preexisting Windows recovery media. Distros will want to be very careful with it. I suspect they'll roll it out in stages with single-boot systems getting patched first and possibly interactive user confirmation.

Use fwupd

These updates are coming from fwupd and LVFS. The frontend is Gnome Software. Lenovo is pushing their firmware updates to LVFS, so you're updating with vendor code. Its a lot like getting device drivers and what-not through Windows Update.

More here u/CornFlakes1991 please report the issue

-> # fwupdmgr update WARNING: UEFI ESP partition not detected or configured See https://github.com/fwupd/fwupd/wiki/PluginFlag:esp-not-found for more information. Devices with no available firmware updates: • USB3.0 Hub • Samsung SSD 860 EVO 250GB • USB2.0 Hub • Unifying Receiver Devices with the latest available firmware version: • SKHynix • UEFI dbx

Related issue: https://github.com/fwupd/fwupd/issues/5477

Would be good to put some pressure on them to use this.