VeraCrypt chainloading fails from GRUB and systemd-boot — works only from UEFI directly

[El Don]

I have a dual boot setup with Windows 11 encrypted with veracrypt (VeraCrypt 1.26.24 full system encryption) and Fedora 44 on a Lenovo laptop with NVMe drive.

Problem:
After entering the correct password, VeraCrypt decrypts successfully but then freezes or reboots back to the bootloader instead of booting Windows.

What works:

1. Booting VeraCrypt directly from UEFI boot menu works perfectly every time
2. Running efibootmgr --bootnext <windows-entry>in fedora then reboot works perfectly

What fails:
GRUB chainloading reboots back to GRUB
Same thing for systemd-boot on openSUSE Tumbleweed
Both fail regardless of distro or bootloader

Already tried:

1. SettingActionSuccess=bootnext=<windows-entry> in DcsProp
2. Renaming bootmgfw.efi to bootmgfw_ms.eft and setting ActionSuccess=postexec file(EFI\Microsoft\Boot\bootmgfw_ms.efi)
3. Moving ActionSuccess config option to be the first config in DcsProp
4. Fresh Windows + VeraCrypt install
5. Fresh Fedora 44 install
6. openSUSE Tumbleweed with systemd-boot
7. BIOS update
8. GRUB reinstall

Key observation:
This worked perfectly on Arch Linux, Fedora 42 and 43 with the same hardware. Stopped working after upgrading to Fedora 44 around April 2026. However since systemd-boot on a completely different distro also fails, it may not be a GRUB/Fedora issue at all.

System:
Lenovo laptop, NVMe SSD
VeraCrypt 1.26.24
Secure Boot enabled
UEFI firmware updated to latest (2024)
Fedora 44, GRUB 2.12-56

Any help appreciated. Happy to provide any additional logs or config files.

[Mounir IDRASSI]

Thank you for the detailed report.

A first important point: ActionSuccess=bootnext=<windows-entry> is not a valid DCS action, so this setting will currently have no effect. The valid action keywords are exit, postexec, exec, halt, shutdown and reboot.

Since authentication succeeds and the problem happens only after the handoff to Windows Boot Manager, this looks specific to the EFI chainloading environment created by GRUB/systemd-boot, not to password verification or decryption itself. Direct firmware boot and efibootmgr --bootnext working is an important clue: it means the VeraCrypt bootloader works when started by the firmware boot manager, but something changes when it is first loaded by another EFI bootloader.

Please provide the following so I can narrow this down:

1. The full content of EFI\VeraCrypt\DcsProp
2. The exact GRUB/systemd-boot entry used to chainload VeraCrypt
3. Output of efibootmgr -v
4. Whether EFI\VeraCrypt\DcsBml.dcs exists on the ESP
5. A test result with Secure Boot temporarily disabled

Also, does the machine really reboots, or it freezes/hangs on a VeraCrypt status/error screen?

For diagnosis, you can also try changing the success action to something like:

ActionSuccess=postexec printinfo delay(10) file(EFI\Microsoft\Boot\bootmgfw_ms.vc)

This should pause long enough to see whether DCS reaches the post-auth execution path and which action is being processed.

For now, the reliable workaround is to keep using the firmware boot entry directly, or use efibootmgr --bootnext <VeraCrypt-entry> from Linux before rebooting. That path avoids the extra EFI state left by GRUB/systemd-boot.

Anyway, this looks like a DCS handoff/chainloading issue. The likely area is the post-auth path where DcsBoot reconnects EFI controllers and starts bootmgfw, possibly interacting badly with the EFI handle/protocol state created by recent GRUB/systemd-boot/shim versions.

[El Don]

Thank you for the detailed response. Here are the results of all the tests:

1. DcsProp content (current)

<?xml version="1.0" encoding="utf-8"?>
<VeraCrypt>
    <configuration>
        <config key="PasswordType">0</config>
        <config key="PasswordMsg">Password: </config>
        <config key="PasswordPicture">login.bmp</config>
        <config key="HashMsg">(0) TEST ALL (1) SHA512 (2) WHIRLPOOL (3) SHA256 (4) BLAKE2S (5) STREEBOG
Hash: </config>
        <config key="Hash">1</config>
        <config key="HashRqt">0</config>
        <config key="PimMsg">PIM (Leave empty for default): </config>
        <config key="Pim">0</config>
        <config key="PimRqt">1</config>
        <config key="AuthorizeVisible">0</config>
        <config key="AuthorizeRetry">10</config>
        <config key="DcsBmlLockFlags">0</config>
        <config key="DcsBmlDriver">0</config>
        <config key="ActionSuccess"></config>
    </configuration>
</VeraCrypt>

2. GRUB chainload entry (from os-prober)

