Debian SBAT future updates
Posted: 2024-09-20 07:43
I don't use Windows at all, but on machines I maintain I use Ubuntu 20.04. It was up to date with shim-signed 15.7, and I hadn't yet installed the updated 15.8 as these are offline machines and we do the updates monthly. Each machine has two disks, each with Ubuntu 20 which is updated in the same way. So note; these are dual-boot machines, but Windows is not involved.
Because Ubuntu 20 is getting old, I wanted to try Debian so I booted the 12.7 ISO from the DVD. Unbeknownst to me, this updated the SBAT from shim 15.8. I discovered this when I tried to boot back into Ubuntu, which wouldn't boot because of the 'SBAT' issue, which despite long familiarising myself with Secure Boot, I had previously never heard of.
Firstly, despite the claims I've seen on this forum, it *is* possible that booting a Debian disk with an updated machine can prevent another OS from booting. Secondly this breakage is not 'fixable' in the BIOS settings (unlike, say, a DBX update) so can be difficult to resolve.
Secondly, it is clear from subsequent investigations that Debian's approach to this update has been different to Canonical's. After I fixed the issue with the test machines I set my mind to the task of updating the Ubuntu machines which I now knew were going to update the SBAT, which would prevent the other disk from booting and hence prevent me from updating that.
To my surprise however, whatever SBAT settings Canonical did, it did not stop the shim 15.7 from booting. Looking at mokutil, it does appear that Debian has done something different to what Canonical have done with Ubuntu.
Question 1: What happened? Why has Debian's SBAT update stopped shim 15.7 booting? What decision made this? It was clearly not replicated with Ubuntu.
Question 2: How will Debian handle this in the future? As you can imagine, as a Dual-booter, this will cause me a massive maintenance issues if I have to turn off secure boot (~30 machines, multiple disks, and turning off secure boot for an update inexplicably stops apt from signing kernel modules with the MOK, which is difficult to fix).
Because Ubuntu 20 is getting old, I wanted to try Debian so I booted the 12.7 ISO from the DVD. Unbeknownst to me, this updated the SBAT from shim 15.8. I discovered this when I tried to boot back into Ubuntu, which wouldn't boot because of the 'SBAT' issue, which despite long familiarising myself with Secure Boot, I had previously never heard of.
Firstly, despite the claims I've seen on this forum, it *is* possible that booting a Debian disk with an updated machine can prevent another OS from booting. Secondly this breakage is not 'fixable' in the BIOS settings (unlike, say, a DBX update) so can be difficult to resolve.
Secondly, it is clear from subsequent investigations that Debian's approach to this update has been different to Canonical's. After I fixed the issue with the test machines I set my mind to the task of updating the Ubuntu machines which I now knew were going to update the SBAT, which would prevent the other disk from booting and hence prevent me from updating that.
To my surprise however, whatever SBAT settings Canonical did, it did not stop the shim 15.7 from booting. Looking at mokutil, it does appear that Debian has done something different to what Canonical have done with Ubuntu.
Question 1: What happened? Why has Debian's SBAT update stopped shim 15.7 booting? What decision made this? It was clearly not replicated with Ubuntu.
Question 2: How will Debian handle this in the future? As you can imagine, as a Dual-booter, this will cause me a massive maintenance issues if I have to turn off secure boot (~30 machines, multiple disks, and turning off secure boot for an update inexplicably stops apt from signing kernel modules with the MOK, which is difficult to fix).