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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
