In data lunedì 27 maggio 2024 22:20:56 CEST, Stakanov ha scritto:
The system in question suddenly displays Blocked executable in the ESP, ensure grub and shim are up to date: /boot/efi/ EFI/grub/shim.efi Authenticode checksum [be435df7cd28aa2a7c8db4fc8173475b77e5abf392f76b7c76fa3f698cb71a9a] is present in dbx
I found that it is possible that this happens if another OS was installed before, but that was not the case here.
Anybody has a suggestion why this could happen?
Systemstructure is quite standard: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 119,2G 0 disk ├─sda1 │ 8:1 0 501M 0 part /boot/efi ├─sda2 │ 8:2 0 4G 0 part [SWAP] └─sda3 8:3 0 114,8G 0 part /var /tmp /usr/local /root /srv /opt /boot/grub2/x86_64-efi /boot/grub2/i386-pc /.snapshots / sdb 8:16 0 931,5G 0 disk └─sdb1 │ 8:17 0 931,5G 0 part └─md127 9:127 0 931,5G 0 raid1 /home sdc 8:32 0 931,5G 0 disk └─sdc1 │ 8:33 0 931,5G 0 part └─md127 9:127 0 931,5G 0 raid1 /home sdd 8:48 1 0B 0 disk sde 8:64 1 0B 0 disk sdf 8:80 1 0B 0 disk sdg 8:96 1 0B 0 disk sr0 11:0 1 1024M 0 rom
Is this a known issue with a grub update? I thought it would apply only to fwupd? Is it save to proceed to update the system anyway? Can I force grub to update, how would I do this?
The system is not under my hand so answers may take some time, currently the user is online.
Thank you
These kind of error messages I face them too on my system (but related to two Python nitrokey issue and it seems that this because the flatpack repo was active (which I deactivated now in Discovery). I did the update on the system (or made it do) with zypper dup and the whole process did run well, did not through errors. I have the impression that the integration of zypper and discovery is not really so smooth. Maybe better to switch back to pure zypper driven updates. Personally I think discovery is uttermost slow.