FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Packaging

 
 
LinkBack Thread Tools
 
Old 09-29-2010, 07:35 PM
James Laska
 
Default 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
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 09-29-2010, 08:04 PM
John Reiser
 
Default Anaconda upgrades and bootloader options

> http://docs.fedoraproject.org/en-US/Fedora/13/html-single/Installation_Guide/index.html#sn-upgrading-bootloader-x86).
> Choices:
> 1. Create new boot loader configuration

> 2. Update boot loader configuration

> 3. Skip boot loader updating

> 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.

>From the viewpoint of the end user, there are three different choices:

1. Install new GRUB via grub-install. This overwrites MBR. This
puts the other GRUB files onto /boot. This updates any existing
/boot/grub/grub.conf (else creates initial grub.conf.)

2. Leave MBR the same. Leave GRUB software the same. Update grub.conf
(or create grub.conf if none exists.)

3. Leave MBR the same. Leave GRUB software the same. Leave grub.conf the same.

I am in category 3. Do not create or modify *ANYTHING* related to booting:
not the MBR, not the GRUB software, not grub.conf. GRUB refuses to understand
my boot setup, so I handle it by myself.

Both 1. and 2. update existing grub.conf if any, else create the first grub.conf.

--

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 09-29-2010, 08:20 PM
James Laska
 
Default Anaconda upgrades and bootloader options

On Wed, 2010-09-29 at 13:04 -0700, John Reiser wrote:
> > http://docs.fedoraproject.org/en-US/Fedora/13/html-single/Installation_Guide/index.html#sn-upgrading-bootloader-x86).
> > Choices:
> > 1. Create new boot loader configuration
>
> > 2. Update boot loader configuration
>
> > 3. Skip boot loader updating
>
> > 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.
>
> >From the viewpoint of the end user, there are three different choices:
>
> 1. Install new GRUB via grub-install. This overwrites MBR. This
> puts the other GRUB files onto /boot. This updates any existing
> /boot/grub/grub.conf (else creates initial grub.conf.)
>
> 2. Leave MBR the same. Leave GRUB software the same. Update grub.conf
> (or create grub.conf if none exists.)
>
> 3. Leave MBR the same. Leave GRUB software the same. Leave grub.conf the same.

I thought that's how it worked too. However, in our testing, #3 results
in updated grub.conf when the new kernel is installed on the system.
This isn't anything anaconda controls, this is managed by the %scripts
of the kernel package itself.

> I am in category 3. Do not create or modify *ANYTHING* related to booting:
> not the MBR, not the GRUB software, not grub.conf. GRUB refuses to understand
> my boot setup, so I handle it by myself.
>
> Both 1. and 2. update existing grub.conf if any, else create the first grub.conf.
>

Thanks,
James
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 10-07-2010, 08:07 PM
Chris Lumens
 
Default Anaconda upgrades and bootloader options

Maybe staring at the code will be helpful (but I doubt it, our
bootloader code is not our finest hour).

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.

> 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).

self.dispatch.skipStep("bootloadersetup", skip = 1)
self.dispatch.skipStep("bootloader", skip = 1)
self.dispatch.skipStep("instbootloader", skip = 1)

This option will cause anaconda to not do anything involving the
bootloader at all. Whatever the kernel's %post script does will still
happen, though.

Does that shed any light on the subject? Are these three options at all
worth keeping?

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 10-08-2010, 03:57 PM
Bill Nottingham
 
Default Anaconda upgrades and bootloader options

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.

> 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?

Bill

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 10-08-2010, 04:28 PM
James Laska
 
Default 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
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 10-08-2010, 05:14 PM
Chris Lumens
 
Default Anaconda upgrades and bootloader options

> > > 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.

That is picky, but more correct, yes.

> What's the usage case for option #2? When would you *want* to run
> grub-install but not change other config options?

You want to update the installation of grub on the system to take
advantage of whatever changes have been made to the package, but don't
want to touch any of your configs? I dunno.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 10-08-2010, 07:47 PM
Bill Nottingham
 
Default Anaconda upgrades and bootloader options

Chris Lumens (clumens@redhat.com) said:
> > > 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.
>
> That is picky, but more correct, yes.
>
> > What's the usage case for option #2? When would you *want* to run
> > grub-install but not change other config options?
>
> You want to update the installation of grub on the system to take
> advantage of whatever changes have been made to the package, but don't
> want to touch any of your configs? I dunno.

It would seem that this second option is equivalent to choosing the first
option, and just picking whatever values you picked when you first installed
it. Allowing the user *on upgrade* to choose option #1 and choose a
different place is just offering them a way to break their system, isn't
it?

Bill

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 

Thread Tools




All times are GMT. The time now is 09:07 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org