menuentry 'Windows Boot Manager (on /dev/nvme0n1p1)' --class windows --class os {
    savedefault
    insmod part_gpt
    insmod fat
    search --no-floppy --fs-uuid --set=root F22B-496F
    chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

3. efibootmgr -v output

BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,DC5B,0003,0000,2001,2002,2003
Boot0000* Windows Boot Manager → \EFI\Microsoft\Boot\bootmgfw.efi
Boot0001* Fedora → \EFI\fedora\shimx64.efi
Boot0003* Fedora → \EFI\fedora\shim.efi
BootDC5B* VeraCrypt BootLoader (DcsBoot) → \EFI\VeraCrypt\DcsBoot.efi

4. DcsBml.dcs Does not exist.

5. Secure Boot test results

With Secure Boot DISABLED + empty ActionSuccess:

• Windows boots successfully from GRUB ✓
• However after Windows boots, VeraCrypt hijacks the boot order, making Fedora only accessible via the UEFI boot menu. Selecting the Fedora entry from UEFI shows the GRUB menu correctly.

With Secure Boot DISABLED + ActionSuccess=postexec printinfo delay(10) file(EFI\Microsoft\Boot\bootmgfw_ms.vc):

• Countdown is visible on screen
• After countdown completes, screen goes black briefly
• Reboots back to VeraCrypt password prompt
• Same behavior with Secure Boot ON

6. Failure behavior (Secure Boot ON, empty ActionSuccess)

• Screen turns off for less than a second after correct password
• Reboots back to GRUB menu
• After repeated failed boot attempts, Windows Automatic Repair starts but freezes on "Preparing Automatic Repair" unless power button is pressed

[Mounir IDRASSI]

Thank you for the detailed test results.

This rules out the DcsBml/BootNext locking hypothesis I had in mind.

The most important result is that GRUB chainloading works when Secure Boot is disabled, but fails when Secure Boot is enabled. I suspect a Secure Boot chainloading issue after VeraCrypt authentication when DcsBoot starts the original Microsoft loader (bootmgfw_ms.vc) from a GRUB environment.

It would be helpful if you could proceed with one more test: please create a manual GRUB entry that chainloads VeraCrypt directly:

menuentry 'VeraCrypt direct DcsBoot' {
insmod part_gpt
insmod fat
search --no-floppy --fs-uuid --set=root F22B-496F
chainloader /EFI/VeraCrypt/DcsBoot.efi
}

Then test it with Secure Boot enabled.

If this works, the issue is specific to chainloading through /EFI/Microsoft/Boot/bootmgfw.efi.
If it still fails, then the issue is generic to Secure Boot + GRUB/shim chainloading of DCS.

Regarding the boot order change after Windows starts: this is Windows-side VeraCrypt bootloader protection/repair logic. You can control it from VeraCrypt EFI bootloader settings, using the options related to automatically fixing boot configuration and forcing the VeraCrypt entry to be first in the firmware boot menu.

[El Don]

Thank you for the suggestion.
I actually tried this exact entry at the beginning of the troubleshooting, The result is the same — password accepted, screen goes black for less than a second, reboots back to GRUB.
Based on your diagnostic statement, this confirms the issue is generic to Secure Boot + GRUB/shim chainloading.

[Mounir IDRASSI]

Thank you, this confirms that the failure is generic to Secure Boot + GRUB chainloading of DCS.

Can you please provide the exact package versions:

rpm -q shim-x64 grub2-efi-x64 grub2-common
mokutil --sb-state

I will look at the DCS bootloader handoff path, especially how the final Windows loader is started after DcsInt installs the block I/O hook. The issue appears to be in that Secure Boot chainloaded handoff.

[El Don]

Thank you again,
Package versions:

shim-x64-16.1-5.x86_64
grub2-efi-x64-2.12-58.fc44.x86_64
grub2-common-2.12-58.fc44.noarch
SecureBoot: enabled

Also worth noting, a potentially related issue was filed last week on rhboot/shim — issue #795 — reporting that Fedora 44's shim-x64-16.1-5 ships with IMAGE_DLLCHARACTERISTICS_NX_COMPAT not set on all shim binaries, which specifically affects Lenovo hardware. This may be related to the broken EFI state during DCS chainloading under Secure Boot.

[Mounir IDRASSI]

Thank you. This is very useful information!

The rhboot/shim issue #795 may indeed be related, especially given the Lenovo angle, but I would not conclude yet that NX_COMPAT itself is the direct cause. The stronger technical lead is that shim 16.1 changed the execution environment: shim now installs its own LoadImage/StartImage/UnloadImage/Exit handlers in the EFI system table.

DCS uses LoadImage/StartImage when it hands off to the original Microsoft Windows loader after authentication. So when DCS is started through shim/GRUB with Secure Boot enabled, the final Windows handoff is going through shim wrapped loader path, not the same firmware path used when BootDC5B is selected directly by the firmware.

That matches your test matrix:

• firmware -> VeraCrypt -> Windows: works
• GRUB/shim -> VeraCrypt -> Windows with Secure Boot disabled: works
• GRUB/shim -> VeraCrypt -> Windows with Secure Boot enabled: fails

This is clearly a shim 16.1 / Secure Boot loader-protocol interaction with DCS final handoff to Windows Boot Manager.

I will investigate whether DCS can detect this shim-loaded environment and whether the final Windows handoff issue can be solved.

[El Don]

Thank you for investigating this. I will wait for a fix, In the meantime I will use the UEFI boot menu to boot Windows directly.