https://bugs.kde.org/show_bug.cgi?id=521329
John <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #6 from John <[email protected]> --- I have booted into the firmware and the UEFI firmware capsule updates were enabled (checkbox ticked), so that was not a problem! I had 2 boot options named somehting like this: debian UEFI: SSD-name, partition one (which should be the EFI partition that is mounted into /boot/efi The strange part is that debian is not also listed as UEFI: debian! As I think that is the default boot option that is booting into and I think I had Ventoy in UEFI mode and Debian showed something like "UEFI Debian installer". Since I'm not sure anymore I din't change anything there and after going out I used to one-time boot menu to boot the second option, with the UEFI: prefix 3 things I noticed to be different now: 1. Bluetooth mouse not working anymore as Bluetooth was off. 2. No more updates in Discover, so the whole KEK CA is missing now after checking for updates. This command: 'df /sys/firmware/efi/efivars' has this output: Filesystem 1K-blocks Used Available Use% Mounted on efivarfs 384 217 163 58% /sys/firmware/efi/efivars -------------------------------------------------------------------------------------------------- So the used space seems to have increased from 50% to 58%. the 'sudo fwupdmgr get-updates' now says that the system is already using the latest updates: Devices with no available firmware updates: • KEK CA • Key Exchange Key • Option ROM UEFI CA • SBAT • ST1000LM035-1RK172 • UEFI DB • WD Blue SN570 1TB • Windows Production PCA Devices with the latest available firmware version: • System Firmware • UEFI CA • UEFI dbx No updates available --------------------------------------------------- Which I guess is the reason why Discover is not showing any more updates There is also this related bug report, with various solutions and workarounds, including resetting the firmware to defaults: https://github.com/fwupd/fwupd/issues/5643 In my case, I think I did enough by sending them those reports and by booting in what seems to be the real UEFI mode. Since this one-time boot in the UEFI: SSD+partition 1 entry seems to be the real one and Discover +fwupdmgr doesn't show this update anymore, I will just uncheck the 'debian' entry and leave only this one. Secure boot for some reason doesn't work even though on another computer it works. As for KDE software, my only wish would be that Info Center -> About this system, would also show the status of UEFI mode and of SecureBoot so we know immediately that that the installation silently failed to proceed how we wanted to, like in my case with both UEFI and SecureBoot active. These are really hard to spot. Now, after creating partitions, tweaking configs, installing programs, it's too late to try to reinstall the OS more properly. If you also think that is a good idea to see if UEFI and SecureBoot is active in the Info Center I can create a feature request for that and even do some investigation on how that could be detected. Just let me know! And thank you very much for everything! -- You are receiving this mail because: You are watching all bug changes.
