Bug 735730

I followed this test case:
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_Upgrade_New_Bootloader

I was upgrading F15 to F16 Beta TC1.

Proposing as Beta blocker:
> 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

Created attachment 521449 [details]
logs

Please attach logs as individual files.  Doing so makes it easier for us to search bugzilla in the future.

Created attachment 521589 [details]
storage.log

Created attachment 521590 [details]
program.log

Created attachment 521591 [details]
anaconda.log

Yes, I have upgraded to python-fedora 0.6.2, so that I can finally use 'bugzilla attach' command and don't have to do it all manually. Logs attached individually.

Created attachment 521672 [details]
anaconda.log

Created attachment 521674 [details]
program.log

Created attachment 521675 [details]
storage.log

I've reproduced this bug. You can find my logs attached above.

Discussed at 2011-09-09 blocker review meeting. Accepted as a Beta blocker under criterion "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". anaconda team, please take a look at this. looks like something is expecting grub2, when f15->f16 upgraded systems still have grub1, at a guess?

This bug is related to the fact that ugprades keep grub1 while installs get grub2.

This bug was also seen in f16-Beta.TC2-x86_64 arch test 2011-09-10

Seen in f16-Beta.TC2-i686 test 2011-09-10

I confirm this bug in the case where you do a clean install of F15 and immediately attempt to upgrade to F16, selecting 'install new bootloader configuration'. You only have two choices of what to do with the bootloader in an F16 upgrade:

1) 'skip bootloader configuration', which leaves you with an unbootable system as per https://bugzilla.redhat.com/show_bug.cgi?id=735785 . This seems to be by design, but still is no use for doing a stock F15 to F16 upgrade.

2) 'install new bootloader configuration', which causes you to hit this bug.

Note that 1) is the default choice, which doesn't seem like the best option now that 'update bootloader configuration' - the previous default - is unavailable. 2) is probably the correct default choice for most F15->F16 upgrades.

Seems like we have two basic options here:

a) make 'install new bootloader configuration' - i.e. migrate from grub1 to grub2, and hopefully get it right in most cases - the default, and fix it.

b) restore 'update bootloader configuration', make it the default again, and have it keep grub1 and update it to boot the f16 kernel. (and probably fix 'install new bootloader configuration' too.)

as things stand, there's no way to achieve a functional default f15->f16 upgrade via anaconda without manual intervention when it comes to the bootloader.

Related bug: https://bugzilla.redhat.com/show_bug.cgi?id=735785

add a higher-level summary to the description.

and the obligatory note that rc is due tomorrow or wednesday, and we need this fixed to some extent by then.

One more scenario to consider: preupgrade. Currently results in grub1 with the F15 kernel, no entry for the F16 kernel. The system does boot to the F15 kernel, and I expect the next attempt to install an F16 kernel would result in a bootloader entry being written.

I'll file a new bug for that.

https://bugzilla.redhat.com/show_bug.cgi?id=737731 filed for preupgrade case.

so, dlehman is working on this, and gave me http://dlehman.fedorapeople.org/updates-grub2.1.img to test. with a basic test, it looks good:

* installed a minimal F15 system, all defaults
* yum updated to latest F15
* did an upgrade install with F16 Beta TC2 + updates-grub2.1.img
* 'install new boot loader configuration' was the default choice
* upgrade completed successfully
* upgraded system booted successfully, using grub2, to an F16 kernel (rc3)
* 'yum upgrade kernel' on the upgraded system installed the rc5 kernel and correctly updated grub2's configuration
* the system correctly booted to the rc5 kernel on reboot

problems:

* after upgrade, both grub and grub2 are installed (despite them conflicting)
* the kernel upgrade printed the error "grubby fatal error: unable to find a suitable template" during post: I suspect this may have been while trying to update the grub1 config, which still exists

so it's a bit messy, but it seems to work.

anaconda-16.18-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/anaconda-16.18-1.fc16

