@pebcak drew my attention to a misbehavior of the loader.conf. can you confirm if this is as intended as @pebcak described it or if another function is related to it.
This is how my loader.conf looks
default @saved
timeout 5
console-mode max
#reboot-for-bitlocker 1
I have commented out reboot-for-bitlocker and restarted several times without any problems. Could you explain the use of this entry?
Just for my general understanding.
Caveat: This feature is experimental, and is likely to be changed (or removed in its current form) in a future version of systemd.
Work around BitLocker requiring a recovery key when the boot loader was updated (disabled by default).
Try to detect BitLocker encrypted drives along with an active TPM. If both are found and Windows Boot Manager is selected in the boot menu, set the “BootNext” EFI variable and restart the system. The firmware will then start Windows Boot Manager directly, leaving the TPM PCRs in expected states so that Windows can unseal the encryption key. This allows systemd-boot(7) to be updated without having to provide the recovery key for BitLocker drive unlocking.
Note that the PCRs that Windows uses can be configured with the “Configure TPM platform validation profile for native UEFI firmware configurations” group policy under “Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption”. When Secure Boot is enabled, changing this to PCRs “0,2,7,11” should be safe. The TPM key protector needs to be removed and then added back for the PCRs on an already encrypted drive to change. If PCR 4 is not measured, this setting can be disabled to speed up booting into Windows.
the warning is also may simply false as many others showing several boot options “not found” etc…
But the entry simply will do nothing in case there is no bitlocker …
At any rates, if you guys have deemed it rather useful to have it than not, then so be it.
That would certainly cover some “edge use case” as I don’t think that there are a great many users using systemd-boot in a dualboot system with BitLocked Windows (speculating freely ).
Read further down in the section called “Device encryption”
Device encryption is a Windows feature that provides a simple way for some devices to enable BitLocker encryption automatically. Device encryption is available on all Windows versions
device encryption is enabled automatically so that the device is always protected
If that is being the case, it looks as if it contradicts the list of the Windows editions that supports BitLocker enablement in the table further up.
It’s a bit confusing but there seems to be a difference between Device Encryption and Bitlocker?
Difference between BitLocker and device encryption
Device encryption turns on BitLocker automatically on device encryption-qualifying devices, with the recovery key automatically backed up to Microsoft Entra ID, AD DS, or the user’s Microsoft account
Device encryption adds a device encryption setting in the Settings app, which can be used to turn device encryption on or off
You obviously don’t read a lot of Microsoft licensing documentation.
It is partially marketing and partially functionality gating but I think it is simplest to consider Device Encryption a limited forum of BitLocker’s encryption.
That is almost close to what I could make out of the article. While device encryption is available on all Windows editions, Bitlocker seems to be only available for the above mentioned editions.
Unlike a standard BitLocker implementation, device encryption is enabled automatically so that the device is always protected. When a clean installation of Windows is completed and the out-of-box experience is finished, the device is prepared for first use. As part of this preparation, device encryption is initialized on the OS drive and fixed data drives on the computer with a clear key that is the equivalent of standard BitLocker suspended state.
Whatever the “standard Bitlocker suspended state” means now
