Bug 816238 - upgrade using boot.iso destroys EFI boot
upgrade using boot.iso destroys EFI boot
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Brian Lane
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F17Blocker/F17FinalBlocker
  Show dependency treegraph
 
Reported: 2012-04-25 11:19 EDT by John Reiser
Modified: 2012-05-02 16:22 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-02 16:22:34 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/anaconda/anaconda.log (11.50 KB, text/plain)
2012-04-25 11:19 EDT, John Reiser
no flags Details
anaconda.program.log (39.13 KB, text/plain)
2012-04-25 11:19 EDT, John Reiser
no flags Details
anconda.storage.log (89.15 KB, text/plain)
2012-04-25 11:20 EDT, John Reiser
no flags Details
anaconda.syslog (123.65 KB, text/plain)
2012-04-25 11:20 EDT, John Reiser
no flags Details
/boot/efi/EFI/redhat/grub.anacbak (1.52 KB, text/plain)
2012-04-25 11:25 EDT, John Reiser
no flags Details
/boot/efi/EFI/redhat/grub.conf (793 bytes, text/plain)
2012-04-25 11:28 EDT, John Reiser
no flags Details
/var/log/anaconda/anaconda.log (10.74 KB, text/plain)
2012-04-25 14:39 EDT, John Reiser
no flags Details
anaconda.program.log (39.04 KB, text/plain)
2012-04-25 14:40 EDT, John Reiser
no flags Details
anconda.storage.log (89.04 KB, text/plain)
2012-04-25 14:40 EDT, John Reiser
no flags Details
anaconda.syslog (123.59 KB, text/plain)
2012-04-25 14:41 EDT, John Reiser
no flags Details
/boot/efi/EFI/redhat/grub.conf (801 bytes, text/plain)
2012-04-25 14:42 EDT, John Reiser
no flags Details

  None (edit)
Description John Reiser 2012-04-25 11:19:17 EDT
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:
Comment 1 John Reiser 2012-04-25 11:19:42 EDT
Created attachment 580188 [details]
anaconda.program.log
Comment 2 John Reiser 2012-04-25 11:20:05 EDT
Created attachment 580189 [details]
anconda.storage.log
Comment 3 John Reiser 2012-04-25 11:20:31 EDT
Created attachment 580191 [details]
anaconda.syslog
Comment 4 John Reiser 2012-04-25 11:25:55 EDT
Created attachment 580193 [details]
/boot/efi/EFI/redhat/grub.anacbak

Previous grub.conf, preserved by anaconda as grub.conf.anacbak
Comment 5 John Reiser 2012-04-25 11:28:23 EDT
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.]
Comment 6 Gwyn Ciesla 2012-04-25 11:31:27 EDT
Assigning to correct component.
Comment 7 Adam Williamson 2012-04-25 12:36:13 EDT
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
Comment 8 John Reiser 2012-04-25 14:39:38 EDT
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.]
Comment 9 John Reiser 2012-04-25 14:40:22 EDT
Created attachment 580240 [details]
anaconda.program.log
Comment 10 John Reiser 2012-04-25 14:40:57 EDT
Created attachment 580241 [details]
anconda.storage.log
Comment 11 John Reiser 2012-04-25 14:41:27 EDT
Created attachment 580242 [details]
anaconda.syslog
Comment 12 John Reiser 2012-04-25 14:42:00 EDT
Created attachment 580244 [details]
/boot/efi/EFI/redhat/grub.conf
Comment 13 Tim Flink 2012-04-26 13:09:02 EDT
(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
Comment 14 John Reiser 2012-04-30 13:27:57 EDT
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.
Comment 15 Tim Flink 2012-05-01 17:44:03 EDT
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.
Comment 16 John Reiser 2012-05-02 12:31:07 EDT
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."
Comment 17 Brian Lane 2012-05-02 14:39:21 EDT
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.
Comment 18 John Reiser 2012-05-02 15:09:58 EDT
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.
Comment 19 Brian Lane 2012-05-02 16:22:34 EDT
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.

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