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 > CentOS > CentOS Development

 
 
LinkBack Thread Tools
 
Old 12-01-2009, 02:35 PM
Chris Lumens
 
Default PATCH fix 510970, 529551, 530541

> Thanks for also reviewing this, the second (third) pair of eyes is
> appreciated. I do have one question though. The first patch of the
> latest sets removes /boot/upgrade/install.img, which is a good thing
> to do as that frees precious /boot place before starting the upgrade,
> but if we do that why not just completely rm -fr /boot/upgrades ?

preupgrade also puts the kickstart file, initrd, and kernel in
/boot/upgrade. We probably don't want to remove any of those until
post-upgrade.

In fact now that I think about it, I'm not sure removing
/boot/upgrade/install.img so early is great either. Note that we will
be removing it when the doBackendSetup step is called, which is before
we do anything with packages. If for some reason you run into a problem
with package upgrades, when you reboot, fix it, and reboot back into
anaconda you will no longer have a stage2 image. This will result in
either anaconda downloading it again or you having to run preupgrade
again.

Either way, you're downloading stuff you thought were already taken care
of.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 12-01-2009, 03:02 PM
Hans de Goede
 
Default PATCH fix 510970, 529551, 530541

Hi,

On 12/01/2009 04:35 PM, Chris Lumens wrote:

Thanks for also reviewing this, the second (third) pair of eyes is
appreciated. I do have one question though. The first patch of the
latest sets removes /boot/upgrade/install.img, which is a good thing
to do as that frees precious /boot place before starting the upgrade,
but if we do that why not just completely rm -fr /boot/upgrades ?


preupgrade also puts the kickstart file, initrd, and kernel in
/boot/upgrade. We probably don't want to remove any of those until
post-upgrade.

In fact now that I think about it, I'm not sure removing
/boot/upgrade/install.img so early is great either. Note that we will
be removing it when the doBackendSetup step is called, which is before
we do anything with packages.


If we already remove it before yum checks to see if there is enough
freespace there, then indeed that part of this patch set should be dropped.

Regards,

Hans

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 12-02-2009, 12:16 AM
Jerry Vonau
 
Default PATCH fix 510970, 529551, 530541

On Tue, 2009-12-01 at 10:35 -0500, Chris Lumens wrote:
> > Thanks for also reviewing this, the second (third) pair of eyes is
> > appreciated. I do have one question though. The first patch of the
> > latest sets removes /boot/upgrade/install.img, which is a good thing
> > to do as that frees precious /boot place before starting the upgrade,
> > but if we do that why not just completely rm -fr /boot/upgrades ?
>
Think that could be done.

> preupgrade also puts the kickstart file, initrd, and kernel in
> /boot/upgrade. We probably don't want to remove any of those until
> post-upgrade.
>
Everything there is in memory when anaconda runs.

> In fact now that I think about it, I'm not sure removing
> /boot/upgrade/install.img so early is great either. Note that we will
> be removing it when the doBackendSetup step is called, which is before
> we do anything with packages. If for some reason you run into a problem
> with package upgrades,
>

Then you have a problem yes, but is that an anaconda problem? You would
have to have some yum/rpm problem right? While file corruption is
possible, the only repo in use was created by preupgrade. Your dealing
with what amounts to a "custom repo", created with whatever repos are
enabled when preupgrade was run. I think it would be its job to ensure
that the upgrade would be successful.

> when you reboot, fix it, and reboot back into
> anaconda you will no longer have a stage2 image. This will result in
> either anaconda downloading it again or you having to run preupgrade
> again.
>

Well, I think you should have to re-run preupgrade, think it was meant
to be a "one shot use" supporting offline upgrades. You have to re-run
it now to use Method 2 of the workarounds on the Wiki, to pickup the
change in the size of /boot. Of course you can just edit grub.conf and
use what you want there, if you remember to remove the install.img
from /boot/upgrade.

> Either way, you're downloading stuff you thought were already taken care
> of.
>

Fair enough, if your tight for space, preupgrade could now be using http
for install.img anyway. How about making the removal conditional on
if /boot is less than the current default size for /boot or available
space on /boot less than 50MB?

Thanks for the feedback,

Jerry



_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 12-02-2009, 11:12 AM
Hans de Goede
 
Default PATCH fix 510970, 529551, 530541

On 12/02/2009 02:16 AM, Jerry Vonau wrote:

On Tue, 2009-12-01 at 10:35 -0500, Chris Lumens wrote:

Thanks for also reviewing this, the second (third) pair of eyes is
appreciated. I do have one question though. The first patch of the
latest sets removes /boot/upgrade/install.img, which is a good thing
to do as that frees precious /boot place before starting the upgrade,
but if we do that why not just completely rm -fr /boot/upgrades ?



Think that could be done.


preupgrade also puts the kickstart file, initrd, and kernel in
/boot/upgrade. We probably don't want to remove any of those until
post-upgrade.


Everything there is in memory when anaconda runs.


In fact now that I think about it, I'm not sure removing
/boot/upgrade/install.img so early is great either. Note that we will
be removing it when the doBackendSetup step is called, which is before
we do anything with packages. If for some reason you run into a problem
with package upgrades,



Then you have a problem yes, but is that an anaconda problem? You would
have to have some yum/rpm problem right? While file corruption is
possible, the only repo in use was created by preupgrade. Your dealing
with what amounts to a "custom repo", created with whatever repos are
enabled when preupgrade was run. I think it would be its job to ensure
that the upgrade would be successful.


when you reboot, fix it, and reboot back into
anaconda you will no longer have a stage2 image. This will result in
either anaconda downloading it again or you having to run preupgrade
again.