(In reply to comment #21)
> * after upgrade, both grub and grub2 are installed (despite them conflicting)
Shouldn't grub2 obsolete grub1?
This will make sure only grub2 is installed.

No, as we need to use grub-legacy for EFI installs.

So we could rename grub to grub-legacy, and have grub2 obsolete grub (ie. before the rename), and add just add some code to make sure grub-legacy is installed on EFI systems.

yeah, that's a possibility, but we haven't really looked at it to make sure there's no other gotchas yet. maybe for final.

Package anaconda-16.18-1.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-16.18-1.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/anaconda-16.18-1.fc16
then log in and leave karma (feedback).

(In reply to comment #21)
> * the kernel upgrade printed the error "grubby fatal error: unable to find a
> suitable template" during post: I suspect this may have been while trying to
> update the grub1 config, which still exists

Isn't that fully explained by bug 735785#c32 - the new kernel is (for reasons unknown to me) not installed but updated, and the old kernel removes itself in its %preuninstall, so there _is_ no template to update. (Or actually there probably is ... Grubby refuses to write a config without any entries, but later on grubby also refuses to use the last entry because the vmlinuz it references no longer exists.)

Confirmed the fix in RC1: I was able to upgrade a fully updated default DVD install of F15 to F16 with all defaults, the upgraded system booted with the rc6 kernel.

The first boot of the upgraded system stalled, but further attempts worked fine, and that's not part of this bug anyway.

I got this with anaconda-16.18-1.fc16 when running from a custom live image, so in my opinion it has not been fixed.

My image was booted by grub2-efi, but there is no "boot loader installer" available, neither grub, grub2 nor grub2-efi. It is thus ok that liveinst fails and I have to install a bootloader somehow myself, but it shouldn't crash.

(In reply to comment #30)
> I got this with anaconda-16.18-1.fc16 when running from a custom live image, so
> in my opinion it has not been fixed.

The fix was to make sure grub2 gets installed on upgrades -- not to make it possible to do an install without any bootloader at all. For that you can file an RFE if you like, but it will likely be rejected.

> 
> My image was booted by grub2-efi, but there is no "boot loader installer"
> available, neither grub, grub2 nor grub2-efi. It is thus ok that liveinst fails
> and I have to install a bootloader somehow myself, but it shouldn't crash.

If you are going to compose images with no bootloader package you will need to patch anaconda to skip bootloader installation, perhaps via updates.img. We do not want anaconda to silently fail when no bootloader is available to install as this is typically a fatal error.

(In reply to comment #31)
> The fix was to make sure grub2 gets installed on upgrades

This was on an EFI system, so it would be a bug if it installed the grub2 package.

This was a live install without any network connection, so I wonder how it would be able to install grub2 (or grub or grub2-efi) at all.

> We do
> not want anaconda to silently fail when no bootloader is available to install
> as this is typically a fatal error.

I don't want anaconda to fail silently. I want anaconda to be robust and report fatal errors without crashing. I don't see how this error is different from other "There was an error installing the bootloader. The system may not be bootable." errors.

This ugly workaround hack worked for me and made it possible (with some manual work) to install an EFI system from updates-testing:

--- /usr/lib/python2.7/site-packages/pyanaconda/bootloader.py	2011-09-15 02:33:59.000000000 +0200
+++ bootloader.py	2011-09-16 17:02:34.487386478 +0200
@@ -2091,7 +2091,7 @@
 
     try:
         anaconda.bootloader.write(install_root=anaconda.rootPath)
-    except BootLoaderError as e:
+    except Exception as e:
         if anaconda.intf:
             anaconda.intf.messageWindow(_("Warning"),
                             _("There was an error installing the bootloader.  "

If your system is EFI anaconda should not be doing anything related to grub2 on your system. For EFI we still use grub-legacy. If you open a separate bug and attach your logs we can look into why your system is not being detected as EFI.

I reproduced with Fedora-16-Beta-TC-i686-Live-XFCE.iso to do an upgrade to a long time runned Fedora 14 system with grub1.

So my decision is to reinstall.

(In reply to comment #34)
Sorry, I meant Fedora-16-Beta-x86_64-netinst.iso

(In reply to comment #35)
Forget about my comments. RC1 works and installs grub2. Sorry for the noise.

anaconda-16.18-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

I may have encountered this bug with the official i386 DVD. I've tried to upgrade from my Fedora 15 and I'm stuck with this error during the process...

Erwan, why do think it was this bug you saw?

If you really did use the official final f16 DVD then you should file a new issue for that (unless somebode else already has done that). Make sure you attach anaconda.log and program.log.

I had seen the very same error message during my attempt to upgrade... As my computer is a netbook, I don't have a DVD drive and had made a Live USB from the official USB. It seems that this may also trigger an issue. I will have to make a complete backup of my current config before retrying...

I have retried and this time everything worked. I however made a slight change in the way I wrote my USB key: I used dd instead of live-iso-to-disk. My guess is that this is related to the automatic detection of the drive to which anaconda install the bootloader. It is triggered if I write my USB with livecd-iso-to-disk but not if I write it with dd...

Erwan: Please file a separate issue for that.

For the record, Erwan filed bug 752358.

I'd also like to note that I hit this same error message (while trying to do an F15 to F16 upgrade, on x86_64) due to my own error:  I was doing the upgrade from an ISO image of the DVD stored on a different partition, but I made the mistake of pointing the F16 installer (i.e., the DVD's vmlinuz and initrd.img) at the F15 ISO, when I should have updated my grub entry to point to the F16 ISO, i.e. I had failed to update the repo= line below (now updated):

title F16 Installer
        kernel (hd0,5)/F16-vmlinuz lang= devfs=nomount ramdisk_size=64000 repo=hd:LABEL=exthome1:/f16/ ip=192.168.XXX.XXX netmask=255.255.255.0 gateway=192.168.XXX.1 dns=192.168.XXX.1
        initrd (hd0,5)/F16-initrd.img

Upon a failed preupgrade attempt, due to bug 737508, when I tried using the F16 DVD installer to upgrade an installation that was already upgraded I received this bug.  I used the debug reporter to try to file a bug but it found this as a duplicate instead.  I have no logs, I have since installed from scratch.