View Issue Details

IDProjectCategoryView StatusLast Update
0015751CentOS-7anacondapublic2019-02-01 12:51
PrioritynormalSeveritycrashReproducibilityhave not tried
Status newResolutionopen 
PlatformLinuxOSCentOSOS Version7.6.1810
Product Version7.6.1810 
Target VersionFixed in Version 
Summary0015751: Installer can destroy EFI boot
DescriptionI have attempted to install CentOS 7.6.1810 on a laptop that had Windows 10 and EFI boot, the intention was to dual-boot.

I have used livecd-iso-to-disk on Fedora (on a different machine) to write the CentOS Gnome live ISO to a USB device. The BIOS of the target computer was set to support both EFI and legacy boot. I did free up space on the drive by shrinking the Windows partition from within Windows; I used manual partitioning to create CentOS partitions in the free space.

The install process proceeded with no unusual warnings. CentOS booted, but there was no dual-boot. It turned ut the boot was installed in non-EFI mode. It garbled the Windows boot system so bad that standard recovery steps (bootrec /fixboot or automatic startup repair from Windows installation media) do not work.

This should not be happening. The installer should not delete/break EFI boot without warning, whatever the BIOS settings etc.
Steps To ReproducePut the Gnome Live ISO onto a flash drive using livecd-iso-to-disk

Target computer must have Windows on EFI boot; enable legacy support in BIOS; ensure there is space for installing CentOS on target computer.

Install CentOS, partitioning manually, deleting nothing.




2019-01-29 01:23

reporter   ~0033716

I have eventually found a way to recover. Namely, I ran gdisk under a Linux system (booted from USB) and there used the v command. The result was:

Command (? for help): v

Warning: The 0xEE protective partition in the MBR is marked as active. This is
technically a violation of the GPT specification, and can cause some EFIs to
ignore the disk, but it is required to boot from a GPT disk on some BIOS-based
computers. You can clear this flag by creating a fresh protective MBR using
the 'n' option on the experts' menu.

No problems found. 227331437 free sectors (108.4 GiB) available in 3
segments, the largest of which is 225280000 (107.4 GiB) in size.

Then I used e (expert mode), then n, then w (write out). Then rebooted and Windows fired up.

I understand why anaconda made this change. But anaconda really needs to output a big fat warning that it is making a change which will render EFI boot inoperable, along with instructiins how to back that change out using gdisk. It also should not guide one to create a EFI partition when one already exists.

I am attaching anaconda logs (from /var/log/anaconda). Sady. after backing up these logs I removed all Linux partitions (as one of the attempts to recover) and so I can't retrieve any more data.

anaconda-efi-broken.tar.bz2 (146,365 bytes)


2019-01-30 23:26

reporter   ~0033735

A couple of notes on this:
 * The system did not boot in UEFI mode
 * While partitioning it displayed this warning 'Your BIOS-based system needs a special partition to boot from a GPT disk label. To continue, please create a 1MiB 'biosboot' type partition.'
 * Since it thought it was doing a BIOS install it set the pmbr_boot flag which apparently confused Windows.

I don't have any explanation for the efibootmgr results, anaconda did not do anything to edit, add, or remove any of the efi boot data.


2019-02-01 12:51

reporter   ~0033755

The confused part was not Windows but the UEFI code, which apparently erased EFI boot entries because of pmbr_boot_flag. My suggestion is to display a warning if pmbr_boot_flag is being set, telling the user EFI boot may fail and also that one ca use gdisk to undo this.

Issue History

Date Modified Username Field Change
2019-01-27 21:50 ramendik New Issue
2019-01-27 21:50 ramendik Tag Attached: efi
2019-01-29 01:23 ramendik File Added: anaconda-efi-broken.tar.bz2
2019-01-29 01:23 ramendik Note Added: 0033716
2019-01-30 23:26 bcl Note Added: 0033735
2019-02-01 12:51 ramendik Note Added: 0033755