ZL

Too bad, "dude", that you didn't specify at the beginning that you only use Windows. My mistake was assuming without asking that you use Linux. Now it turns out that most of my writing is unnecessary. Windows (in my opinion) probably approaches this issue differently. Good luck.

Let's clarify the description. Are we understanding each other correctly? I understand your problem like this: 1) There is a computer with a Linux system (+ Windows) running on the hard drive in the computer. Everything is fine. 2) One day you insert a USB stick with another Linux system (in this case it is Clonzilla) into the USB. You start this computer from this USB stick. Everything is fine. 3) You finish working with the system on USB. You turn off the computer. You disconnect the USB stick...

Let's clarify the description. Are we understanding each other correctly? I understand your problem like this: 1. There is a computer with a Linux system (+ Windows) running on the hard drive in the computer. Everything is fine. One day you insert a USB stick with another Linux system (in this case it is Clonzilla) into the USB. You start this computer from this USB stick. Everything is fine. You finish working with the system on USB. You turn off the computer. You disconnect the USB stick from the...

Since I wrote the previous post in a hurry, here are some details. Point 1. shim packages in Debian Testing: shim-helpers-amd64-signed 1+15.7+1 shim-signed:amd64 1.40+15.7-1 shim-signed-common 1.40+15.7-1 shim-unsigned 15.7-1 Point 2. shim packages in Debian sid (these versions break older ones): shim-helpers-amd64-signed 1+15.8+1 shim-signed:amd64 1.44+15.8-1 shim-signed-common 1.44+15.8-1 shim-unsigned:amd64 15.8-1 Point 3. Clonezilla versions (according to the file on the CD: /live/filesystem.packages):...

I understand you. Universal advice: don't panic, take a break to cool down. In Linux, everything can be fixed. I was helpless, too, when I saw a black screen with this sign and my computer shut down after a few seconds. The only thing to do then is to disable Secure Boot. You can always boot with Secure Boot disabled - Linux will boot correctly. I don't know what effect this has on Winows 10/11. Besides, you are not alone - the developers of Clonezilla are smarter than the two of us and will surely...

@KC You need to boot twice using the latest shim version (the one that broke this, no need to download anything new): Disable Secure Boot Boot the system with the latest shim and issue the command mokutil --set-sbat-policy delete as root Reboot the system with the latest shim, because now the entries will be undone. Now turn off the computer, enable SecureBoot and it should be fine. Hide the USB with the latest shim deep in a drawer.

I thought I was the only one having this problem. This is the fault of the 'shim' packages from the 'sid' branch. They increase the shim numbers unnecessarily and that is why older versions of shim cannot start and print "Verifying shim SBAT data failed: Security Policy Violation". I think these four 'sid' shim packages were too hastily included in Clonezilla and are breaking other shims. Take a look: https://en.opensuse.org/openSUSE:UEFI#Reset_SBAT_string_for_booting_to_old_shim_in_old_Leap_image...

@KC You need to boot the system twice with the latest shim (the one that broke, no need to download anything new): 1. Disable Secure Boot 2. Boot the system with the latest shim and issue the command mokutil --set-sbat-policy delete as root 3. Reboot the system with the latest shim, because now the entries will be undone. 4. Now turn off the computer, enable SecureBoot and it should be fine. Hide the USB with the latest shim deep in a drawer.