PSA: Use Fedup 0.8 for Fedora 20 upgrades

Welp, turns out there was one last (I hope!) brown paper bag bug for Fedora 20: fedup 0.7, which was in the Fedora 18 and 19 stable repos today, can't successfully upgrade to Fedora 20 any more. It certainly could last time we tested it, so this has blindsided us a bit, or else we'd have been better prepared!

Fedup 0.8, which is currently in updates-testing but will be in stable for Fedora 19 tomorrow and for Fedora 18 just as soon as we can get it pushed, can upgrade to Fedora 20 just fine. If you want to upgrade but haven't got around to it yet, just make sure you use fedup 0.8, and you'll be fine. Run 'yum --enablerepo=updates-testing update fedup' to get 0.8, or you can use the graphical package management tools to enable updates-testing, install fedup, then disable it again.

If you already tried with 0.7 and it failed, just upgrade to 0.8 and try again, but you may want to do 'mv /var/lib/fedora-upgrade /var/lib/system-upgrade' and 'mv /var/tmp/fedora-upgrade /var/tmp/system-upgrade' first (fedup's file download locations changed in 0.8, and this will save it needlessly re-downloading the upgrade packages, and make sure it cleans up after itself properly when it's done).

If you already had a failure with 0.7 and a success with 0.8, you might want to check for /var/lib/fedora-upgrade and /var/tmp/fedora-upgrade and wipe them if they exist - they won't hurt anything, but you don't need them and they're just wasting disk space.

Sorry for the mess, folks!


