coreos / bootupd

Bootloader updater
Apache License 2.0
132 stars 26 forks source link

Cleanup `shimx64-fedora.efi` from adopted installations (was: Can't upgrade UEFI dbx from 77 to 371) #784

Open Verhoeckx opened 1 week ago

Verhoeckx commented 1 week ago

Hello bootupd developers,


When I run

fwupdmgr update

and try to upgrade UEFI dbx from 77 to 371

╔══════════════════════════════════════════════════════════════════════════════╗
║ Upgrade UEFI dbx from 77 to 371?                                             ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ Insecure versions of the Microsoft Windows boot manager affected by Black    ║
║ Lotus were added to the list of forbidden signatures due to a discovered     ║
║ security problem.This updates the dbx to the latest release from Microsoft.  ║
║                                                                              ║
║ Before installing the update, fwupd will check for any affected executables  ║
║ in the ESP and will refuse to update if it finds any boot binaries signed    ║
║ with any of the forbidden signatures.Applying this update may also cause     ║
║ some Windows install media to not start correctly.                           ║
║                                                                              ║
╚══════════════════════════════════════════════════════════════════════════════╝
Perform operation? [Y|n]: Y

I get the following error message:

Decompressing…           [                                       ]
Blocked executable in the ESP, ensure grub and shim are up to date: /boot/efi/EFI/fedora/shimx64-fedora.efi Authenticode checksum [0ce02100f67c7ef85f4eed368f02bf7092380a3c23ca91fd7f19430d94b00c19] is present in dbx

This even after I upgraded the system today and bootupd 0.2.25-1.fc41 got installed.


rpm-ostree status

● fedora:fedora/41/x86_64/silverblue
                  Version: 41.20241130.0 (2024-11-30T01:11:46Z)
               BaseCommit: 71b49b45ef9ed102aed5a48e5d20be664e00fe38893d6e2a39cb8e360a1fe206
             GPGSignature: Valid signature by 466CF2D8B60BC3057AA9453ED0622462E99D6AD1
          LayeredPackages: gnome-tweaks google-tinos-fonts rpmfusion-free-release rpmfusion-nonfree-release VirtualBox
            LocalPackages: Publii-0.46.1-1.x86_64 uld-1.00.39.12-2.fc38.x86_64

lsblk

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
zram0       252:0    0     8G  0 disk [SWAP]
nvme0n1     259:0    0 476,9G  0 disk 
├─nvme0n1p1 259:1    0   600M  0 part /boot/efi
├─nvme0n1p2 259:2    0     1G  0 part /boot
└─nvme0n1p3 259:3    0 475,4G  0 part /var/home
                                      /var
                                      /sysroot/ostree/deploy/fedora/var
                                      /usr
                                      /etc
                                      /
                                      /sysroot


Let me know if you need the output of other commands!

HuijingHei commented 1 week ago

Assume you update bootupd to 0.2.25-1.fc41.x86_64 and reboot. Then you should update shim by running bootupctl update, then run fwupdmgr update to see if the issue is fixed.

~Also find another workaround: https://github.com/fedora-silverblue/issue-tracker/issues/120#issuecomment-1177515110~

travier commented 1 week ago

/boot/efi/EFI/fedora/shimx64-fedora.efi is the old name for the shim binary from previous Fedora releases.

Can you give us the output of the commands below:

$ efibootmgr
$ efibootmgr | grep fedora

If /boot/efi/EFI/fedora/shimx64-fedora.efi is not listed there then it should be safe to remove. If it is, then it means that we need to figure out how to update it as well, even though it's not provided by the new Fedora releases.

If we want to remove it from the ESP via an update then we would have to figure out if it is still in use first.

travier commented 1 week ago

Also find another workaround: fedora-silverblue/issue-tracker#120 (comment)

Let's not link to this anymore as it should not be needed now that we have bootupd.

Verhoeckx commented 1 week ago

@travier: below is the output of the commands you mentioned.

efibootmgr

BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0002,0000,0001
Boot0000  ubuntu    HD(1,GPT,3ae827cd-dec6-4958-841b-b74df0a02e3c,0x800,0x186000)/\EFI\ubuntu\shimx64.efi
Boot0001* Linux Firmware Updater    HD(1,GPT,3ae827cd-dec6-4958-841b-b74df0a02e3c,0x800,0x12c000)/\EFI\fedora\fwupdx64.efi
Boot0002* Fedora    HD(1,GPT,3ae827cd-dec6-4958-841b-b74df0a02e3c,0x800,0x12c000)/\EFI\fedora\shimx64.efi


efibootmgr | grep fedora

Boot0001* Linux Firmware Updater    HD(1,GPT,3ae827cd-dec6-4958-841b-b74df0a02e3c,0x800,0x12c000)/\EFI\fedora\fwupdx64.efi
Boot0002* Fedora    HD(1,GPT,3ae827cd-dec6-4958-841b-b74df0a02e3c,0x800,0x12c000)/\EFI\fedora\shimx64.efi


I didn't completely understand your previous comment, so I don't know what my next step should be. Let me know if you need more information about my system.

HuijingHei commented 1 week ago

If /boot/efi/EFI/fedora/shimx64-fedora.efi is not listed there then it should be safe to remove.

According to Timothée's comment and your efibootmgr result, seems shimx64-fedora.efi is not used any more, so it can be safe to remove.

I don't know what my next step should be

Before doing the remove, could you help to run bootupctl update (assuming you have bootupd-0.2.25-1) to update grub2 and shim, then run fwupdmgr update to see if the issue is fixed? Thanks!

travier commented 1 week ago

Can you give us the listing for /boot/efi/EFI?

$ sudo ls -alRh /boot/efi

Thanks

travier commented 1 week ago

I didn't completely understand your previous comment, so I don't know what my next step should be. Let me know if you need more information about my system.

I've updated my previous comment to fix a wrong negation in the sentence.

Once we've confirmed the content of the ESP using the command above, the next step would be to remove the offending binary:

$ sudo rm /boot/efi/EFI/fedora/shimx64-fedora.efi

You should then be able to update the dbx.

Verhoeckx commented 1 week ago

Hello @HuijingHei and @travier,


This is what I did (in chronological order):


sudo ls -alRh /boot/efi

/boot/efi:
total 12K
drwx------. 3 root root 4,0K  1 jan  1970 .
drwxr-xr-x. 7 root root 4,0K 30 nov 15:26 ..
drwx------. 5 root root 4,0K 30 nov 15:26 EFI

/boot/efi/EFI:
total 20K
drwx------. 5 root root 4,0K 30 nov 15:26 .
drwx------. 3 root root 4,0K  1 jan  1970 ..
drwx------. 2 root root 4,0K 28 nov 14:00 BOOT
drwx------. 4 root root 4,0K 12 nov 14:05 Dell
drwx------. 4 root root 4,0K 30 nov 15:26 fedora

/boot/efi/EFI/BOOT:
total 1,0M
drwx------. 2 root root 4,0K 28 nov 14:00 .
drwx------. 5 root root 4,0K 30 nov 15:26 ..
-rwx------. 1 root root 928K 28 nov 14:00 BOOTX64.EFI
-rwx------. 1 root root  86K 28 nov 14:00 fbx64.efi

/boot/efi/EFI/Dell:
total 16K
drwx------. 4 root root 4,0K 12 nov 14:05 .
drwx------. 5 root root 4,0K 30 nov 15:26 ..
drwx------. 3 root root 4,0K  9 nov  2023 Bios
drwx------. 2 root root 4,0K 12 nov 14:05 logs

/boot/efi/EFI/Dell/Bios:
total 12K
drwx------. 3 root root 4,0K  9 nov  2023 .
drwx------. 4 root root 4,0K 12 nov 14:05 ..
drwx------. 2 root root 4,0K  9 nov  2023 Recovery

/boot/efi/EFI/Dell/Bios/Recovery:
total 37M
drwx------. 2 root root 4,0K  9 nov  2023 .
drwx------. 3 root root 4,0K  9 nov  2023 ..
-rwx------. 1 root root  19M  9 nov  2023 BIOS_CUR.RCV
-rwx------. 1 root root  19M 11 aug  2023 BIOS_PRE.rcv

/boot/efi/EFI/Dell/logs:
total 16K
drwx------. 2 root root 4,0K 12 nov 14:05 .
drwx------. 4 root root 4,0K 12 nov 14:05 ..
-rwx------. 1 root root  734 12 nov 14:05 diags_current.xml
-rwx------. 1 root root  745 12 nov 14:05 diags_previous.xml

/boot/efi/EFI/fedora:
total 11M
drwx------. 4 root root 4,0K 30 nov 15:26 .
drwx------. 5 root root 4,0K 30 nov 15:26 ..
-rwx------. 1 root root  110 11 sep  2022 BOOTX64.CSV
drwx------. 2 root root 4,0K 11 sep  2022 fonts
drwx------. 2 root root 4,0K  9 nov  2023 fw
-rwx------. 1 root root  60K  1 jan  1980 fwupdx64.efi
-rwx------. 1 root root  144 11 sep  2022 grub.cfg
-rwx------. 1 root root 2,9M 30 nov 15:26 grubia32.efi
-rwx------. 1 root root 3,9M 30 nov 15:26 grubx64.efi
-rwx------. 1 root root 829K 28 nov 14:00 mmx64.efi
-rwx------. 1 root root 928K 28 nov 14:00 shim.efi
-rwx------. 1 root root 928K 28 nov 14:00 shimx64.efi
-rwx------. 1 root root 1,2M 11 sep  2022 shimx64-fedora.efi

/boot/efi/EFI/fedora/fonts:
total 8,0K
drwx------. 2 root root 4,0K 11 sep  2022 .
drwx------. 4 root root 4,0K 30 nov 15:26 ..

/boot/efi/EFI/fedora/fw:
total 8,0K
drwx------. 2 root root 4,0K  9 nov  2023 .
drwx------. 4 root root 4,0K 30 nov 15:26 ..


rpm -qi bootupd

Name        : bootupd
Version     : 0.2.25
Release     : 1.fc41
Architecture: x86_64
Install Date: za 30 nov 2024 02:05:09 CET


bootupctl update

Running as unit: bootupd.service
No update available for any component.


fwupdmgr update

Blocked executable in the ESP, ensure grub and shim are up to date: /boot/efi/EFI/fedora/shimx64-fedora.efi Authenticode checksum [0ce02100f67c7ef85f4eed368f02bf7092380a3c23ca91fd7f19430d94b00c19] is present in dbx


Remove shimx64-fedora.efi

sudo rm /boot/efi/EFI/fedora/shimx64-fedora.efi


fwupdmgr update

Successfully installed firmware


Reboot the system

reboot


Firmware is updated & message in GNOME Software is gone :partying_face: !


So in summary: the problem was that fwupdmgr update checked a file that shouldn't exist any more (and the question if it can be safely removed or not)?


Thanks for all the help and hopefully it also helped you in stabilizing bootupd!

HuijingHei commented 1 week ago

Thanks @travier for the nice instruction, also thanks @Verhoeckx for the testing!

Close this as the issue is resolved.

travier commented 5 days ago

Given that this file is likely to be present on old installations of Fedora, we might want to special case it and remove it if we can verify that it's safe by checking the boot entries. Let's keep this open for now and we'll see if we can get to it.

HuijingHei commented 5 days ago

Given that this file is likely to be present on old installations of Fedora, we might want to special case it and remove it if we can verify that it's safe by checking the boot entries.

Sorry that close this a I thought it is triggered by fwupdmgr update, it should be fwupdmgr care about it. But agree that can do something from bootupd.