View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0015751||CentOS-7||anaconda||public||2019-01-27 21:50||2019-02-01 12:51|
|Priority||normal||Severity||crash||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0015751: Installer can destroy EFI boot|
|Description||I 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 Reproduce||Put 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.
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)
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.
|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.|
|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|