Windows dual boot documentation? #427

Open
opened 2025-01-21 19:32:59 +00:00 by pshirshov · 12 comments
pshirshov commented 2025-01-21 19:32:59 +00:00 (Migrated from github.com)

It seems like it's currently impossible to configure a host for dual-boot in declarative manner.

Maybe I'm wrong, but from what I can see one has to manually sign the ed2k shell and add a regular entry through boot.loader.systemd-boot.windows.

It would be awesome to have some blessed approach to dual boot described in the docs.

It seems like it's currently impossible to configure a host for dual-boot in declarative manner. Maybe I'm wrong, but from what I can see one has to manually sign the ed2k shell and add a regular entry through `boot.loader.systemd-boot.windows`. It would be awesome to have some blessed approach to dual boot described in the docs.
RaitoBezarius commented 2025-01-21 23:39:53 +00:00 (Migrated from github.com)

I think you only need to keep Microsoft keys and let systemd-boot know about Windows via the magic reboot into Windows option and that's it?

You don't need to do anything and you must not boot Windows via systemd-boot otherwise you will mess your measurement path and if you are using anything like Bitlocker, this will trigger a recovery prompt on boot because the measurement path is incorrect.

I think you only need to keep Microsoft keys and let systemd-boot know about Windows via the magic reboot into Windows option and that's it? You don't need to do anything and you must not boot Windows via systemd-boot otherwise you will mess your measurement path and if you are using anything like Bitlocker, this will trigger a recovery prompt on boot because the measurement path is incorrect.
pshirshov commented 2025-01-25 00:50:18 +00:00 (Migrated from github.com)

Well, reboot to windows works but I would really like to have an option to boot through systemd-boot menu. So, essentially, it's not possible at all?

measurement path

But from what I can see, if I sign the uefi shell and boot through it, I only have to enter bitlocker key once.

In any case, it would be good to have this documented.

Well, reboot to windows works but I would really like to have an option to boot through systemd-boot menu. So, essentially, it's not possible at all? > measurement path But from what I can see, if I sign the uefi shell and boot through it, I only have to enter bitlocker key once. In any case, it would be good to have this documented.
RaitoBezarius commented 2025-01-25 19:27:33 +00:00 (Migrated from github.com)

Well, reboot to windows works but I would really like to have an option to boot through systemd-boot menu. So, essentially, it's not possible at all?

I'm not sure systemd-boot gives us easy way to do this and we will probably not support super advanced modifications that diverges too much from what systemd encourages.

measurement path

But from what I can see, if I sign the uefi shell and boot through it, I only have to enter bitlocker key once.

In any case, it would be good to have this documented.

If you are willing to send a documentation PR, we can take a look :).

> Well, reboot to windows works but I would really like to have an option to boot through systemd-boot menu. So, essentially, it's not possible at all? I'm not sure systemd-boot gives us easy way to do this and we will probably not support super advanced modifications that diverges too much from what systemd encourages. > > > measurement path > > But from what I can see, if I sign the uefi shell and boot through it, I only have to enter bitlocker key once. > > In any case, it would be good to have this documented. If you are willing to send a documentation PR, we can take a look :).
pshirshov commented 2025-01-26 00:33:36 +00:00 (Migrated from github.com)

I'm know literally nothing about the subject.

I'm know literally nothing about the subject.
rainx0r commented 2025-02-03 04:39:01 +00:00 (Migrated from github.com)

@RaitoBezarius

I think you only need to keep Microsoft keys and let systemd-boot know about Windows via the magic reboot into Windows option and that's it?

Which magic reboot into Windows option are you referring to? systemd-boot can't know about Windows if it's installed on another drive. However, in boot.loader.systemd-boot, it is possible to configure Windows entries manually if you know the EFI device handle which is pretty easy to get with edk2-uefi-shell. Currently, lanzaboote does not seem to support this .windows option at all and even if it's specified in boot.loader.systemd-boot.windows the corresponding boot entry does not seem to be generated. So am I missing some other magic that could be used here or can I conclude that currently lanzaboote does not support Windows on other drives? (Which is also the case for OP)

Secondly, to boot Windows this way, systemd-boot uses the edk2-uefi-shell still, which is not signed by lanzaboote by default. I'm pretty sure that's also what OP was originally trying to convey. I think these two issues are the crux of the problem.

