Bug 1626862 - Broken Fedora/Windows dualboot
Summary: Broken Fedora/Windows dualboot
Keywords:
Status: CLOSED DUPLICATE of bug 1631989
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F29FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2018-09-09 22:07 UTC by František Zatloukal
Modified: 2018-10-02 19:32 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-02 19:32:31 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
grub.cfg - grub2-efi-x64-2.02-51.fc29 (7.74 KB, text/plain)
2018-09-10 07:48 UTC, František Zatloukal
no flags Details
grub.cfg - grub2-efi-x64-2.02-38.fc28.x86_64 (6.25 KB, text/plain)
2018-09-10 07:49 UTC, František Zatloukal
no flags Details
efibootmgr -v (fc28 - working packages) (1.19 KB, text/plain)
2018-09-30 16:29 UTC, František Zatloukal
no flags Details
efibootmgr -v (fc29 - broken packages) (1.19 KB, text/plain)
2018-09-30 16:30 UTC, František Zatloukal
no flags Details

Description František Zatloukal 2018-09-09 22:07:00 UTC
Description of problem:
GRUB is broken after upgrading Fedora 28 to Fedora 29 on a Fedora/Windows 10 Dualboot desktop.

Version-Release number of selected component (if applicable):
grub2-efi-x64-2.02-51.fc29
grub2-efi-x64-2.02-54.fc29


Steps to Reproduce:
1. Install Windows 10 and the Fedora 28
2. Upgrade Fedora 28 to Fedora 29

Actual results:
Booting Fedora "skips" GRUB entirely and ends with Windows 10 Bootloader complaining about \Windows\system32\winload.exe . However, if I choose to boot Windows 10 from UEFI directly, instead of Fedora, it works just fine.


Additional info:
The Upgrade was done with updates-testing enabled, so grub2-efi-x64-2.02-54.fc29 got installed. After that, I've tried downgrading to grub2-efi-x64-2.02-51.fc29 which didn't help at all.

The only solution that worked was to downgrade to Fedora 28 grub packages, that was done from chroot by:
dnf downgrade grub2* --releasever=28
dnf remove efi-filesystem --releasever=28
dnf install shim-x64 efibootmgr --releasever=28
dnf reinstall grub2-efi shim --releasever=28
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

After downgrading to F28 GRUB ( grub2-efi-x64-2.02-38.fc28.x86_64 ), everything is working just fine. SecureBoot is enabled on that desktop. 

I'll test SecureBoot off and add more information/logs tomorrow.

Comment 1 František Zatloukal 2018-09-10 07:46:52 UTC
So, using just grub from F28 is not enough, also shim-x64 from F28 is necessary in order to be able to boot to grub.

Secure boot seems to be disabled:
[    0.000000] secureboot: Secure boot disabled


grub2-mkconfig:

# Broken, grub2-efi-x64-2.02-51.fc29 shim-x64-15-5.x86_64 efibootmgr-16-4.fc29.x86_64
$ sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.18.5-300.fc29.x86_64
Found initrd image: /boot/initramfs-4.18.5-300.fc29.x86_64.img
Found linux image: /boot/vmlinuz-4.18.5-200.fc28.x86_64
Found initrd image: /boot/initramfs-4.18.5-200.fc28.x86_64.img
Found linux image: /boot/vmlinuz-4.16.3-300.fc28.x86_64
Found initrd image: /boot/initramfs-4.16.3-300.fc28.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-84bb94dc29014906b77699567d57024b
Found initrd image: /boot/initramfs-0-rescue-84bb94dc29014906b77699567d57024b.img
Found Windows Boot Manager on /dev/sda2@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for EFI firmware configuration
done


# Working, grub2-efi-x64-2.02-38.fc28.x86_64 shim-x64-15-2.x86_64 efibootmgr-16-2.fc28.x86_64
$ sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.18.5-300.fc29.x86_64
Found initrd image: /boot/initramfs-4.18.5-300.fc29.x86_64.img
Found linux image: /boot/vmlinuz-4.18.5-200.fc28.x86_64
Found initrd image: /boot/initramfs-4.18.5-200.fc28.x86_64.img
Found linux image: /boot/vmlinuz-4.16.3-300.fc28.x86_64
Found initrd image: /boot/initramfs-4.16.3-300.fc28.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-84bb94dc29014906b77699567d57024b
Found initrd image: /boot/initramfs-0-rescue-84bb94dc29014906b77699567d57024b.img
Found Windows Boot Manager on /dev/sda2@/EFI/Microsoft/Boot/bootmgfw.efi
done

Comment 2 František Zatloukal 2018-09-10 07:48:55 UTC
Created attachment 1482021 [details]
grub.cfg - grub2-efi-x64-2.02-51.fc29

Comment 3 František Zatloukal 2018-09-10 07:49:28 UTC
Created attachment 1482023 [details]
grub.cfg - grub2-efi-x64-2.02-38.fc28.x86_64

Comment 4 Fedora Blocker Bugs Application 2018-09-10 14:19:57 UTC
Proposed as a Blocker for 29-final by Fedora user frantisekz using the blocker tracking app because:

 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.

Comment 5 Chris Murphy 2018-09-14 02:21:39 UTC
I can't reproduce with:
shim-x64-15-5.x86_64
grub2-efi-x64-2.02-58.fc29.x86_64

