On Fri, 2010-10-08 at 11:57 -0400, Bill Nottingham wrote: > Chris Lumens (clumens@xxxxxxxxxx) 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
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