The thing is I'm actually a bit confused as to why some of this is happening. I can see there is a test where supposedly some settings are set in boot.loader.systemd-boot and then they end up in the actual /boot/loader/loader.conf. I can't reproduce this locally as any changes in boot.loader.systemd-boot just don't get reflected in /boot if lanzaboote is enabled, which I suppose is expected since lanzaboote does say it's a replacement right now.

So, am I missing something in terms of getting certain settings from boot.loader.systemd-boot (such as boot.loader.systemd-boot.windows) working? Or is that intended? Or is it intended to work and it not working is a bug? And if it's indeed not intended to work then does lanzaboote intend to reimplement all boot.loader.systemd-boot settings eventually? Because there are a lot of settings there that I can't currently see equivalents for in lanzaboote.

@RaitoBezarius > I think you only need to keep Microsoft keys and let systemd-boot know about Windows via the magic reboot into Windows option and that's it? Which magic reboot into Windows option are you referring to? systemd-boot can't know about Windows if it's installed on another drive. However, in `boot.loader.systemd-boot`, [it is possible to configure Windows entries manually if you know the EFI device handle](https://github.com/NixOS/nixpkgs/commit/73011ba96fe6dc0574c38b594a72657a5a7e2f39) which is pretty easy to get with edk2-uefi-shell. Currently, lanzaboote does not seem to support this `.windows` option at all and even if it's specified in `boot.loader.systemd-boot.windows` the corresponding boot entry does not seem to be generated. So am I missing some other magic that could be used here or can I conclude that currently lanzaboote does not support Windows on other drives? (Which is also the case for OP) Secondly, to boot Windows this way, systemd-boot uses the edk2-uefi-shell still, which is not signed by lanzaboote by default. I'm pretty sure that's also what OP was originally trying to convey. I think these two issues are the crux of the problem. The thing is I'm actually a bit confused as to why some of this is happening. I can see [there is a test](https://github.com/nix-community/lanzaboote/blob/master/nix/tests/lanzaboote/systemd-boot-loader-config.nix#L12) where supposedly some settings are set in `boot.loader.systemd-boot` and then they end up in the actual `/boot/loader/loader.conf`. I can't reproduce this locally as any changes in `boot.loader.systemd-boot` just don't get reflected in `/boot` if lanzaboote is enabled, which I suppose is expected since lanzaboote does say it's a replacement right now. So, am I missing something in terms of getting certain settings from `boot.loader.systemd-boot` (such as `boot.loader.systemd-boot.windows`) working? Or is that intended? Or is it intended to work and it not working is a bug? And if it's indeed not intended to work then does lanzaboote intend to reimplement all `boot.loader.systemd-boot` settings eventually? Because there are a lot of settings there that I can't currently see equivalents for in lanzaboote.
arulagrawal commented 2025-02-16 12:33:33 +00:00 (Migrated from github.com)

Which magic reboot into Windows option are you referring to?

boot.lanzaboote.settings.reboot-for-bitlocker

> Which magic reboot into Windows option are you referring to? `boot.lanzaboote.settings.reboot-for-bitlocker`
elikoga commented 2025-03-02 06:42:50 +00:00 (Migrated from github.com)

I got a dual boot fde with tpm key storage setup without the reboot flag on my hp laptop but I don't exactly remember how I achieved it 😊

I don't remember it being difficult though, and I can verify that I needed to enter the bitlocker key once or twice for the initial install. Sometimes you need to enter the key but you will always know what you did to cause it.

I got a dual boot fde with tpm key storage setup without the reboot flag on my hp laptop but I don't exactly remember how I achieved it 😊 I don't remember it being difficult though, and I can verify that I needed to enter the bitlocker key once or twice for the initial install. Sometimes you need to enter the key but you will always know what you did to cause it.
samemrecebi commented 2025-04-25 11:24:40 +00:00 (Migrated from github.com)

Hey, I was able to get it working while having windows on a separate drive. The NixOS wiki explains how to set it up using edk2-uefi-shell. Lanzabnoote does not sign the boot file for it but I manually signed it by following this link from the arch wiki. I do not know if this will keep working with updates and how it will work with Bit Locker but at least it allows it to boot. Maybe it should be included into the guide or if edk2-uefi-shell is enabled lazaboote should also sign it. Whats your opinion?

