-   Fedora (
-   -   How did FedUp do for you? (

ykahn 01-21-2013 09:19 AM

How did FedUp do for you?
What is your experience with the new Fedora Upgrade tool?
What should one be aware of when upgrading from Fedora 17 to Fedora 18?


syg00 01-21-2013 02:39 PM

Worked fine for me on a 32-bit dual-boot with XP. Fedora (grub2) owns the MBR on this system.
I am not at all happy with the direction taken re grub on this release - on several of my systems Fedora doesn't own the MBR, and the devs have made those systems more of a pain to upgrade. It won't be happening yet on those systems - I'll give it a month or two to settle down, and maybe wait for a refresh shipping.

ykahn 01-21-2013 03:18 PM

I hear there is trouble with the rpmfusion repo, Dropbox and Chromium.
Any of this happened to you?

PTrenholme 01-21-2013 05:55 PM

Shouldn't this thread be in the "Installation" Fedora sub-forum? Or has that been abandoned? :scratch: (Nobody's posted there for quite a while.)

So, my experience. First, on my HP Pavilon p6000 (An AMD 64-bit system, upgraded to 12Gb RAM and 5Tb of SATA storage on 3 drives.)

First, I tried fedup on a (working) F17 installed on a software RAID1 500Gb partition set. Results:
  1. The --network 18 told me that I needed to use the (nonexistent or undocumented) --enrepo (sp? - from memory) option to point to one containing the "boot image." (All the F18 repos had been located before the message was displayed, so the image could not be found in any of them.)
  2. So I downloaded the DVD, and tried the --iso option. Result: "The iso file in unusable." (However, the ISO file could be mounted as a loop device, and the check sum was correct.)
  3. Since the iso file was mountable, I tried the --file option. That seemed to work. Partially.
    1. The system booted only to a login prompt.
    2. The old F17 stuff was not removed and
    3. The new F18 files were not installed.
In order to get a usable system I had to:
  1. Add the missing Wants=display-manager.service to the /usr/lib/systemd/system/
  2. Made sure that the /usr/lib/systemd/system/ pointed to the
  3. Rebooted to a working GUI :D
  4. Run yum --dist-sync
  5. Run package-cleanup --dupes followed by package-cleanup --cleandupes --noscripts
After all that, I notice that there's a lot of left-over "sutff" in /usr/lib/systemd, but I haven't (yet) removed it.

I was able to do all that since I had another, working, F18 on the same hardware. (Soon to be a F19 system, but that's another story.) That let me use krusader to compare the working system's file with the "bonked" one. (I run a kde system since I prefer a screen with no icons on it, and that configuration is easier -- for me -- to set up with kde.)


With all that behind me, I decided to try fedup on my old Dell Inspiron 8600 laptop (An I686 system upgraded to 2Gb RAM and 500Gb storage. The result:
  • fedup ran with no problems, although it took several hours to complete. (The upgrade described above took a few days, so a few hours is a good thing, eh?)
  • Rebooting the system using the 3.7.2-201 or 3.7.2-204 kernel worked, but the vt font settings --or something -- are completely wrong, and even a simple terminal is unreadable. (This is true even if the headless boot option is added to the linux line.)
  • Rebooting with the 3.6.11 kernel (left over from the F17 that was running on the system before the upgrade) produces a usable GUI

I'm still trying to get the laptop to boot with the 3.7 kernels, but I haven't yet posted a bug against the 3.7 kernel. In fact, if anyone has any suggestions, I like to have them. <edit>See below</edit>

(By the way, the grub2 boot menus displays fine, but everything after the iniramfs starts is displayed as a big white "blob," and the X display is, basically, solid white with vertical lines on it.)

Oh, the video controller in the laptop is an old nVidia GeForce on-board one, which, as I said, works fine with the 3.6 kernel, but not any 3.7 one I've tried. I did try the nvivia-173 drives, but they didn't make any difference, so I'm fairly sure that the nouveau driver is O.K. on the system, and the problem is that 3.7 is not using the correct VT settings, but I don't (yet) know how to fix it.

Well, after more investigation, I think my problem is the nouveau driver. The driver is shipped with the kernel package, and the ones shipped with every F18 kernel I've tried - including the old 3.6.10-4 kernel shipped with the KDE spin LiveCD ISO - reports PTIMER: unknown input clock freq. I've entered a bug report on the Fedora bugzilla against xorg-x11-dvr-nouveau.

ykahn 01-27-2013 05:18 AM


Upgraded to Fedora 18 both on my home and work machines.

* Dropbox repository for F-18 is indeed missing (just disabled it ...)
* For multilingual users - language switcher key shortcut wasn't preserved and couldn't be set via the system settings program. Had to use gnome-tweak-tool (see here:
* Apache configuration has changed. It'll keep your old configuration and just fail ... I just renamed httpd.conf.rpmnew to httpd.conf (back it up first!) and fixed issues as per my server (e.g. UerDir definitions moved to conf.d/userdir.conf)

scoon 01-28-2013 08:44 PM

I have a dell inpiron 1545 and fedup'd with no show stopper. I do think moving forward, I'll try and upgrade versions one behind. So, I won't install 19 until 20 comes out. I think that now, but I'm sure the upgrade bug will bite......

All times are GMT -5. The time now is 06:31 AM.