#278 Future of dual booting Windows and Fedora
Opened 2 years ago by chrismurphy. Modified a month ago

Problem
Laptops with TPM 2.0 and Modern Standby and Windows 10 or 11 preinstalled [1] have Bitlocker disk encryption enabled by default, and the key is sealed in the TPM. Two problems result:

  • Bitlocker volume can't be resized in Linux {INSTALL/RESIZE}[2]
  • Bitlocker volume can't be unlocked when booting from GRUB {BOOT} [3]

Potential Solutions

  • Shrink using Window's Disk Management {INSTALL/RESIZE}
    • poor UI/UX
    • Should a new Windows resize tool be commissioned? At the March 15, 2022 meeting, the group decided it's worth investigating, dual boot is an important use case
  • UEFI firmware provide a built-in boot manager {BOOT}
    • No standard Fn key to bring it up
    • Highly variable UI/UX - difficult to generically document
  • FOSS bootloader {BOOT}
    • systemd-boot recently supports setting BootNextEFI variable, followed by a reboot. This works around the issue, and the UI/UX is the same as today.
    • Upstream GRUB are thus far unresponsive to implementing the same thing as sd-boot, or providing alternatives, see grub-devel thread
  • User-space boot selection {BOOT}
    • A graphical tool could use efibootmgr --bootnext to set Windows as the next booted OS following a reboot.

Notes
[1] The scope of the issue is confusing due to Microsoft's policy changing within the Windows 10 lifecycle. Most computers with Windows 10 Pro preinstalled in the last ~2 years have it enabled, e.g. ThinkPad X1 Carbon Gen 7 Laptop. Windows 10 Home often doesn't have it enabled. Users with Windows 11 Home are reporting it is enabled.

[2] Anaconda uses cryptsetup to unlock encrypted volumes. Cryptsetup supports the Bitlocker metadata format, and can unlock these volumes, but not modify the metadata. Upstream cryptsetup thread expresses uncertainty over resizing. Anaconda/blivet doesn't support BitLocker yet, an RFE has been filed.

[3] Bitlocker seals the encryption key in the TPM. Measured Boot uses the TPM to cryptographically verify the boot chain, and only unseal the Bitlocker encryption key if the boot chain is intact. The usage of either shim or GRUB results in unexpected measured boot values and thus boot failure, as it's indistinguishable from the boot chain being tampered with. The end user sees a blue Bitlocker Recovery Key page, and if they enter their ~48 character recovery key, the system boots.


Metadata Update from @chrismurphy:
- Issue assigned to chrismurphy
- Issue set to the milestone: Future Release
- Issue tagged with: experience, installation, meeting-request

2 years ago

Metadata Update from @chrismurphy:
- Issue untagged with: meeting-request

2 years ago

I've simplified the issue. Two things I forgot to mention at the meeting that are relevant:

  • Related Bug 2049849 is a conditional blocker for Fedora 36. The final release criterion says our bootloader needs to boot Windows, and right now it doesn't. It's conditional because while it affects many users, it's not yet the vast majority (or so far as we know).

  • User-space boot selection tool. It could be as simple as a "Reboot to Windows" checkbox in the reboot dialog.

Windows with bitlocker enabled can't be booted, needs to use bootnext instead of chainloader
https://bugzilla.redhat.com/show_bug.cgi?id=2049849

This release blocking bug has been waived as "difficult to fix" for Fedora 36. If it's not addressable for Fedora 37, good chance the release criterion that requires the bootloader being capable of booting both Fedora and Windows will be dropped.

We're at risk for Fedora 37's GRUB menu entry being unable to boot Windows for recent hardware.

Metadata Update from @chrismurphy:
- Issue tagged with: meeting-request

2 years ago

I've resummarized and posted future of dual booting Windows and Fedora, redux to the Fedora devel mailing list.

This needs more visibility though, somehow. It affects Fedora downstreams, any distribution targeting Windows users with explicit dual boot support, and any desktop environment. But I'm not sure how to go about getting it that visibility. What about bringing it to the attention to lwn and see if a staff writer wants to take this on?

My take with RH bootloader folks is they would be happy to cede this to user space, e.g. efibootmgr, and optionally a GUI wrapper for it. In this case, we don't need a bootloader specific developer, but UI/UX eval and a proper home for it. Discoverability might be the hardest part. Maybe it should go in the restart/shutdown menu rather than expecting the user to find a g-c-c panel?