Hey, I was able to get it working while having windows on a separate drive. The NixOS wiki explains how to set it up using edk2-uefi-shell. Lanzabnoote does not sign the boot file for it but I manually signed it by following [this link](https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Signing) from the arch wiki. I do not know if this will keep working with updates and how it will work with Bit Locker but at least it allows it to boot. Maybe it should be included into the guide or if edk2-uefi-shell is enabled lazaboote should also sign it. Whats your opinion?
pshirshov commented 2025-04-25 16:00:41 +00:00 (Migrated from github.com)

Yes, that can be done, though there is no way to do it declaratively. And, I believe, edk2-uefi-shell provides way too much to a potential attacker.

Yes, that can be done, though there is no way to do it declaratively. And, I believe, edk2-uefi-shell provides way too much to a potential attacker.
samemrecebi commented 2025-04-25 19:46:53 +00:00 (Migrated from github.com)

Yes, that can be done, though there is no way to do it declaratively. And, I believe, edk2-uefi-shell provides way too much to a potential attacker.

Yea I agree but maybe it could be an option for people who want to as with systemdboot and windows on a separate drive I don't think there is a different option. At the very least maybe it can be included into the QuickStart guide how to sign it and say it has security risks.

> Yes, that can be done, though there is no way to do it declaratively. And, I believe, edk2-uefi-shell provides way too much to a potential attacker. Yea I agree but maybe it could be an option for people who want to as with systemdboot and windows on a separate drive I don't think there is a different option. At the very least maybe it can be included into the QuickStart guide how to sign it and say it has security risks.
JHilmarch commented 2025-05-24 11:33:25 +00:00 (Migrated from github.com)

Hello good people!

I'm setting up NixOS on Acer Orion Predator 7000, side by side with Windows 11 (dual boot). The motherboard is replaced with Asus PRIME Z790-P Wifi. The systems are installed on the same physical disc and the boot partition (ESP) is shared. I enabled LUKS on the NIXROOT partition and my next step was to get Secure Boot working. I got into a state where Lanzaboote is installed, the keys are enrolled and secure boot is activated....BUT! ...only login to Windows is working. When I'm booting into NixOS I get at message saying that the kernel hash is not matching.

The steps I did:

  • Installed sbctl
  • Cleared the secure boot keys in UEFI to enter "setup" mode
  • Generated new keys with sbctl, with the Windows flag
  • Upgraded to sbctl 'unstable' and migrated to new configuration
  • Verified that all the keys are signed with sbctl
  • Enrolled keys
  • Activated Secure Boot with Windows UEFI

Anybody know how I can get it to work? Please, reach out! I followed the documentation step by step, so I agree that documentation for this use case is needed.

Here is my code changes: https://github.com/JHilmarch/nixos-config/pull/18/files

> bootctl status

System:
      Firmware: UEFI 2.80 (American Megatrends 5.27)
 Firmware Arch: x64
   Secure Boot: disabled
  TPM2 Support: yes
  Measured UKI: yes
  Boot into FW: supported

Current Boot Loader:
      Product: systemd-boot 256.10
     Features: ✓ Boot counting
               ✓ Menu timeout control
               ✓ One-shot menu timeout control
               ✓ Default entry control
               ✓ One-shot entry control
               ✓ Support for XBOOTLDR partition
               ✓ Support for passing random seed to OS
               ✓ Load drop-in drivers
               ✓ Support Type #1 sort-key field
               ✓ Support @saved pseudo-entry
               ✓ Support Type #1 devicetree field
               ✓ Enroll SecureBoot keys
               ✓ Retain SHIM protocols
               ✓ Menu can be disabled
               ✓ Boot loader sets ESP information
         Stub: lanzastub 0.4.2
     Features: ✓ Stub sets ESP information
               ✗ Picks up credentials from boot partition
               ✗ Picks up system extension images from boot partition
               ✗ Picks up configuration extension images from boot partition
               ✗ Measures kernel+command line+sysexts
               ✗ Support for passing random seed to OS
               ✗ Pick up .cmdline from addons
               ✗ Pick up .cmdline from SMBIOS Type 11
               ✗ Pick up .dtb from addons
          ESP: /dev/disk/by-partuuid/fac1026b-852c-4b89-903c-8687fc60cf6c
         File: └─/EFI/systemd/systemd-bootx64.efi

Random Seed:
 System Token: set
       Exists: yes

Available Boot Loaders on ESP:
          ESP: /boot (/dev/disk/by-partuuid/fac1026b-852c-4b89-903c-8687fc60cf6c)
         File: ├─/EFI/systemd/systemd-bootx64.efi (systemd-boot 256.10)
               └─/EFI/BOOT/bootx64.efi (systemd-boot 256.10)