Well, I think you should have to re-run preupgrade, think it was meant
to be a "one shot use" supporting offline upgrades. You have to re-run
it now to use Method 2 of the workarounds on the Wiki, to pickup the
change in the size of /boot. Of course you can just edit grub.conf and
use what you want there, if you remember to remove the install.img
from /boot/upgrade.


Either way, you're downloading stuff you thought were already taken care
of.



Fair enough, if your tight for space, preupgrade could now be using http
for install.img anyway. How about making the removal conditional on
if /boot is less than the current default size for /boot or available
space on /boot less than 50MB?



Hi Jerry,

If I understood Chris correctly we already remove /boot/upgrades before we
enter the part of the installer where the amount of freespace in /boot matters,
so your patch should not make a difference. If it does then we are currently
not doing what Chris thinks we are doing. So for this part of your patchset
it would be good to find out where and when exactly /boot/upgrades is getting
cleared with the current code, and if that is too late, move the clearing, instead
of adding pretty much the same clearing code a second time.

Regards,

Hans

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 12-02-2009, 02:33 PM
Jerry Vonau
 
Default PATCH fix 510970, 529551, 530541

On Wed, 2009-12-02 at 13:12 +0100, Hans de Goede wrote:

>
> Hi Jerry,
>
> If I understood Chris correctly we already remove /boot/upgrades before we
> enter the part of the installer where the amount of freespace in /boot matters,
> so your patch should not make a difference. If it does then we are currently
> not doing what Chris thinks we are doing.

Maybe I'm just blind but I can't find any reference to removing
install.img from /boot/upgrade in the anaconda sources.

> So for this part of your patchset
> it would be good to find out where and when exactly /boot/upgrades is getting
> cleared with the current code, and if that is too late, move the clearing, instead
> of adding pretty much the same clearing code a second time.
>

I fully agree, why reinvent the wheel, but I can't see where
that should be happening, hence the patch. I believe the only
place that /boot/upgrade is touched is in the %post part of
preupgrade's kickstart file.

Jerry



_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 12-04-2009, 11:25 AM
Hans de Goede
 
Default PATCH fix 510970, 529551, 530541

On 12/02/2009 04:33 PM, Jerry Vonau wrote:

On Wed, 2009-12-02 at 13:12 +0100, Hans de Goede wrote:



Hi Jerry,

If I understood Chris correctly we already remove /boot/upgrades before we
enter the part of the installer where the amount of freespace in /boot matters,
so your patch should not make a difference. If it does then we are currently
not doing what Chris thinks we are doing.


Maybe I'm just blind but I can't find any reference to removing
install.img from /boot/upgrade in the anaconda sources.


So for this part of your patchset
it would be good to find out where and when exactly /boot/upgrades is getting
cleared with the current code, and if that is too late, move the clearing, instead
of adding pretty much the same clearing code a second time.



I fully agree, why reinvent the wheel, but I can't see where
that should be happening, hence the patch. I believe the only
place that /boot/upgrade is touched is in the %post part of
preupgrade's kickstart file.



Chris,

Can we have your input on this please ?

Thanks,

Hans



Jerry



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


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 12-09-2009, 05:10 PM
Chris Lumens
 
Default PATCH fix 510970, 529551, 530541

> If it does then we are currently
> not doing what Chris thinks we are doing.

You know, maybe one day someone will believe I actually know what I'm
doing. I guess we're not there quite yet.

> So for this part of your patchset
> it would be good to find out where and when exactly /boot/upgrades is getting
> cleared with the current code, and if that is too late, move the clearing, instead
> of adding pretty much the same clearing code a second time.

anaconda does not remove /boot/upgrade (no 's') at any time. However if
you look at the discussion we were just having, you will see that you
wrote:

> Thanks for also reviewing this, the second (third) pair of eyes is
> appreciated. I do have one question though. The first patch of the
> latest sets removes /boot/upgrade/install.img, which is a good thing
> to do as that frees precious /boot place before starting the upgrade,
> but if we do that why not just completely rm -fr /boot/upgrades ?

My reply was that implementing your suggestion to completely remove
/boot/upgrade was a bad idea. I have no idea how you guys got started
thinking that I was saying we already do this.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 12-09-2009, 05:11 PM
Chris Lumens
 
Default PATCH fix 510970, 529551, 530541

Can you please post a link to the current state of your patch one more
time? I might just commit it as-is. I'm not sure I really care about
the install.img deleting thing.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 12-10-2009, 02:36 AM
Jerry Vonau
 
Default PATCH fix 510970, 529551, 530541

On Wed, 2009-12-09 at 13:11 -0500, Chris Lumens wrote:
> Can you please post a link to the current state of your patch one more
> time? I might just commit it as-is. I'm not sure I really care about
> the install.img deleting thing.
>
> - Chris

http://members.shaw.ca/jvonau/pub/F12/

0001-0005 are what I have working, 0006 is testing/work in progress.

Jerry


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 12-11-2009, 02:58 PM
Chris Lumens
 
Default PATCH fix 510970, 529551, 530541

> > Can you please post a link to the current state of your patch one more
> > time? I might just commit it as-is. I'm not sure I really care about
> > the install.img deleting thing.
> >
> > - Chris
>
> http://members.shaw.ca/jvonau/pub/F12/
>
> 0001-0005 are what I have working, 0006 is testing/work in progress.

My one complaint remains with 0004 that I don't think freetmp is a
YumBackend-specific method and should be put somewhere where all
backends can make use of it. I wonder if it could be merged with
backend.removeInstallImage.

Once this is addressed, I'm all for committing.

- Chris

_______________________________________________
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 12:58 AM.

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