Comment 6 Adam Williamson 2018-09-15 00:06:41 UTC
Frantisek, can you still reproduce?

Comment 7 František Zatloukal 2018-09-15 07:07:17 UTC
Yes, still broken the same way.

Note: This is probably Hardware specific, I wasn't able to reproduce it on another desktop.

MB where is this happening: Gigabyte GA-Z170-D3H, BIOS: F22f (latest), SecureBoot off

Comment 8 Geoffrey Marr 2018-09-17 20:18:00 UTC
Discussed during the 2018-09-17 blocker review meeting: [1]

The decision to delay the classification of this as a blocker bug was made as this is a potential violation of the dual-boot criterion, but it seems unclear what's going on and if it's somehow system-specific. We will delay the decision to try and gather more info.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-09-17/f29-blocker-review.2018-09-17-16.02.txt

Comment 9 Geoffrey Marr 2018-09-24 19:34:01 UTC
Discussed during the 2018-09-24 blocker review meeting: [1]

The decision to delay the classification of this as a blocker bug was made as this bug seems to be system-specific in some way; we need more information to make a decision. We will ask pjones how frantisek can proceed from here to figure out what the problem is.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-09-24/f29-blocker-review.2018-09-24-16.05.txt

Comment 10 Kamil Páral 2018-09-25 11:30:29 UTC
I tested this on one of our Brno office test machines and dualboot with Windows works fine in UEFI and BIOS mode. This bug is likely hardware specific.

Comment 11 František Zatloukal 2018-09-30 16:28:12 UTC
It's still broken with grub2-efi-x64-2.02-59.fc29 .

Also, this is possible duplicate: https://bugzilla.redhat.com/show_bug.cgi?id=1634386

Comment 12 František Zatloukal 2018-09-30 16:29:53 UTC
Created attachment 1488614 [details]
efibootmgr -v (fc28 - working packages)

Comment 13 František Zatloukal 2018-09-30 16:30:37 UTC
Created attachment 1488615 [details]
efibootmgr -v (fc29 - broken packages)

Comment 14 Adam Williamson 2018-10-01 15:15:38 UTC
Frantisek, can we see the partition layout of the affected system? Does it by any chance have two EFI system partitions?

Comment 15 Geoffrey Marr 2018-10-01 19:47:40 UTC
Discussed during the 2018-10-01 blocker review meeting: [1]

The decision to delay the classification of this as a blocker bug was made as it is still not clear exactly what is going on in this case and we do not have sufficient info to make a blocker decision yet. We ask frantisekz and pjones to try and get more info on what's going on here.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-10-01/f29-blocker-review.2018-10-01-16.00.txt

Comment 16 Mamoru TASAKA 2018-10-02 01:31:57 UTC
(In reply to František Zatloukal from comment #13)
> Created attachment 1488615 [details]
> efibootmgr -v (fc29 - broken packages)

This says 

Boot0002* Fedora	HD(2,GPT,ed72f972-829b-4de2-b9ce-19fd465e7e28,0xe1800,0x31800)/File(\EFI\FEDORA\SHIM.EFI)..BO 

so maybe this may be seeing the same issue as https://bugzilla.redhat.com/show_bug.cgi?id=1634386#c11

Comment 17 František Zatloukal 2018-10-02 07:42:04 UTC
(In reply to Adam Williamson from comment #14)
> Frantisek, can we see the partition layout of the affected system? Does it
> by any chance have two EFI system partitions?

fdisk -l
Disk /dev/sda: 223.6 GiB, 240057409536 bytes, 468862128 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: D7B06C2B-10A3-4FA8-A1E9-7B3A8E8A26B0

Device         Start       End   Sectors  Size Type
/dev/sda1       2048    923647    921600  450M Windows recovery environment
/dev/sda2     923648   1126399    202752   99M EFI System
/dev/sda3    1126400   1159167     32768   16M Microsoft reserved
/dev/sda4    1159168 368160767 367001600  175G Microsoft basic data
/dev/sda5  368160768 370257919   2097152    1G Linux filesystem
/dev/sda6  370257920 380329983  10072064  4.8G Linux swap
/dev/sda7  380329984 468860927  88530944 42.2G Linux filesystem


Doesn't seem so, /dev/sda5 is Fedora's boot.

Comment 18 Mamoru TASAKA 2018-10-02 10:56:03 UTC
František, maybe installing shim-ia32-15-5.x86_64 fixes the problem you see?

Comment 19 Adam Williamson 2018-10-02 16:16:38 UTC
Yup indeed, this does look an awful lot like https://bugzilla.redhat.com/show_bug.cgi?id=1631989 ... which would mean it and 1634386 were dupes after all :)

Frantisek, if it was installed as Fedora 26 or earlier and installing 'shim-ia32' or editing the EFI boot manager entry to point to 'SHIMX64.EFI' instead of 'SHIM.EFI' fixes the problem, close as a dupe of 1631989. Thanks!

Comment 20 František Zatloukal 2018-10-02 19:32:01 UTC
Installing just shim-x64-15-7 from https://bodhi.fedoraproject.org/updates/FEDORA-2018-12bb418c63 fixed the issue (shim-ia32 was not needed).

Comment 21 František Zatloukal 2018-10-02 19:32:31 UTC

*** This bug has been marked as a duplicate of bug 1631989 ***


Note You need to log in before you can comment on or make changes to this bug.