doesn't updating from Fedora 12 to rawhide work via preupgrade?

[marko]

I wanted to update my currently updated Fedora 12 x86-64 to Rawhide Fedora 13 by using preupgrade but it always fails at a popup "Failed to download installer data. This could be caused by a missing network connection or a bad mirror".

My df -haT says:

/dev/sda1 ext4 291M 44M 233M 16% /boot

so there should be plenty of /boot space free (233MB)

I can hit the Retry button over and over and it never finds a good one.

The preupgrade wiki suggests that it's ok to use preupgrade to update from F12 to Rawhide so is there a problem with the mirrors tonight?

I could do it the yum update way pointing to rawhide but I'd prefer to do it with preupgrade unless that won't work.

[CSchwangler]

Preupgrade never worked for me, with different error messages that mostly occured during the operation. I always prefer to use the yum way, since that seems to work better for me.

[Kaboon]

I've been wondering this too (I got the same issue), but it seems more like a mirror problem to me.

Apparently there are two mirrors that provide an installer image, ftp.freepark.org and ftp.cc.uoc.gr. Preupgrade will fail on a "No more mirrors to try" error for me.

marko, when you run preupgrade from the commandline, what does it tell you? Just asking, because the Preupgrade is giving me the same error message on it's front-end.

Preupgrade generally works fine for me.

[marko]

I did a :

yum update --disablerepo=* --enablerepo=rawhide,rpmfusion-free-rawhide,rpmfusion-nonfree-rawhide

I had to uninstall my netbeans and a couple ibus packages: ibus-rawcode and ibus-chewing

to get it to update but it worked.

[AdamW]

There's some changes to the way Rawhide works during F13 cycle which haven't been reflected in preupgrade yet. Particularly, we aren't generating installer images daily for the next release until after the Alpha stage, so preupgrade has simply had no F13 installer to use. There have been points at which we've done installer builds to run our automated test suite (RATS) on them, and had any of those passed we would've uploaded it somewhere as a 'last known good' installer build, and maybe patched preupgrade to work with it. But none of them _did_ pass, so it was a bit academic. I think what happens next is the Alpha comes out, and then preupgrade will either magically start working or we'll ship an update to tweak it for the post-F12 era.

Has anyone filed a bug?

[planetf1]

With the alpha getting closer, is there any news on the pre-upgrade front?

In the past I've usually updating during alpha or beta timeframes, and pre-upgrade has rarely been completely smooth. However it's never gone that wrong -- typically the only issue has been with old release rpms that I've had to manually upgrade (and resolve dependencies for) manually.

Am I right in thinking that with pre-upgrade the upgrade should be fairly seamless?

If instead of pre-upgrade I booted off media and upgraded through anaconda the end result should be fairly similar, I just loose on "down-time" whilst booted off cd?

If instead I just updated with "yum" (see http://fedoraproject.org/wiki/YumUpgradeFaq) it may well work, but there'll probably be an element of fiddling to resolve dependencies & I could get temporarily thwarted by glibc issues etc?

Scarily I have a fairly newly-installed system, backed up, and running btrfs. I've tried the latest alpha RCs and they look viable on the hw. I'm toying with the idea of taking a btrfs snapshot (to try that feature) & then running an upgrade, most likely a regular anaconda update.

For that scenario pre-upgrade doesn't really add anything?

---------- Post added at 03:03 PM CST ---------- Previous post was at 02:59 PM CST ----------

Looking at the alpha/beta criteria, "upgrade" of either type is clearly a BETA goal not an alpha goal. Whilst I have a backup plan perhaps I'll wait and see how others get on, but may flip to beta

[CiaW]

While I was installing the i386 netinstall of F13 (pre-alpha) it didn't have an option for btrfs filesystem. I selected ext3 just because I felt like it, I have a rawhide x86_64 F13 install on another partition using ext4.

From this list (F13 Feature list) it looks like the System rollback with btrfs feature is 80% completed.

[GoinEasy9]

When RC2 and RC3 didn't install last week, I installed the fedora-release-13 app from the development/13 repo, then did a yum --nogpgcheck upgrade, and wound up with a working F13 system. The only problem I encountered was the User name was not present on the login screen. I could enter the User name and password after clicking other and was able to log on, so other than that yum update worked fine.

[AdamW]

planetf1: glad to see you found the criteria useful! indeed, upgrades are considered Beta stuff at present, we do not block the Alpha on upgrade problems, or do much upgrade testing with the Alpha.

[planetf1]

Last night, with a full backup, I thought I'd try an anaconda upgrade using RC4. I did also first create a btrfs snapshot of the main filesystem (/) on the disk. Only /boot (ext3) & paging are seperate partitions.

However apart from the boot menu (install or upgrade) at no point was I given an upgrade option -- only an install.

Just wondering why that might be
- intentionally disabled
- user error (since I've previously used yum or preupgrade)
- bug, perhaps due to use of btrfs

I couldn't see anything obvious in the anaconda log (which I don't have right now).

---------- Post added at 10:53 AM CST ---------- Previous post was at 07:01 AM CST ----------

Thought I'd try running preupgrade anyway. It ran cleanly from a GUI perspectiove, but I noticed a large number of errors on stderr/out - 718 lines to be precise

The yum cache directories for preupgrade, pre-upgrade-main contain a handful of rpms only, so I'd guess this has not worked correctly ;-)

[AdamW]

we don't really test the upgrade paths at alpha point, that's at beta point currently. So there's no expectation that it'll necessarily work. Using btrfs is certainly an additional complicating factor. At least Anaconda will not consider btrfs partitions unless you boot it with the 'icantbelieveitsnotbtr' parameter, AIUI.

[planetf1]

I decided to
a) check my backups ;-)
b) Take a btrfs snapshot (why not!)
c) Do a yum update

It all went very cleanly and uneventfully, with everything happily upgrading to f13 alpha levels.

I did disable updates-testing & enable updates with a vague intent of having a slightly more stable system .

Overall seems pretty good. Main grief so far (as usual) has been video drivers. Similar to the f12 .32 kernel, in .33 I'm struggling with dual-screens (dvi+lcd) on R600 chip. Today I disabled KMS, dual screens works fine.. except that breaks suspend.. Long term I'm hoping we may get some of the new power management features from .34 pulled into f13 -- currently this is a pain point.

I'll wait out for next kernel/ati update and then look at raising a defect if it persists.

[AdamW]

glad it worked!

it would be nice if you could enable updates-testing and use fedora-easy-karma - https://fedoraproject.org/wiki/Fedora_Easy_Karma - to provide feedback on the updates. The more people do this, the more reliable (hopefully!) we can make F13 for everyone

[planetf1]

Thanks for the pointer - will read up/take a look.