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

Re: Anaconda upgrades and bootloader options



On Fri, 2010-10-08 at 11:57 -0400, Bill Nottingham wrote:
> Chris Lumens (clumens redhat com) said: 
> > Bootloader config in anaconda involves three distinct dispatcher steps:
> > 
> > (1) bootloadersetup.  This sets the list of which drives should be
> > considered for installing a bootloader to, picks the preferred one, and
> > looks for EFI system partitions.  This step is non-interactive.
> > 
> > (2) bootloader.  This displays the screen shown at
> > http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/s1-x86-bootloader.html
> > and sets variables all over the place based on the UI elements.  Most
> > importantly for this discussion, it controls setting which OS options
> > you'll have in the bootloader menu.  It does not, however, write any
> > changes to disk.
> > 
> > (3) instbootloader.  Given all the previous settings, this writes
> > grub.conf and device.map, and runs grub.  Or whatever's appropriate for
> > the platform.  This step is non-interactive.  It is also impossible to
> > follow.
> > 
> > You need to know those three steps to understand exactly what is
> > supposed to happen for each of the three bootloader upgrade options.
> > 
> > >      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?
> > 
> >             self.dispatch.skipStep("bootloadersetup", skip = 0)
> >             self.dispatch.skipStep("bootloader", skip = 0)
> >             self.dispatch.skipStep("instbootloader", skip = 0)
> >             self.bl.doUpgradeOnly = 0
> > 
> > So, this option will create a completely new grub.conf file and run grub
> > to install itself to wherever you say (mbr, partition, etc).  Whatever
> > the kernel's %post script does will have happened before we hit the
> > instbootloader step.
> > 
> > >      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).
> > 
> >             self.dispatch.skipStep("bootloadersetup", skip = 0)
> >             self.dispatch.skipStep("bootloader", skip = 1)
> >             self.dispatch.skipStep("instbootloader", skip = 0)
> >             self.bl.doUpgradeOnly = 1
> > 
> > This option will cause no changes to be written to grub.conf, but
> > grub-install will still be run.  Whatever the kernel's %post script does
> > will have happened before we hit the instbootloader step.
> 
> If I'm being really picky here, this might be better described as 
> 'Update boot loader', as it's not touching the configuration file. 

I don't think that's being picky, I think that is a reasonable
suggestion given the understanding of what is being done behind the
scenes.

> > Does that shed any light on the subject?  Are these three options at all
> > worth keeping?
> 
> What's the usage case for option #2? When would you *want* to run
> grub-install but not change other config options?

I'm still unclear on what the use case is for option#2.  I was guessing
that there may be potentially new stage#2 detection support in the newer
grub package ... and updating the stage#1 in the MBR will install the
new code, right?

But in practice, if you're upgrading an already installed system ...
you'd think it didn't have any problems locating the grub stage#2
partition.

Thanks,
James

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]