[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian live boot corrupting secure boot



On Wed, 27 Sep 2023 09:54:31 +0700 Max Nikulin <manikulin@gmail.com> wrote:
I found the issue on latest versions of Clonezilla, but then I tried
                       ^^^^^^

    with plain Debian live and the behavior is the same.


Does it mean that you can not boot your *old* Clonezilla live after booting a latest Clonezilla? If so, it is better to discuss the issue with shim or grub developers.

Yes. If I load a Clonezilla live newer than 3.1.0-11, then I cannot boot anymore 2.8.1-12.


1) Machine brand new: secure boot is active, Windows 10 shows it active, I can boot an old Clonezilla live (2.8.1-12) as many times as I want.
An old image may be signed by a key later added to certificate revocation lists. If so, secure boot just works as it is supposed to do.

I didn't consider that... But it makes sense.

    2) I boot from USB drive Debian Live 12
    https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.1.0-amd64-kde.iso


If it can be reproduced with a contemporary Clonezilla or e.g. a Fedora image then it is not a Debian issue. If it is specific to namely Debian (I am unsure concerning Ubuntu, Debian derivatives) then it is better to file a bug providing more details.

As I said, the image that is not loaded anymore is older Clonezilla.
The image that alters secure boot is newer Clonezilla, and then I found that newer Debian does the same. I still haven't found an old version of Debian that cannot boot after newer one (but I only tried 10 live, so far).

    4) I reflash BIOS, same version, and go to point 1.


How old is your BIOS? Maybe you just restore obsolete list signing of keys.

Perhaps... I have no option during reflash.

BIOS has 9 month. One month ago a new version has been released: some day ago I installed it but it behaves just like the previous.

I suggest to compare

    efibootmgr -v

output in the state when Clonezilla may be booted and when it fails. In addition public keys and certificate revocation list should be compared (unsure concerning commands).

I'll try as soon as I have another identical machine.

My opinion is that just loading boot images without installing OS should not modify firmware state. In this sense it may be a bug.

Not only I didn't install any OS, I didn't boot any image. It's enough to reach first page (grub entries) and the damage is done.

On the other hand, forgot old images if you have secure boot enabled.

Or forget the new ones ;-)


Reply to: