Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2049849
| Summary: | Windows with bitlocker enabled can't be booted, needs to use bootnext instead of chainloader | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Chris Murphy <bugzilla> | |
| Component: | grub2 | Assignee: | Nicolas Frayer <nfrayer> | |
| Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | rawhide | CC: | abuse, awilliam, bcotton, bugzilla, cervajs, dominik, drfudgeboy, fmartine, fzatlouk, gary.buhrmaster, geno1520, gmarr, kparal, lkundrak, nerijus, phillip.szelat, pjones, redhat, rharwood, robatino, vtq-gnome, vtrefny, zbyszek | |
| Target Milestone: | --- | Keywords: | CommonBugs, FutureFeature | |
| Target Release: | --- | Flags: | bcotton:
fedora_prioritized_bug+
|
|
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | https://ask.fedoraproject.org/t/20612 RejectedBlocker | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 2132134 (view as bug list) | Environment: | ||
| Last Closed: | Type: | Bug | ||
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 2132134 | |||
|
Description
Chris Murphy
2022-02-02 19:27:24 UTC
Proposed as a Blocker for 36-final by Fedora user chrismurphy using the blocker tracking app because: https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Windows_dual_boot "and install a bootloader which can boot into ... Windows" The intent of the criterion is that Windows is bootable, which it isn't. In that sense, the bug is a blocker. However, this isn't a bug per se, nor is it a regression in GRUB. TPM measured boot is working as designed. This is in effect a request for enhancement for GRUB. From this point of view, it's maybe not a blocker because the criterion itself is prescribing a solution that won't work. The current work around is to use the firmware's boot manager to choose to boot Windows. This is probably a good candidate for common bugs documentation, and as a prioritized bug though. Discussed during the 2022-02-07 blocker review meeting: [0] The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion: "The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora" in the case of Windows being installed with Bitlocker enabled (as is increasingly common). We recognize this is technically difficult to fix and may change or defer. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-02-07/f36-blocker-review.2022-02-07-17.00.txt > The current work around is to use the firmware's boot manager to choose to boot Windows.
One can manipulate this from Linux using efibootmgr to set BootNext to the Windows entry as well.
I recommend either changing the criteria or deferring.
See also: https://pagure.io/fedora-workstation/issue/278 https://lists.gnu.org/archive/html/grub-devel/2022-02/msg00073.html This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle. Changing version to 36. For sd-boot we solved it by using BootNext [1]. That code will be available in rawhide after the next release (~one or two weeks). It's reported to work, though I haven't tried it myself due to lack of appropriate wall fixtures. [1] https://github.com/systemd/systemd/pull/22043/commits/661615a0afacee3545cde0a48286c0fef983f8fe At the 2022-03-28 blocker review meeting, we agreed to waive this bug to Fedora 37 according to the process: https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2022-03-28/f36-blocker-review.2022-03-28-16.00.html https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2022-03-28/f36-blocker-review.2022-03-28-16.00.log.html This is considered a "difficult to fix" bug - as indicated by Robbie above, there is no realistic prospect of it being fixed during the Fedora 36 timeframe. Accordingly, it is waived to Fedora 37. If upstream still doesn't consider this addressable during that timeframe, we'll consider amending the release criteria to not require dual-boot to work with BitLocker-enabled Windows installs. This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle. Changing version to 37. Since this doesn't seem to be moving, here's a release criteria amendment proposal: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/YT24WA7W6HYHOENBKDJ66PMZ4CHBTBMM/ The criterion proposal was approved and implemented, so bumping this back to proposed blocker. I expect it should now be rejected, since the criterion specifically exempts this exact situation. Discussed during the 2022-10-03 blocker review meeting: [1] The decision to classify this bug as an RejectedBlocker was made: We reject this as a blocker per the rewritten criterion: "The installer must be able to install into free space alongside an existing clean Windows installation. As long as the Windows installation does not have BitLocker enabled, the installer must also install a bootloader which can boot into both Windows and Fedora." [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2022-10-03/f37-blocker-review.2022-10-03-16.00.log.txt This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component. Is there any progress here? It's such a shame if Fedora can't play nicely with modern Windows installations: it'll really put people off making the switch. I only use grub as bootloader. When grub gets updated, I need to key in the bitlocker key once. Afterwards, it is fine. I can boot Fedora or Windows 11 fine from grub with secure boot enabled and bitlocker on. Proposing as a Prioritized bug as mentioned in comment 1. This is a long-standing bad situation for our dual-boot users. In today's prioritized bugs meeting, we agreed to accept this as it makes dual boot with some Windows installations more difficult https://meetbot.fedoraproject.org/fedora-meeting-1/2023-04-19/fedora_prioritized_bugs_and_issues.2023-04-19-14.00.log.html#l-82 This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component. This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '37'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed. As I recall, there is some experimental support in systemd-boot for windows bitlocker support (reboot-for-bitlocker) which has been stated that it is intended to be reworked at some point. Moving to systemd-boot from grub is not going to be viable to all (and the systemd shim is not yet signed, although there is the open bug 2268695 to do so in the future), but it may be something to keep an eye on to see when/if it can provide a path forward. |