There's minimum requirements and scope to figure out. efibootmgr lists many things that don't need to be exposed to the user, because this isn't a replacement for the firmware's boot options menu. It just tries to make it easier to boot some other OS. The question is whether it should be limited to to Windows (and possibly macOS), or extended to any Linux distro.

Note: Make sure to (re)consider the role of the normally hidden "Boot Options" in the restart/shutdown menu, revealed when holding down the Alt key. This currently causes the "hidden GRUB menu" to appear on the next boot.

How confusing is it when some boot options are in the GRUB menu and other boot options are in a g-c-c panel? Could they all go in a new g-c-c boot options panel?

Just unlocking bitlocker and resizing the Windows volume will still break the TPM measurement and lead to the recovery page next boot.

Instead, you would need to suspend bitlocker and resize the Windows volume from within Windows, install Fedora in the free space, then boot back to Windows and reenable bitlocker. That will update the boot measurement to include GRUB. Things will work ok until grub is updated.

Would it help if I write up a full gist or video on the topic? I’d also be happy to collaborate on testing a grub-less option. I dual boot Fedora 36 on multiple machines with bitlocker and secure boot enabled.

In the latest workstation wg meeting notes i saw “ ACTION: Allan to set up a separate call with interested parties
(brainycmurf, 01:12:46)” - where could I get more info on the followup? I could join if I’m available

Metadata Update from @catanzaro:
- Issue untagged with: meeting-request

a year ago

In the latest workstation wg meeting notes i saw “ ACTION: Allan to set up a separate call with interested parties
(brainycmurf, 01:12:46)” - where could I get more info on the followup? I could join if I’m available

Sorry @patricklang , I only just noticed this comment. I'm going to organise this conversation soon. If you want to make contact on Matrix (#workstation:fedoraproject.org) , I'll add you to the invite.

@aday did this call happen? Any status update?

@aday did this call happen?

I'm currently in the process of organising it. Hopefully it will happen in the next couple of weeks.

The call is happening at 15:00 UTC on Friday 20 January. If anyone wants to participate, just let me know.

If someone has a dual boot system and they want to switch to the other OS, having to dig into the settings each time is going to be rather frustrating.

It might be better to list the available boot targets in gnome-shell's reboot dialog.

We should be able to identify boot targets at startup for desktops to populate in their various system action menus/dialogs, right?

We should be able to identify boot targets at startup for desktops to populate in their various system action menus/dialogs, right?

What we discussed in the call was filtering the output of efibootmgr to identify valid boot targets - basically any entries starting with HD. We'll also need to eliminate any entries that don't exist on disk.

It might be better to list the available boot targets in gnome-shell's reboot dialog.

Hmm, so the issue here might be that elevated privileges are required to set bootnext...

I've got to a reasonable stage with the designs now, and have filed a couple of tickets against gnome-shell to have them implemented:

As far as I'm aware, no one is lined up to work on this.

gnome-shell requires a d-bus api that it can use to set next boot. @feborges requested this from systemd in systemd#26397 , which has been marked as a duplicate of systemd#11221 .

As far as I'm aware, no one is lined up to work on this.

Looks like this is a problem. I see the design work is done, and we've taken this as far as we can without a developer working on the project.

We will have to eventually close this issue if no developers are interested in working on it. In this case, we should probably document that Fedora does not support dual booting with Windows when Bitlocker is in use.

@chrismurphy any ideas what next steps should be? Maybe a call for assistance?

Yes, cross posting on the discussion forum and devel@ list seems appropriate.

@chrismurphy any status update here?

We will have to eventually close this issue if no developers are interested in working on it. In this case, we should probably document that Fedora does not support dual booting with Windows when Bitlocker is in use.

Unless somebody is planning to work on this, I suggest we just document this limitation. Bitlocker users probably do not expect to be able to dual boot Linux anyway.

No update.

Increasingly every Windows user is a Bitlocker user. It's become the default in some Windows variants, and some vendors are opting into Bitlocker by default even when it's not the default for a particular Windows variant.

Login to comment on this ticket.

Metadata
Boards 1
Installing Status: Backlog