Boot Loaders Listed in EFI Variables:
        Title: Windows Boot Manager
           ID: 0x0000
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/fac1026b-852c-4b89-903c-8687fc60cf6c
         File: └─/EFI/systemd/systemd-bootx64.efi

        Title: Windows Boot Manager
           ID: 0x0001
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/fac1026b-852c-4b89-903c-8687fc60cf6c
         File: └─/EFI/Microsoft/Boot/bootmgfw.efi

Boot Loader Entries:
        $BOOT: /boot (/dev/disk/by-partuuid/fac1026b-852c-4b89-903c-8687fc60cf6c)
        token: nixos

Default Boot Loader Entry:
         type: Boot Loader Specification Type #2 (.efi)
        title: NixOS Vicuna 24.11.20250521.2baa12f (Linux 6.6.91) (Generation 10, 2025-05-24)
           id: nixos-generation-10-coxpli4t4ooc4dmuucpzy3ipj3p7mufsbvbquc3heidq7qlrwq3q.efi
       source: /boot//EFI/Linux/nixos-generation-10-coxpli4t4ooc4dmuucpzy3ipj3p7mufsbvbquc3heidq7qlrwq3q.efi
     sort-key: lanza
      version: Generation 10, 2025-05-24
        linux: /boot//EFI/Linux/nixos-generation-10-coxpli4t4ooc4dmuucpzy3ipj3p7mufsbvbquc3heidq7qlrwq3q.efi
      options: init=/nix/store/n25jinbsqydlaz7g7mya5idm1lj4aix8-nixos-system-nixos-orion-7000-24.11.20250521.2baa12f/init root=fstab loglevel=4 nvidia-drm.modeset=1 nvidia-drm.fbdev=1 nvidia.NVreg_OpenRmEnableUnsupportedGpus=1
❯ sudo sbctl list-enrolled-keys
[sudo] password for jonatan: 
PK:
  ASUSTeK MotherBoard PK Certificate
KEK:
  ASUSTeK MotherBoard KEK Certificate
  Microsoft Corporation Third Party Marketplace Root
  Microsoft RSA Devices Root CA 2021
DB:
  ASUSTeK MotherBoard SW Key Certificate
  ASUSTeK Notebook SW Key Certificate
  Microsoft Corporation Third Party Marketplace Root
  Microsoft Root Certificate Authority 2010
  Microsoft RSA Devices Root CA 2021
  Microsoft Root Certificate Authority 2010
