[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Anaconda upgrades and bootloader options



Greetings,

During testing of Fedora 13, the Fedora QA team identified a gap in our
test matrix related to text-mode upgrades.  Specifically,
http://bugzilla.redhat.com/590823 highlighted a failure when performing
text-mode upgrades and attempting to create a new bootloader.  

While discussing [1] how best to cover the gap for future releases, the
QA team and Chris Lumens came to the conclusion that it's not clear what
the difference is between the different bootloader upgrade options
offered during an anaconda upgrade (see
http://docs.fedoraproject.org/en-US/Fedora/13/html-single/Installation_Guide/index.html#sn-upgrading-bootloader-x86).
 
     1. Create new boot loader configuration
              * I believe this is understand, it installs a new grub
                stage#1 into the MBR (or partition).  
              * In the days of lilo and grub, perhaps this offered a
                choice of bootloaders?
     2. Update boot loader configuration
              * does not run grub-install
              * When the kernel package is upgraded, it will call
                'new-kernel-pkg' from it's %scripts and this eventually
                updates the existing bootloader configuration file (e.g.
                grub.conf, yaboot.conf, elilo.conf, zipl.conf).
     3. Skip boot loader updating
              * does not run grub-install
              * When the kernel package is upgraded, it will call
                'new-kernel-pkg' from it's %scripts and this eventually
                updates the existing bootloader configuration file (e.g.
                grub.conf, yaboot.conf, elilo.conf, zipl.conf).

The open question from Fedora QA [1] is, is there value in presenting
options#2 and options#3?  From what we can tell, they result in the same
upgraded system.

Thanks,
James

[1] https://fedorahosted.org/fedora-qa/ticket/86

Attachment: signature.asc
Description: This is a digitally signed message part


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]