Created attachment 580187 [details] /var/log/anaconda/anaconda.log Description of problem: Upgrading Fedora 17 Beta x86_64 using http://tflink.fedorapeople.org/iso/20120424_f17-preTC1-3.x64.boot.iso creates a mess with existing EFI boot. Version-Release number of selected component (if applicable): anaconda 17.22 How reproducible: Steps to Reproduce: 1. EFI boot 20120424_f17-preTC1-3.x64.boot.iso from DVD for Upgrade of existing Fedora 17 Beta x86_64 (which had been partially upgraded by yum, but there were still 74 packages with newer versions.) 2. Keep existing bootloader config 3. Otherwise choose default options. Actual results: 1. Bootloader config is re-written despite request to "Keep existing ..." 2. /boot/efi/EFI/redhat/grub.conf has only one stanza (for upgraded kernel-3.3.2-8). This was an Upgrade, so former stanzas should still be present. 3. bootloader is upgraded to something that gives "Error 15: file not found" or drops to "grub rescue>". 4. No documentation or "help" command in grub rescue. 5. boot.iso does not contain grub*-install, thus bootloader cannot be fixed in the obvious way by running grub*-install. Expected results: No change to bootloader config. Old grub.conf stanzas are retained (this was an Upgrade, not a Fresh Install.) "grub rescue >" allows "help" (give list of commands). boot.iso contains grub*-install to re-install bootloader. Additional info:
Created attachment 580188 [details] anaconda.program.log
Created attachment 580189 [details] anconda.storage.log
Created attachment 580191 [details] anaconda.syslog
Created attachment 580193 [details] /boot/efi/EFI/redhat/grub.anacbak Previous grub.conf, preserved by anaconda as grub.conf.anacbak
Created attachment 580195 [details] /boot/efi/EFI/redhat/grub.conf Upgraded grub.conf. [Was modified during recovery attempts, but I think I got it back to the state immediately after the upgrade.]
Assigning to correct component.
Proposing as a release blocker, as anaconda is clearly doing something it shouldn't be doing here, and it violates the "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria" criterion. We sometimes say that 'leave bootloader untouched' upgrades don't violate this, but that's only in the case where the bootloader config actually *is* left untouched; in this case, it isn't. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 580239 [details] /var/log/anaconda/anaconda.log I have reproduced similar behavior in a simplified setup which other testers may be able to reproduce. All boots are EFI, both from DVD media and from harddrive installed system. I did a fresh install (including re-format EFI System Partition mounted on /boot/efi) of Graphical Desktop from Fedora-17-Beta-RC4-x86_64-DVD.iso [equal to Beta] then Upgraded using Fedora-17-Final.TC1-x86_64-DVD.iso I chose to Upgrade the immediately preceding fresh install, and "Skip boot loader updating". Some 320 packages were upgraded (about 1/4 of original install), including kernel. What I see now is that grub.conf is unchanged by the update (still refers to vmlinuz-3.3.0-1.fc17.x86_64 from Beta; and there is no grub.conf.anacbak), but the corresponding kernel and initramfs are no longer present in /boot; instead only kernel-3.3.2-8 and initramfs etc are in /boot. So this time my request to "Skip boot loader updating" kept grub.conf the same, but removed the files themselves (leaving dangling pointers) and did not insert any pointers to the new kernel. The result is that booting (which offers only the old 3.3.0-1) gives "Error 15: file not found". The Fedora-17-Final.TC1-x86_64-DVD.iso still has no grub*-install in its own initrd, so Rescue mode lacks this tool. [However just editing grub.conf may be enough in this case; I may not have to re-install grub.]
Created attachment 580240 [details] anaconda.program.log
Created attachment 580241 [details] anconda.storage.log
Created attachment 580242 [details] anaconda.syslog
Created attachment 580244 [details] /boot/efi/EFI/redhat/grub.conf
(In reply to comment #7) > Proposing as a release blocker, as anaconda is clearly doing something it > shouldn't be doing here, and it violates the "The installer must be able to > successfully complete an upgrade installation from a clean, fully updated > default installation (from any official install medium) of the previous stable > Fedora release, either via preupgrade or by booting to the installer manually. > The upgraded system must meet all release criteria" criterion. We sometimes say > that 'leave bootloader untouched' upgrades don't violate this, but that's only > in the case where the bootloader config actually *is* left untouched; in this > case, it isn't. +1 blocker
If I choose "Create a new bootloader configuration" during the Upgrade, then grub.conf has only one stanza (pointing to the new kernel), and the old kernel gets deleted from /boot. Thus running a previous kernel requires more than just selecting the old kernel during a reboot. Thus for EFI boot, somebody is not following the usual practice of "keep up to 3 total versions of kernel: the newest, plus up to 2 old versions". Perhaps /sbin/new-kernel-pkg (part of 'grubby' package) has a bug under EFI, or did anaconda invoke grubby improperly? This experiment was done using Fedora-17-Final.TC2-x86_64-DVD.iso upgrading from Graphical Desktop installed by Fedora-17-Beta-RC4-x86_64-DVD.iso More generally, I expect that several root partitions will each mount the same EFI System Partition under /boot/efi [serially, one-at-a-time, of course]. Therefore EFI/redhat/grub.conf will be shared among the different systems, so new-kernel-pkg must merge carefully and honor the "latest three versions of kernel" for each system.
Discussed in the 2012-05-01 blocker bug review meeting. This appears to be a blocker but we want to verify that this affects 16 -> 17 upgrades before accepting as a blocker. Please re-test as an upgrade from 16 to 17.
Yes, the same bad results happen when using Fedora-17-Final.TC2-x86_64-DVD.iso booted from DVD to Upgrade to Fedora 17 from fully-up-to-date Fedora 16, as when Upgrading from Fedora 17 Beta. (All boots are EFI, including from DVD.) Thinking about possible causes and fixes, one important piece is that EFI/redhat/grub.conf, when mounted beneath /boot/efi, is a shared resource: shared across multiple root partitions; mounted in each case at the respective /boot/efi. Thus modifying grub.conf is always a merge, unless the current instance of the installer formatted the EFI System Partition. In particular, any existing stanza in grub.conf that has a different root=UUID= must be retained and not modified. Also: when upgrading then retain the newest previous 2 stanzas that have the same root=UUID=, even for different versions such as Fedora 16 ==> 17. If booting the new kernel doesn't work, then attempting to boot an old kernel is still a semi-reasonable choice, although of course it may fail because of incompatible updates to various support programs. See also bug 809963, "EFI install from DVD forgets previous EFI boot."
This is not a bug, assuming comment 8 is the correct description, you skipped bootloader updating and it left it alone. Upgrade is for moving between releases, you shouldn't expect to keep the F16 kernels when upgrading to F17. If you skip bootloader updating then yes, you need to edit grub.cfg yourself. I've tested this with a straight F16->F17 upgrade and it works fine as long as you upgrade the bootloader.
I believe that there remains a bug [at least one], even when constrained to the situation described in Comment 8. Namely, I selected the radio button "Skip boot loader updating" but instead the installer did something related to boot loading that resulted in "unable to boot anything". The installer can predict with 100% accuracy that this will be the case, but did not give a warning. This is a Usability bug if nothing else. Also, the last paragraph of Comment 17 "straight upgrade F16->F17 and it works fine as long as you upgrade the bootloader" is not true in general. If EFI/redhat/grub.conf is mounted under /boot/efi and contains boot stanzas that relate to any other installed system on the same box [for different root filesystems, also mounted under the respective /boot/efi when booting those roots], then the upgrade deletes those stanzas, which unnecessarily destroys user data that is unrelated to the Upgrade. This is another Usability bug.
The point is that you have a customized setup and need to maintain it yourself. By skipping the bootloader upgrade you are saying that you will handle that part. The reason why you ended up being unable to boot is because you tried to use the same /boot/ and the old kernels were removed when the upgraded kernel was installed. As far as straight F16->F17 upgrades go, see my comments in bug 809963.