sudo sbctl status
Installed:	✓ sbctl is installed
Owner GUID:	98b85f3b-61a8-408e-aa43-e8e40802e99b
Setup Mode:	✓ Disabled
Secure Boot:	✗ Disabled
Vendor Keys:	microsoft builtin-db builtin-db builtin-db builtin-KEK builtin-PK
Hello good people! I'm setting up NixOS on Acer Orion Predator 7000, side by side with Windows 11 (dual boot). The motherboard is replaced with Asus PRIME Z790-P Wifi. The systems are installed on the same physical disc and the boot partition (ESP) is shared. I enabled LUKS on the NIXROOT partition and my next step was to get Secure Boot working. I got into a state where Lanzaboote is installed, the keys are enrolled and secure boot is activated....BUT! ...only login to Windows is working. When I'm booting into NixOS I get at message saying that _the kernel hash is not matching_. The steps I did: - Installed sbctl - Cleared the secure boot keys in UEFI to enter "setup" mode - Generated new keys with sbctl, with the Windows flag - Upgraded to sbctl 'unstable' and migrated to new configuration - Verified that all the keys are signed with sbctl - Enrolled keys - Activated Secure Boot with Windows UEFI Anybody know how I can get it to work? Please, reach out! I followed the documentation step by step, so I agree that documentation for this use case is needed. Here is my code changes: https://github.com/JHilmarch/nixos-config/pull/18/files ``` > bootctl status System: Firmware: UEFI 2.80 (American Megatrends 5.27) Firmware Arch: x64 Secure Boot: disabled TPM2 Support: yes Measured UKI: yes Boot into FW: supported Current Boot Loader: Product: systemd-boot 256.10 Features: ✓ Boot counting ✓ Menu timeout control ✓ One-shot menu timeout control ✓ Default entry control ✓ One-shot entry control ✓ Support for XBOOTLDR partition ✓ Support for passing random seed to OS ✓ Load drop-in drivers ✓ Support Type #1 sort-key field ✓ Support @saved pseudo-entry ✓ Support Type #1 devicetree field ✓ Enroll SecureBoot keys ✓ Retain SHIM protocols ✓ Menu can be disabled ✓ Boot loader sets ESP information Stub: lanzastub 0.4.2 Features: ✓ Stub sets ESP information ✗ Picks up credentials from boot partition ✗ Picks up system extension images from boot partition ✗ Picks up configuration extension images from boot partition ✗ Measures kernel+command line+sysexts ✗ Support for passing random seed to OS ✗ Pick up .cmdline from addons ✗ Pick up .cmdline from SMBIOS Type 11 ✗ Pick up .dtb from addons ESP: /dev/disk/by-partuuid/fac1026b-852c-4b89-903c-8687fc60cf6c File: └─/EFI/systemd/systemd-bootx64.efi Random Seed: System Token: set Exists: yes Available Boot Loaders on ESP: ESP: /boot (/dev/disk/by-partuuid/fac1026b-852c-4b89-903c-8687fc60cf6c) File: ├─/EFI/systemd/systemd-bootx64.efi (systemd-boot 256.10) └─/EFI/BOOT/bootx64.efi (systemd-boot 256.10) Boot Loaders Listed in EFI Variables: Title: Windows Boot Manager ID: 0x0000 Status: active, boot-order Partition: /dev/disk/by-partuuid/fac1026b-852c-4b89-903c-8687fc60cf6c File: └─/EFI/systemd/systemd-bootx64.efi Title: Windows Boot Manager ID: 0x0001 Status: active, boot-order Partition: /dev/disk/by-partuuid/fac1026b-852c-4b89-903c-8687fc60cf6c File: └─/EFI/Microsoft/Boot/bootmgfw.efi Boot Loader Entries: $BOOT: /boot (/dev/disk/by-partuuid/fac1026b-852c-4b89-903c-8687fc60cf6c) token: nixos Default Boot Loader Entry: type: Boot Loader Specification Type #2 (.efi) title: NixOS Vicuna 24.11.20250521.2baa12f (Linux 6.6.91) (Generation 10, 2025-05-24) id: nixos-generation-10-coxpli4t4ooc4dmuucpzy3ipj3p7mufsbvbquc3heidq7qlrwq3q.efi source: /boot//EFI/Linux/nixos-generation-10-coxpli4t4ooc4dmuucpzy3ipj3p7mufsbvbquc3heidq7qlrwq3q.efi sort-key: lanza version: Generation 10, 2025-05-24 linux: /boot//EFI/Linux/nixos-generation-10-coxpli4t4ooc4dmuucpzy3ipj3p7mufsbvbquc3heidq7qlrwq3q.efi options: init=/nix/store/n25jinbsqydlaz7g7mya5idm1lj4aix8-nixos-system-nixos-orion-7000-24.11.20250521.2baa12f/init root=fstab loglevel=4 nvidia-drm.modeset=1 nvidia-drm.fbdev=1 nvidia.NVreg_OpenRmEnableUnsupportedGpus=1 ``` ``` ❯ sudo sbctl list-enrolled-keys [sudo] password for jonatan: PK: ASUSTeK MotherBoard PK Certificate KEK: ASUSTeK MotherBoard KEK Certificate Microsoft Corporation Third Party Marketplace Root Microsoft RSA Devices Root CA 2021 DB: ASUSTeK MotherBoard SW Key Certificate ASUSTeK Notebook SW Key Certificate Microsoft Corporation Third Party Marketplace Root Microsoft Root Certificate Authority 2010 Microsoft RSA Devices Root CA 2021 Microsoft Root Certificate Authority 2010 ``` ``` sudo sbctl status Installed: ✓ sbctl is installed Owner GUID: 98b85f3b-61a8-408e-aa43-e8e40802e99b Setup Mode: ✓ Disabled Secure Boot: ✗ Disabled Vendor Keys: microsoft builtin-db builtin-db builtin-db builtin-KEK builtin-PK ```
nixos-discourse commented 2025-06-12 17:34:56 +00:00 (Migrated from github.com)

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/secureboot-on-stable-do-i-need-lanzaboote/65583/2

This issue has been mentioned on **NixOS Discourse**. There might be relevant details there: https://discourse.nixos.org/t/secureboot-on-stable-do-i-need-lanzaboote/65583/2
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: raito/lanzaboote#427
No description provided.