VK Joseph wrote on 2013-12-18 14:23:
My effort also failed with .7 but succeeded with .8
Robert Nunnally (gurdonark) wrote on 2013-12-18 16:24:
Thanks for this post, which explains why I spent hours last night trying to use FedUp to upgrade from F19 to F20, with lots of action but no upgrade. I had meant to wait a week or five to upgrade, but a little free time got the better of me. My effort to use updates-testing for fedup .8 did not work. I'll look forward to when FedUp .8 hits the stable, and give it another whirl in a few days. I'm sure it will all sort out, and in the meantime, F19 is still great. Your post helped, because it let me know where the issue lies. I know that getting a distro out must be a ton of work, and little things like this will happen sometimes.
rafhael almeida wrote on 2013-12-18 17:35:
thx for the news!
BubbaButch wrote on 2013-12-19 08:22:
I am so confused about where to get any chat support as the one on the Fedora Project website is at best not clear on how to register. Does anyone know wheen theya re actually going to get around to updating the stable repositories to include the correct version of fedup to upgrade from Fedroa 19 to 20 which should be .8 and not the .7 that is in there currently in stable ????
BubbaButch wrote on 2013-12-19 08:28:
Some people might think I am bitching, and not asking a question but if they had any real experiences with large scale software development they would know this mistake between fedup .7 and .8 is a documentation issue, and Project management as someone changed the location of files without tell all the users of the change. I am sorry if you think me pointing out just how sophomoric this mistake is amounts to bitching. Those are the facts that the community of users using fedup are second class citizens and that the people who made these changes are obviously from the crowd that believes as does Microsoft that a fresh install is normally the way to make version upgrades. Since when did this kind of Microsoft poor design become acceptable in the Linux Community ????
adamw wrote on 2013-12-19 08:44:
BubbaButch: the updates were intended to go stable today, they've been queued for stable since last night. releng has been running into problems doing the stable update pushes all day long, though. Always the way, problems come in packages. As soon as releng is able to get the stable update push processes working, they'll be there. I don't think your diagnosis of the cause of the issue is accurate. The fact that the file download location moved between fedup 0.7 and 0.8 is not actually the cause of fedup 0.7-based upgrade failing to work: I've tested that. (It's easy enough to test - run a 0.7 upgrade, and move the files before rebooting. It still fails). We haven't yet isolated the exact cause of the 0.7 failure, because ensuring 0.8 gets released ASAP and informing as many people as possible of the issue has been a higher priority - it doesn't matter so much why 0.7 broke, if we know 0.8 works and we just need to get it out to people. "and that the people who made these changes are obviously from the crowd that believes as does Microsoft that a fresh install is normally the way to make version upgrades" Um. The 'people who made these changes' are one person, the developer of fedup. He writes fedup because he cares about upgrades. If he didn't care about upgrades, he wouldn't be writing an upgrade utility. We're really sorry that this issue happened, but it didn't happen because we don't care. In fact, if anything the problem is that we care too much: we could just have shipped with the stuff from Beta, which was known to work in most cases, but we wanted to get the 0.8 builds of fedup and fedup-dracut used for Final because they fixed issues in several more complex cases, and provided the GPG verification for upgrades that many people have requested.
BubbaButch wrote on 2013-12-19 10:29:
Okay I tried a variant of the above and got the fedup .8 , and besides a few warning messages which were mostly related to Libreoffice I was able to run fedup and now I am on Fedora 20. I only say variant as I didn't do the command line as suggested above, and oh it would eb nice if support actually used the GUI tools that exist or is everyone just showing off always using command line and doing it the hard way ? It would be best for the newbies if the support wasn't always offered from an elitists perspective. So for the people more windows oriented I will show my steps below... run the Software GUI program, and click on the menu drop down, and select sources then click next to Fedora 19 testing then close. Now go back in like you are adding software and type fedup, and when the two optyions come up foirst delete fedup .7 then submit changes, and apply this change to dlete fedup .7 then go back and add fedup .8 ....this will now give you the most current version of fedup. You can now go back to sources, and unselect the testing so that the next time you do the Software Update function you will only get the Stable Updates. Then command line of "fedup --network 20 " can now be typed and should complete the update afterwards telling you to reboot agterwards the fedup will appear as the top of the various options under booting which you can run ang wait about 20 minutes for fedup to update all the modules. Good Luck and for theose that don't wanmt to wait until fedup .8 makes it into stable please feel free to ttype this work around..
rafhael almeida wrote on 2013-12-19 14:06:
====================================================================================================== Package Arquitectura Versión Repositorio Tamaño ====================================================================================================== Instalando: fedup noarch 0.8.0-3.fc19 updates 80 k Resumen de la transacción ====================================================================================================== Instalar 1 Paquete
adamw wrote on 2013-12-19 17:00:
Bubba: your comment actually nicely illustrates why we usually provide guidance using CLI commands: it's much shorter, clearer and less subject to confusion than trying to guide someone through a series of GUI clicks :) That's the only reason. We usually put a 'sudo' or an 'su -c' on the front, though, so you can just copy and paste; I should've done that.
Harm wrote on 2013-12-24 00:27:
I am using Fedora 17 and after downloading without errors it asks me to reboot and I do so. Then it will start the upgrade (added menu option) only to go to black screen and reboot in Fedora 17 again (no more upgrade menu option in grub2). Tried to update fedup to version 0.8 but it doesn't exist, enabled test and update repos but latest version is 0.7.
adamw wrote on 2013-12-24 00:59:
I'm afraid F17 is EOL and has been for some time. You're hitting the same bug people had with F18 and F19 at release time, but we really can't fix it any more, because we can no longer ship new packages for F17. It's stuck on fedup 0.7 forever. You have a few options. You could try installing the F18 fedup package: this is entirely untested, I've no idea if it would work. You could try upgrading to F18 with fedup 0.7, then F20 with fedup 0.8. You could try doing a yum update, but see and read both the 'general' instructions and all the 'release specific instructions' for 17-18, 18-19 and 19-20.
BubbaButch wrote on 2014-02-03 18:12:
Adam looking back at my comments, and your reply it still is very clear to me that you don't get my point. The truth is that Fedup 0.7 was still in the testing repo's several days after Fedora 20 was released, and in fact a friend of mine who works at the University Of Oklahoma called up several days later complaining of just how difficult it was to do an update. I told him of my work around I found, but he still thought this kind of tweaking shouldn't be necessary if Linux is to be a viable alternative to Windows. He makes some good points I think that the Linux Community should be a little less thin skinned, and arrogant about. I have known lots of arrogant programmers over the years who take any constructive critism as if it was unconstructive, and you insulted them personally. This explaination of using the CLI stuff reminds me of just such an instance where rather than admit most of the time the older users alienate the introdctory users by giving them instructions that they would not expect in a Microsoft Windows Environment so do not usually feel as comfportable using Command Line. The work around I came up with was all GUI, and a lot simpler than all the CLI stuff for a user experienced with Windows and GUI's. The answer is simple given the excellent interface of the Software Updater still used in Fedora 19 that allows you to pick the location of repository where you get the updates from you simply had to make one change long enough to update Fedup. This is impossible of course in the newer system used in Fedora 20 because someone obviously had to change something just for the sake of changing it. The old Irish Saying "Don't Change what Ain't Broken" applies here, or at least my Irish Grandfather used to say that all the time when he saw change that didn't add value or imporvements. In the older Software Update I could point toward the "testing" repositories, and then update Fedup to 0.8 then change it back to "stable" after the Fedup was updated then run Fedup again and it worked although it still generated some error messages about files not being in locations expceted of which most were related to LibreOffice. You too quickly pointed out I was wrong in order to defend your mistake, but yet you failed to explain why the Libreoffice still fails to find some files. I suggest you aren't so quick to dismiss anyones suggestions in the fuutre , and explaining the CLI is easier then GUI changes as everyone I told about changing the repositories to Testing from Stable long enouigh to update Fedup had no problem understanding how to do this in the GUI. The dropping of VirtualBox out of the Software Update, and forcing everyone to use KVM is yet another example of how the Linux Community seems to not want to make it was easy as they can for Windows Users to migrate. I get that VirtualBox is less capable than KVM, but for most users it is capable enough to allow them to install Windows under Linux to have access to their old familiar Windows Programs until they are more comfortable. There is also the issue that some things do yet work under Linux or have a GNU replacement yet. Yes GIMP is a fairly descent repalcement for Photoshop, and I haev been using Open Office for years, and yet there are still some programs I need to explore in more detail before ditching the windows versions. Octave should replace matLab, but somethingts such as Labview still need a windows machine for now. Hint Hint developers start on the GNU version of Labview. The Ham's could user a version of echolink that supportsd Server Mode not just client, and the list goes on, and on. The point is that I am not complaining what is missing in Linux so much as we should make it easier for migration by not doing things like getting rid of things like VirtualBox for intro users to use until we get all the stuff available that Windows does, adn then maybe having something as difficult to use as KVM would be okay. The various add on I have tried that attempt to make KVM easier such as Virt-Manager as still way more difficult to use that Oracle's VirtualBox. Fedroa 19 VirtualBox was supported, and worked with very little effort to install it. We are moving in the wrong direction as a community if we continue to do such things. The Amateur Radio or Ham Community saw their numbers start to shrink a few years back, and they probably would still be shrinking if it weren't for all the Survialist or Preppers who are waiting for the government to fall. The efforts I amke as a Ham are to bring a different group of users into the crowd that are the ones using newer technologies, and I am actively recruiting more educated and intelligent future Hams from the local college engineering programs. I am intentionlly staying away from using some of the older hams because of their eat the young attitudes toward newer technologies such as Low Power Hand Held Radio's. This could also be an excellent way to introduce new users to Linux if some of the learning curve could be avoided. The Linux+ test is based upon CLI so the classes taught at college are oriented that way, and totally ignore all the excellent GUI based Managemewnt Tools that exist so this anti-GUI attitude seems to be prelevant in many Linux Organizations. I am not a newbie to UNIX since I started on a X-TERM over twenty years ago, and yes my Lucent Class 5 Telephone switch was CLI on a version of UNIX developped for real time control called RTR (Real Time Relaible) which is where the Telco inouts into their own version of Linux came from since a Real Time Kernel will need certain enhancements which is why RTLinux isn't 100% compatable with Linux. In closing we have a huge opportunity to absorb lots of Windows XP Users now that they have gone EOL on that OS, but we will need to give them a path such as Cinnamon does in the GUI to make it easier to be productive immediately instead of force a learaning curve on them. The interest among college students in engineering is going to explode once they see that the Internet of Things is going to be running on ARM chips running Linux of some sort which is I am sure one of the reasons Redhat pushed for ARM to become a Primary Arch. Well taht and the fact they probably knew of AMD's plans to relqase a 64bit ARM Opteron the A1100 to repalce the existing x86 Opteron. The future is our as Linux/Unix users if we find a way to bring in the Windows Users painlessly by making more GUI stuff. BubbaButch
adamw wrote on 2014-02-03 18:30:
Y'know, if we're going to get personal: I worked almost non-stop through a weekend trying to help people with the fedup upgrade issue when it hit. I didn't *have* to. I'm perfectly within my rights to work 9-5 monday to friday and say 'screw you' to anything else. I think it's a bit rich to go around making unwarranted assumptions about other people's intentions in order to justify *you* calling *them* "thin skinned and arrogant". If you're going to make accusations like that, you ought to be damn sure you have clear and objective evidence, not unjustified extrapolations. I told you why I prefer to recommend CLI instructions. It is extremely rude to assume I'm lying to you about that, especially without a shred of proof. Perhaps your grandfather would agree, if you asked him. "The work around I came up with was all GUI, and a lot simpler than all the CLI stuff for a user experienced with Windows and GUI’s." But it only works if you have gnome-packagekit installed, which is not a safe assumption: there are over half a dozen desktops in Fedora, of which I think only two come with gnome-packagekit installed out of the box (GNOME and Cinnamon). KDE has apper, which has a different interface. Xfce and LXDE have yumex, which have a different interface. People who do non-graphical installs have no graphical package management tool available at all. "This is impossible of course in the newer system used in Fedora 20 because someone obviously had to change something just for the sake of changing it." Again, you are making unwarranted assumptions. This is entirely untrue. "but yet you failed to explain why the Libreoffice still fails to find some files." This was not what the LibreOffice errors were about, and they had nothing to do with the upgrade process per se. It was simply due to a LibreOffice reaching 'stable' status for Fedora 19 faster than it did for Fedora 20, so for a couple of days, the LO package in stable for F19 was newer than the one in stable for F20. When that happens, it often causes package managers to print some kind of warning. The LO warning did not prevent an upgrade completing successfully. "The dropping of VirtualBox out of the Software Update, and forcing everyone to use KVM...Fedroa 19 VirtualBox was supported, and worked with very little effort to install it." VirtualBox is not in the Fedora repositories at all and never has been. This is because it relies on a kernel module that is not a part of the upstream kernel, and never would be accepted as a part of the upstream kernel, as the kernel developers do not agree with its design. Fedora does not accept this kind of kernel module. VirtualBox is in RPM Fusion, which is a third party repository. Fedora is not responsible for RPM Fusion, its contents, or its update schedule.