Package: asahi-scripts Version: 20250130-3 Severity: important Tags: upstream fixed-upstream trixie forky sid X-Debbugs-Cc: [email protected]
Dear Maintainer, update-m1n1 is not idempotent: if executed twice, it will happily create a new boot binary, replace the old boot binary (/boot/efi/m1n1/boot.bin.old) with the current one (/boot/efi/m1n1/boot.bin) and then move the new boot binary to the path of the current one (/boot/efi/m1n1/boot.bin) without checking if the new binary is the same as the current one. This breaks the fundamental safeguard of making sure the current boot binary is always different from the old one. A real-life scenario where this can cause breakage is after kernel updates. Suppose one has kernel version A and B installed, A < B, and call A and B the boot binaries that update-m1n1 generated starting from the respective DTBs, A: /boot/efi/m1n1/boot.bin.old B: /boot/efi/m1n1/boot.bin When the user updates to kernel version C, a new boot binary is generated and we are left with B: /boot/efi/m1n1/boot.bin.old C: /boot/efi/m1n1/boot.bin If the user now removes kernel version A, update-m1n1 is called again and we are left with C: /boot/efi/m1n1/boot.bin.old C: /boot/efi/m1n1/boot.bin which are the same binary. If kernel version C is broken for some reason, and 1. the breakage also affects the DTBS, or 2. the DTBs in C and kernel B are incompatible, then the user won't be able to revert to using kernel B and/or boot binary B. If update-m1n1 were idempotent (i.e. if it checked that the new boot binary is different from the current one before doing the replacements), it would be impossible to end up in this situation. Cheers!
