On Fri, 2009-11-13 at 09:35 -0500, Andy Gospodarek wrote:
On Thu, Nov 12, 2009 at 11:27:28PM -0500, Bill Nottingham wrote:
Toshio Kuratomi (a badger gmail com) said:
There are definitely workarounds available, but none that meet the criteria for preupgrade as an effortless upgrade option.
So I'm a bit confused by what is so hard here. preupgrade starts up, finds it can't store stage2, and then tells you that you'll need to have a wired connection to the internet if you want to use it. So you have to download stage2 when you reboot and you have to cart your laptop over to the router to plug it in while it does so... it's not like I'm going to be using it for work while anaconda is running....
Basically, the case where it fails is when there's enough space to download stage2, but not enough space left after downloading stage2 to do the upgrade.
Could we add some support to use a USB key as scratch space for any part of this process?
Not a bad idea. Not sure who would add this support and test it before Tuesday. Definitely something to consider as a future enhancement to preupgrade.
You could hand edit the stage2= line and point is to any non-lvm partition including a temporary usbkey. You would need to have a filesystem label on the usbkey, and change "Fedora" to be the name of your usbkey in the grub.conf file entry for preupgrade. Just make sure that the install.img resides in /images on the usbkey.
You could boot off the boot.iso and pass the needed options to anaconda, appending to the boot line does work with:
append initrd=initrd.img stage2=hd:LABEL="Fedora" preupgrade \ repo=hd::/var/cache/yum/preupgrade ks=hd:sda1:/upgrade/ks.cfg
Yea, I know ks=hd:sda1 is less that ideal, but if that is the /boot partition unless your playing bios games with the boot order, where else can it be but sda1? This could be added to the boot.iso in a stanza as an option much like rescue.
Just some thoughts,
Jerry
On Mon, 2009-11-16 at 01:33 -0600, Jerry Vonau wrote:
On Fri, 2009-11-13 at 09:35 -0500, Andy Gospodarek wrote:
On Thu, Nov 12, 2009 at 11:27:28PM -0500, Bill Nottingham wrote:
Toshio Kuratomi (a badger gmail com) said:
There are definitely workarounds available, but none that meet the criteria for preupgrade as an effortless upgrade option.
So I'm a bit confused by what is so hard here. preupgrade starts up, finds it can't store stage2, and then tells you that you'll need to have a wired connection to the internet if you want to use it. So you have to download stage2 when you reboot and you have to cart your laptop over to the router to plug it in while it does so... it's not like I'm going to be using it for work while anaconda is running....
Basically, the case where it fails is when there's enough space to download stage2, but not enough space left after downloading stage2 to do the upgrade.
Could we add some support to use a USB key as scratch space for any part of this process?
Not a bad idea. Not sure who would add this support and test it before Tuesday. Definitely something to consider as a future enhancement to preupgrade.
You could hand edit the stage2= line and point is to any non-lvm partition including a temporary usbkey. You would need to have a filesystem label on the usbkey, and change "Fedora" to be the name of your usbkey in the grub.conf file entry for preupgrade. Just make sure that the install.img resides in /images on the usbkey.
You could boot off the boot.iso and pass the needed options to anaconda, appending to the boot line does work with:
append initrd=initrd.img stage2=hd:LABEL="Fedora" preupgrade \ repo=hd::/var/cache/yum/preupgrade ks=hd:sda1:/upgrade/ks.cfg
Yea, I know ks=hd:sda1 is less that ideal, but if that is the /boot partition unless your playing bios games with the boot order, where else can it be but sda1? This could be added to the boot.iso in a stanza as an option much like rescue.
Just some thoughts,
Thanks for the input Jerry. Lot's of good ideas on how to manually work around the issue. The preupgrade target user is typically one who might not be fully comfortable with some of the manual workarounds on the table. Ideally, a preupgrade maintainer will be addressing a method to make this process more smooth for Fedora 13, but for now we're looking to avoid leaving the average user high-and-dry, and documenting suggested workarounds (as you've noted above) in the Common_F12_Bugs page.
Thanks, James
-
James Laska -
Jerry Vonau