Loader.conf reboot-for-bitlocker

@manuel @joekamprad @dalto @Bryanpwo

I had described my problem in this thread.

@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.

I dug a bit further and found:


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.

Added in version 251.

source: https://www.freedesktop.org/software/systemd/man/latest/loader.conf.html

You had this in the journal:

It might be that it has been removed as implied in the quote above. Not sure why EnOS has it in the loader.conf.

Since it is already commented out (disabled by default), I would say it is safe to remove it altogether.

You aren’t even using Windows with BitLocker on your system, are you?

PS. I was wrong about the lack of reference in man loader.conf. I overlooked it at a first glance. It is there as well: man loader.conf


indeed if you do not use bitlocker you do not need that… simple as this… it is a general support feature …

I only use eos.

That’s why i wanted to ask the developers :wink:

Quite a lot of knowledge that I have acquired today. I have no idea about it, it’s way beyond my horizon

Simple answer to a simple question. A thousand thanks Joe :handshake: :enos:

If `reboot-for-bitlocker’ is already set to be enabled in loder.conf, is there an explanation for why the line not being recognized?

Perhaps it has only bearing when a Windows system with BitLocker is present and then there will be no entry in the journal :thinking:

Because it is harmless if you don’t need it, but if you do need it, it is important.

To be clear, it is not being recognized by “systemd-logind”. I am not sure why that reads loader.conf.

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 …

Yes, that was a bit surprising.

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 :wink:).

Windows uses bitlocker by default now, doesn’t it?

Not the Home edition, it seems:

The following table lists the Windows editions that support BitLocker enablement:

Windows Pro Windows Enterprise Windows Pro Education/SE Windows Education
Yes Yes Yes Yes


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. :rofl:

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.

Certainly not :rofl:

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 :wink:

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.