Red Hat Bugzilla – Bug 809963
EFI install from DVD forgets previous EFI boot
Last modified: 2012-06-04 20:07:32 EDT
Description of problem: Fresh install from Fedora-17-Beta-RC3-x86_64-DVD onto a new partition of a harddrive with previous EFI boot of Fedora 17 from an existing partition, deletes the choice of booting the previous system. Also there are hints that the [second] install thought this was a mactel system.
Version-Release number of selected component (if applicable):
How reproducible: haven't tried
Steps to Reproduce:
1. EFI boot from DVD, Custom partitioning of totally-blank drive (create and write new GPT label, new EFI System Partition 100MiB FAT16 as /boot/efi, new ntfs partition 90GiB, new swap 15GiB, new root 15GiB), install onto root.
2. EFI boot from DVD, Custom partitioning of drive from step 1 (mount existing EFI System Partition as /boot/efi, new 15GiB root), install onto root.
Actual results: Second install leaves only one stanza in /boot/efi/EFI/redhat/grub.conf, pointing at second root. Old grub.conf.anacbak has stanza for old system. Splash screen for grub2 boot is totally black background instead of night sky with stars and aurorae. New mactel file mach_kernel and directory System/ have been added to /boot/EFI.
Expected results: Second install lists both old and new systems in /boot/efi/EFI/redhat/grub.conf. grub2 splash screen background is unchanged from first install. No mactel files are present.
# diff grub.conf.anacbak grub.conf
< # kernel /boot/vmlinuz-version ro root=/dev/sda4
> # kernel /boot/vmlinuz-version ro root=/dev/sda5
< device (hd0,3) HD(1,800,32000,dd8d4311-2ba2-4518-8b62-4722dca6dd74)
> device (hd0,4) HD(1,800,32000,dd8d4311-2ba2-4518-8b62-4722dca6dd74)
< title Fedora (3.3.0-8.fc17.x86_64)
< root (hd0,3)
< kernel /boot/vmlinuz-3.3.0-8.fc17.x86_64 rd.md=0 rd.lvm=0 rd.dm=0 root=UUID=981e2901-cfef-4884-95f7-8bdd77009bec KEYTABLE=us SYSFONT=True rd.luks=0 ro LANG=en_US.UTF-8
< initrd /boot/initramfs-3.3.0-8.fc17.x86_64.img
> title Fedora (3.3.0-1.fc17.x86_64)
> root (hd0,4)
> kernel /boot/vmlinuz-3.3.0-1.fc17.x86_64 rd.md=0 rd.lvm=0 rd.dm=0 KEYTABLE=us root=UUID=2962c4ca-9c1a-4fe5-9548-1683437a9c06 SYSFONT=True rd.luks=0 ro LANG=en_US.UTF-8 rhgb quiet
> initrd /boot/initramfs-3.3.0-1.fc17.x86_64.img
]# gdisk /dev/sda
GPT fdisk (gdisk) version 0.8.2
Partition table scan:
BSD: not present
APM: not present
Found valid GPT with protective MBR; using GPT.
Command (? for help): p
Disk /dev/sda: 976773168 sectors, 465.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): FF759AE0-43F7-4034-96E5-F9C336FC3E85
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 2048-sector boundaries
Total free space is 693452781 sectors (330.7 GiB)
Number Start (sector) End (sector) Size Code Name
1 2048 206847 100.0 MiB EF00 EFI System Partition
<<note 1.0MiB freespace here: sectors 206848-208895>>
2 208896 188952575 90.0 GiB 0700
3 188952576 220409855 15.0 GiB 8200
4 220409856 251867135 15.0 GiB 0700
5 251867136 283324415 15.0 GiB 0700
This is repeatable, at least the part about forgetting the old boot. I deleted the partition sda5, deleted /boot/efi/EFI/redhat/mach_kernel and System/, restored the grub.conf with just a single entry for sda4, then did a fresh install from Beta-RC3-x86_64-DVD, re-creating sda5 as the target. The resulting grub.conf listed only the kernel for the newly-installed sda5, forgetting the previous system on sda4. mach_kernel and System/ were not re-created; could this be because I did not delete the empty directory grub2-efi before starting the re-install?
Anyway, I will attach the installer log files in case they help. Apparently the installer version on RC3 was 17.18, not 17.16.
Created attachment 575484 [details]
anaconda.log file from retry fresh install of sda5
Created attachment 575485 [details]
storage.log from retry fresh install of sda5
Created attachment 575486 [details]
program.log from retry of fresh install to sda5. Some boot info is at end.
What does the output from: cat /sys/class/dmi/id/chassis_vendor look like? We check it to see if it has 'apple' in it.
As far as sharing the same /boot/efi directory between installs, we don't support that -- a new copy of the grub.efi binary is written as well as a new grub.conf.
In general it isn't a good idea to share the directory since the grub binary would be overwritten by any newer install.
/sys/class/dmi/id/chassis_vendor says "Chassis Manufacture\n". Note the grammar mistake or length restriction: no ending 'r' on Manufacturer. This is a self-built box which has ASUS P8Z68-V motherboard.
Using Fedora-17-Final.TC2-x86_64-DVD.iso, the EFI/redhat/mach_kernel and System/ no longer appear.
Sharing /boot/efi is supported. It is an explicit choice in the Mount field of Create or Edit dialogs. The partition ID of _the_ [one only] EFI System Partition is recognized in the table of partitions. If sharing /boot/efi is not supported then there are problems: need a separate /boot/efi for each root, which is expensive because there are at most 15 partitions per drive. If grub.conf is not sharable, then need a separate one for each root filesystem, which means a separate /boot/efi for each OS, which means that chain loading must work in order to support multiple OS per box.
Overwriting grub.efi binary: backward compatibility is reasonably expected except for major version changes such as grub ==> grub2. Also grub.conf is not executable; grub.conf is data, which is immortal.