Red Hat Bugzilla – Bug 372011
depsolve hang in F7 to F8 upgrade
Last modified: 2009-03-17 03:56:41 EDT
Description of problem:
The F8 install DVD hangs about a third of the way through the "Checking package
dependencies..." dialog (according to the progress bar) when attempting to
upgrade an x86_64 F7 system.
Steps to Reproduce:
1. Boot upgrade CD
2. Click buttons
I let it go for about 8 hours, during which anaconda used ~100% of one CPU for
the entire time and allocated almost all of system RAM before I gave up.
Created attachment 252271 [details]
Created attachment 252281 [details]
Representative strace output
This is a several seconds worth of stracing anaconda and appears to be a
representative sample of what it spent it's time doing the entire time. (I
straced it multiple times over the 8 hour interval, and it was always doing
roughly what's found in this log.)
Created attachment 252291 [details]
lsof on anaconda, to make the strace log more meaningful
Created attachment 252301 [details]
top and ps ax output on the system shortly before I killed it
Confirm bug on x86_64. Anaconda consumes 100% CPU and stalls at package
Just noticed that this is a duplicate of bug 371111. Looks like anaconda is
Upgrades are hard. Do you remember all you customizations? Added packaged from
non-Fedora repositories? NVIDIA/ATI drivers? Imagine how hard it is for
anaconda to work you custom stuff around.
I'm seeing identical behavior on i386 (Dell Inspiron 600m laptop). I have no
non-fedora packages on this system. I'm not using special Nvidia/ATI drivers,
just what comes with Fedora Core 7.
Same problem on a Dell Optiplex gx280. The F8 i386 install DVD hangs at
"Checking package dependencies..." when attempting to upgrade an i686 F7 system.
I have similar problem during graphical boot from install dvd. Viedo Card is
NVidia 6200. It works fine with F7 anaconda installer. Now I need to go to text
mode install (fresh).
Can you try the update image at
http://katzj.fedorapeople.org/updates-f8-yumloop.img and see if it resolves the
The use of update images is described at
Jeremy, your update image didn't help. anaconda still hangs at 26%.
I just tried the update image and it did not solve the problem for me. I see
exactly the same behavior as before.
Created attachment 253221 [details]
output from yum on fc7 demonstrating loop
I upgraded my yum on F7 from the F8 DVD and set up a yum.conf as follows:
# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d
and I ran
yum -v -c /tmp/yum.conf --disablerepo=\* --enablerepo=InstallMedia update
This is the output. It is looping in the same way that it does when run from
anaconda during the upgrade. I can provide a list of the packages I have
installed on this system if it would make any difference.
Perhaps this will help narrow it down. I tested a manual update (rpm -U --test
./*.rpm) in the Packages directory on the DVD and then proceeded to manually
erase offending packages. Eventually I was able to upgrade after removing the
mplayer and dependencies
vlc and dependencies (incl. compat-wxGTK)
gnome office and dependencies (gnucash, gnumeric, goffice04, libgsf-gnome)
inkscape, ImageMagick-c++, ImageMagick-perl, pstoedit
This is all. I hope those with similar problems could narrow it down to 1 or 2
packages by elimination.
This might have something to do with the problem..
Instead of using anaconda to upgrade to F8 I ran 'yum upgrade' using the F8
installation DVD as package source.
After a while it kept repeating "resolving dependencies" for a few packages, for
example "net-snmp-utils" -- which is _not_ included in F8 (it is included in the
So my thought is that the F8 installation dvd is incomplete and missing some
Having the same problems on x86_64 archs, but not on i386 machines, which have
too a lot of rpms installed not of kind *.fc7: anaconada loops after it has
processed 26% of the dependency checking.
Have the same problem on i386.
It just always stuck at 26% on "Checking package
Toshiba Satellite M45 S296
Same deal: hangs at about 25%-28% and does not recover ... ever (and I have
waited a long time).
I have tried all the tricks posted on various websites (most related acpi stuff)
but nothing helps. I have used/upgraded each release of Fedora from Fedora Core 3.
I am disappointed that this release is such a disaster.
anaconda hangs in postselection in F7 to F8 upgrade
From Fedora 7 (i386)
In directory Packages of DVD Fedora 8:
# rpm -Uvh fedora-release-*
# yum update
--> Running transaction check
--> Processing Dependency: gnutls = 1.6.3-2.fc7 for package: gnutls-utils
--> Processing Dependency: openoffice.org-writer = 1:2.3.0-6.4.fc7 for
--> Processing Dependency: kdemultimedia = 6:3.5.7-2.fc7 for package:
--> Processing Dependency: kdeutils = 6:3.5.7-1.fc7.1 for package:
--> Processing Dependency: libboost_python.so.2 for package: kdeedu
--> Processing Dependency: qt = 1:3.3.8-7.fc7 for package: qt-MySQL
--> Processing Dependency: openoffice.org-core = 1:2.3.0-6.4.fc7 for package:
--> Processing Dependency: openoffice.org-core = 1:2.3.0-6.4.fc7 for package:
--> Processing Dependency: openoffice.org-core = 1:2.3.0-6.4.fc7 for package:
--> Processing Dependency: tcp_wrappers-libs = 7.6-48.fc7 for package:
--> Processing Dependency: libmpcdec.so.3 for package: audacious-plugins
--> Processing Dependency: libmpcdec.so.3 for package: k3b
--> Processing Dependency: libiw.so.28 for package: kdenetwork-extras
--> Processing Dependency: libiw.so.28 for package: NetworkManager
--> Processing Dependency: gnome-python2-desktop = 2.18.0-1.fc7 for package:
whith infinite loop...
i686 F7 (fresh install when new) to F8, using the rpm -U --test method:
error: Failed dependencies:
fedora-logos conflicts with generic-logos-8.0.2-1.fc8.noarch
ant = 0:1.6.5-4jpp.2.fc7 is needed by (installed)
avahi = 0.6.17 is needed by (installed) avahi-compat-howl-0.6.17-1.fc7.i386
libdb-4.5.so is needed by (installed) libgda-1.9.100-12.fc7.i386
libexpat.so.0 is needed by (installed) compat-wxGTK26-2.6.3-2.i386
libexpat.so.0 is needed by (installed) graphviz-2.12-8.fc7.i386
libexpat.so.0 is needed by (installed) wxGTK-2.8.4-3.fc7.i386
libexpat.so.0 is needed by (installed) git-core-22.214.171.124-3.fc7.i386
freeglut = 2.4.0-11.fc7 is needed by (installed)
gamin = 0.1.8 is needed by (installed) gamin-devel-0.1.8-5.fc7.i386
glib = 1:1.2.10-26.fc7 is needed by (installed)
gnome-python2-desktop = 2.18.0-1.fc7 is needed by (installed)
gnome-python2-extras = 2.14.3-5.fc7 is needed by (installed)
gtk+ = 1:1.2.10-57.fc7 is needed by (installed)
kdelibs = 6:3.5.7 is needed by (installed) kdelibs-apidocs-3.5.7-22.fc7.i386
kdemultimedia = 6:3.5.7-2.fc7 is needed by (installed)
kernel-i686 = 126.96.36.199-10.fc7 is needed by (installed)
kernel-i686 = 188.8.131.52-21.fc7 is needed by (installed)
libgpod.so.1 is needed by (installed) gtkpod-0.99.8-3.fc7.i386
libgsf = 1.14.3-4.fc7 is needed by (installed)
libmpcdec.so.3 is needed by (installed) k3b-1.0.3-2.fc7.i386
libmpcdec.so.3 is needed by (installed) vlc-0.8.6c-4.lvn7.i386
libmpcdec.so.3 is needed by (installed) mplayer-1.0-0.81.rc2.lvn7.i386
libusb = 0.1.12-7.fc7 is needed by (installed)
libutempter = 1.1.4-3.fc6 is needed by (installed)
lucene = 0:1.4.3-1jpp.18 is needed by (installed)
mysql = 5.0.45-1.fc7 is needed by (installed) mysql-devel-5.0.45-1.fc7.i386
libneon.so.25 is needed by (installed) neon-devel-0.25.5-6.i386
libneon.so.25 is needed by (installed) tla-1.3.4-5.fc6.i386
neon = 0.25.5-6 is needed by (installed) neon-devel-0.25.5-6.i386
openoffice.org-core = 1:2.3.0-6.4.fc7 is needed by (installed)
openoffice.org-core = 1:2.3.0-6.4.fc7 is needed by (installed)
openoffice.org-writer = 1:2.3.0-6.4.fc7 is needed by (installed)
pcre = 7.0-2 is needed by (installed) pcre-devel-7.0-2.i386
libpoppler.so.1 is needed by (installed) poppler-utils-0.5.4-7.fc7.i386
poppler = 0.5.4-7.fc7 is needed by (installed)
qt-devel = 1:3.3.8-7.fc7 is needed by (installed)
subversion = 1.4.4-1.fc7 is needed by (installed)
unixODBC = 2.2.12-2.fc7 is needed by (installed)
vim-common = 2:7.1.12-1.fc7 is needed by (installed)
xine-lib = 1.1.7 is needed by (installed)
Created attachment 254951 [details]
anaconda.log with yum depsolving output
OK, I modified YumDepSolveProgress to include all the logging from the original
yum DepSolveProgressCallBack and this is the result.
The log is truncated because there's no way to stop or pause anaconda, but the
looped output at the end is obvious.
I had the same problem on an i386, (Celeron based) desktop system.
I have Livna and FreshRPMs packages.
Upgrade hanged at 26%, both graphical and text installation.
I aborted the upgrade and then updated my F7 packages using the graphical tool
(Puppy?) and tried again.
After that, the "Checking dependencies..." process goes all the way to around
99%, but the last 20% are _really_ slow. After around 7 hours total and 99% done
checking dependencies I aborted the proces.
I thought I'd chime in here as well -- I'm seeing the same problem -- upgrade
hanging at 26% while "Checking dependencies..." -- whether using graphical or
text mode anaconda install. Strace output shows me it's looping, never making
progress. Using packages from atrpms and livna repositories. Upgrading from i386
Fedora 7 -> Fedora 8.
*** Bug 366641 has been marked as a duplicate of this bug. ***
*** Bug 371111 has been marked as a duplicate of this bug. ***
FWIW, I have this reproduced and am debugging it (for those playing at home).
Hopefully will have a new updates.img to try out before I leave the office this
Okay, I've updated http://katzj.fedorapeople.org/updates-f8-yumloop.img with
newer bits that get through depsolving successfully for me in cases where there
are some deps that can't be resolved.
Can people try and see if this helps?
Jeremy, I have used your latest version of updates-f8-yumloop.img, and it has
(so far) got past the 'dependencies' hang in my F6-F8 upgrade, and the rest of
the installation is now in progress...
Using the comment #28 version of updates-f8-yumloop.img I was able to complete
an upgrade to Fedora 8 on one machine. Thanks Jeremy, after this one
(unfortunately pretty major) glitch, this was a trouble-free upgrade.
Looks like it fixed it. I was able to get it installed and this update is coming
from a freshly upgraded system. Thank you!
I was also able to upgrade from FC6 to F8 using the updates-f8-yumloop.img from
comment #28. Thanks for the fix.
I was also able to upgrade using this image. Thanks!
can anyone please explain the steps to apply the fix? (FC8 DVD + updates.img on
a USB key)
Never used anaconda updates before and cant get instructions from
http://fedoraproject.org/wiki/Anaconda/Updates to work
thanks in advance
I don't understand something. Information provided on
doeasn't seem to be correct or the image file I downloaded is corrupt:
$ cpio -iv <updates-f8-yumloop.img
cpio: premature end of archive
$ mv updates-f8-yumloop-0.img updates-f8-yumloop.img
$ gunzip updates-f8-yumloop.img.gz
gunzip: updates-f8-yumloop.img.gz: not in gzip format
Nothwithstanding that, I copied the image file to the floppy:
$ dd if=updates-f8-yumloop.img of=/dev/fd0 bs=72k count=20
Then I put the Fedora 8 install DVD into the DVD drive, rebooted, and added the
`linux updates' flag to the boot line, as instructed.
A few screens later I am prompted for the location of the updates image I choose
`fd0' and press `OK'. This ALWAYS throws an error message that ends
`install exited abnormally [1/1]'
I repeated this several times, I used several different floppies, I downloaded
updates-f8-yumloop.img several times. Always the same result.
I haven't tried using a USB stick.
I don't think the image is corrupt because it contains a loop mountable filesystem.
after "mount -o loop <image> /mnt" you can see that it contains ordinary files.
But nevertheless I have the same problems as Mariusz Wodzicki in comment #35 (I
use a floppy for the image).
Thank you, firstname.lastname@example.org, for your remark. My previous post has been
written from a machine in a network where I did not have root privilages, so I
couldn't check the image file by mounting it. A few moments ago I did that on
another machine, and I can confirm the integrity of the mounted mini file system.
install exited abnormally
as described in #35
Great work for the anaconda update, congratulations!
Now I have a new Fedora 8 box (very nice and with a clean look!)
Put the img in a usb key and boot from dvd. Choose "upgrade from ..." from the
boot menu (without press the tab key because I'm not sure where to write
"updates"). When the boot starts press CONTROL-C and now at the prompt write:
This is what I did after somes tries (...and failures of anaconda).
Booting from the DVD, and hitting "esc" key at the first menu, I could get the
prompt. Typed "linux updates" and after selecting the location of the updates
it ends up with a "install exited abnormally [1/1]" message (tested a floppy
(fd0) and a USB key(sdc) with the same results)
Mine is i386 arch
Have the same trouble - "install exited abnormally [1/1]"
tested a floppy and a USB and nothings helped =(
Very weird: after going back to F7 (on past friyday after my first unseccessful
F8 upgrade try) and then today morning installing the most recent F7 updates
(yum update), the dependency checker during F8 upgrade did not remain at 26%,
but proceeded until 99% (the steps from % to % needed more than 60 secs and
became longer and longer). The used memorory increased to 41.7% of 2 gigabyte
(100% of the dependency checker were not reached, so I rebooted back to F7).
From booting the F8 DVD until this state, it took about 1.5 hours, and this on a
Athlon 4600+ with 2 CPU's and 2 gig meory.
Could any of the people seeing the "install exited abnormally" message please
post the traceback or stack trace they are seeing? That's useful information
for debugging the problem.
I also get "install exited abnormally [1/1]" with floppy disk image. Then I
copied the updates-f8-yumloop.img to web server and then do:
..and it works for me! My upgrade was FC6-->F8.
Created attachment 257411 [details]
anacoda backtrace update from fd0
sorry, the attachment went before my comments! :-)
(In reply to comment #44)
> Could any of the people seeing the "install exited abnormally" message please
> post the traceback or stack trace they are seeing? That's useful information
> for debugging the problem.
Chris here is the backtrace I got trying to update F7 to F8, using your anacoda
update image from on /dev/fd0:
loader received SIGSEGV! Backtrace:
install exited abnormally [1/1]
(I transscribed that from a photo of the display ... I don't have a way to
capture the screen off the server otherwise) .. I'll attach that photo, just in
As a comment on #47, I found a way to work around that, if you dare ;)
- start the installation CD like normal (so no worrying about linux updates or
anything), with the updates floppy or USB disk inserted
- run all the way to when the anaconda graphical stuff displays, but don't use
any of the buttons
- switch to terminal 2 with <ctrl>+<alt>+<f2>
- remove the floppy or USB disk and re-insert it (especially important for USB
- enter in sequence, with "update-source" being your update source, for instance
fd0 for floppy or sdb/sdc/sdd (depends) for USB disk:
# cd /mnt
# mkdir updates
# mount /dev/update-source ./updates
# export PYTHONPATH="/mnt/updates"
- press <ctrl>+<alt>+<f6> or <f7> to return to anaconda's graphical installer
- and use anaconda like nothing happened.
I am glad that comment #28 seemed to help a lot of people, but I can't upgrade
that way (you don't want to know why).
When will the patch be applied to the release-ISO on Fedora Main? This is how I
will have to upgrade.
I can confirm the behaviour described in Comment #43 by email@example.com.
After observing that all of my DVD upgrade attempts were always consistently
stalling at the 26% mark during the "Checking package dependencies..." step, I
decided to update all of my installed Fedora 7 packages by issuing `yum update'.
I keep my system up to date so I was quite surprised to see how many F7 packages
have been updated literally in recent days.
Then I made another attempt at upgrading to Fedora 8 from the DVD. This time the
installer progressed reasonably fast up to around 50% mark, but then has been
progressing much slower, so finally after 3 hours of wait I left it at around
98-99% mark. Eight hours later it was still at the same spot. I had to shutdown
the installer manually (Ctrl-Alt-F2 takes you from the installer to the shell
prompt). This happened on Sunday night. Yesterday I noticed that again a lot of
additional Fedora 7 packages have been updated, and again I did a `yum update'.
In addition, I removed a number of old packages, some leftovers of late Red Hats
and early Fedora Core releases.
I wonder whether this most recent update may get me past the dreaded "Checking
package dependencies..." step this time. Anybody tried the DVD upgrade today
after doing first `yum update' of all his Fedora 7 packages?
I am really hoping that Jeremy Katz, or somebody else from the anaconda
installer or yum development teams would would revisit us soon, as the situation
still remains quite intollerable.
(In reply to comment #48)
Was not helpful for me: the anaconda dependendcy checker stalled as usual at the
On a Fujitsu-Siemens S6010 Lifebook the upgrade from Fedora 7 to Fedora 8 hang
at 99 % of checking dependencies, even after I had removed all duplicate
packages and resolved all problems in the RPM database shown with package-
cleanup. Using the upgrade in comment #28 finally allowed the Fedora 8 upgrade
to take place.
Initially the upgrade stopped at around 26%, using the update in comment #28 my
upgrade stopped at around 99%, so for me comment #28 has sadly not yet solved
System here is Fedora 7, x86_64, fully updated.
just to increase the counter of poor souls hit by this horrible anaconda bug =(
My system is a fully updated F7 x86_64, and upgrade hangs "forever" at 99% of
the deps solving process (waited for 1+ hours). It looks like "good old"
dependency hell problems are back =(
However, there's some hope that the updated .img provided by Jeremy Katz will
help me get past this point as it helped others (but unfortunately not
everyone). I will try this ASAP (I am at work now) and post back here my results.
Fixed for me with the newer updates.img - thanks Jeremy.
I tried F8 upgrades on two machines last night. An FC6->F8 upgrade worked okay
(a bit slow, and >700 packages to update and clean up afterwards).
However, an F7->F8 upgrade failed, even with the newer updates.img. Or at least
I gave up on it after 10+ hours. It was about 99% through the "resolving
dependencies" progress bar.
Here's the output of 'free' and 'uptime' just prior to killing off anaconda:
total used free shared buffers
Mem: 1034944 1015032 19912 0 6188
Swap: 4200956 728532 3472424
Total: 5235900 1743564 3492336
09:43:03 up 10:28, load average: 1.22, 1.16, 1.06
So it looks as if there's some form of memory leak also involved.
The system has just under 2400 RPMs installed.
Just a reminder for all who see:
install exited abnormally [1/1]
Make sure you have a valid Partition table on the device you are using. If you
dd the img file to say /dev/sdc, you end up with a loop partition table. Which
will be happyly mounted by linux under normal conditions, so if you mount it on
another machine it will work. But not as an update device.
create new partition "n"
don't forget to quit :-)
dd if=xxxx.img of=/dev/sdc1 //!!!!!!! there's a 1 there
Hope this helps.
I used the image that Jeremy Katz provided in comment #28 and didn't get any
luck. It stuck at 99%, I waited about 2 and half hours and then rebooted back
into my F7.
So sad this is happening :(
Well, it worked for me and I finally managed to upgrade to F8 =)
I had one failed attempt before succeeding, but that was because I misspelled
"updates" (I wrote "upgrade"), and anaconda simply ignored it, no complaints. I
went through another 1+ hours until I realized (by looking at /tmp/anaconda.log)
that the updated image hasn't been used.
Then I tried again, and this time I typed
at the "boot:" prompt, and that did the trick =) (anaconda will even tell you
it's obtaining the IP address and downloading the .img file)
I used the images get passed dependency check but get stucked at the next step.
Machine completely hangs and graphical display is completely messed up (see
I gave it another try displaying top in the command windows. Machine hanged
similarly (see attached picture with top output).
Created attachment 259251 [details]
Machine hangs: graphical display
Created attachment 259261 [details]
Machine hangs: top display
Based on the hint of comment #58, I was able to avoid "install exited
abnormally [1/1]" error: previously I was booting with the USB stick plugged,
but things started to work when I plugged the memory just after the check media
In the Update Disk Source dialog I selected /dev/sdc, and again a new Update
Disk Source dialog appeared asking to confirm the partition (sdc1)
Finally the "Updates Disk" dialog asks to insert the updates disk in /dev/sdc1
and press OK.
But after that I went back to the graphical interface and ended up in the 99%
hang of checking dependencies
Not sure if it helps, but (Ctrl+Alt+F3) last lines of anaconda log are
WARNING : step installtype does not exist
WARNING : step complete does not exist
INFO : moving (1) to step welcome
I probably will not be able to confirm the advice given by Ronald Kuetemeier,
see Comment #58, since 10 hours ago I was finally able to complete the upgrade
F7->F8. I used a USB stick this time. All I did was just to execute the command
dd if=updates-f8-yumloop.img of=/dev/sdc1 bs=72k count=20
without creating a partition first -- as suggested in Comment #58.
I have to say that my first attempt at the update with the `linux updates' boot
flag failed for no clear reasons (and not because I misspelt something): when
prompted for choosing the updates location, my selection was rejected with an
error message saying that the location did not contain any updates.
I tried several times, always with the same result. I decided to try again: I
switched to the shell prompt to reboot the laptop. In a short pause between the
shutdown and the boot, I repositioned the USB stick in the USB port.
On the first screen I again added the boot flag `linux updates', and a few
screens later, I again chose `sdc1' as the updates location -- as I did during
my failed previous attempt. This time my choice was accepted, and soon I arrived
at the dreaded "Checking package dependencies..." step. I noticed that that step
terminated when the progress bar reached around 26% (!) [I suppose due to Jeremy
Katz' intervention], and was not ever allowed to progress to 100%.
Then I was greated with the following screen, and there is not much to report on
what was happening afterwards. The whole installation still required around 2
1/2 hours (!) even though I was informed that only 963 packages had been set to
I am still hoping that some competent person would clarify why the updates
instructions provided by Jeremy Katz in Comment #11 were generally wrong. And
what was wrong? The image provided image file or the instructions?
And finally, I have a strong hope that some responsible people at Red Hat will
analyze this whole upgrade fiasco and will take necessary measures so that a
flop of this magnitude will not happen again.
This was not just a nuisance but a critical bug which prevented a lot of people,
including quite experienced ones (I, for one, have been upgrading from Red Hat
7.3 through every single subsequent Red Hat and Fedora Core releases), for
nearly a week, to upgrade to Fedora 8 -- especially if one thinks of all the
wasted time and energy of so many of us. And I am afraid a lot more people are
still going to be stung by this bug.
Note typo in comment #60. The URL should be fedorapeople not fedoraproject.
Doesn't matter because it doesn't work either way for me.
I have to say that I am getting rather teed-off over this whole mess ... if
Fedora can't fix something as trivial as an updater, what about the tough stuff?
Also, why isn't anything posted about this on FedoraMain? Thousands of people
are continuing to download Fedora 8 only to be bit by this fiasco. If Redhat
posted a notice of this issue AND provided daily status updates, many many
manhours of time would be saved and much frustration would be averted.
*** Bug 384081 has been marked as a duplicate of this bug. ***
In my case, I have the impression that after selecting sdc1 as the source of
the updates, anaconda starts again the ordinary installation (probes video
card, starts Xorg and the language and keyboard selection screens) from the
beginning, ignoring the linux updates command and the updates.
The same behaviour occurs with the "linux
ip=dhcp" way (I'm pretty sure it downloads the .img but after saving it,
anaconda starts over from the beginning)
I experienced these twice (more than 6 hrs each) and in both cases I ended up
with the checking dependencies bar at 99%.
Is there a way to debug anaconda in after selecting updates?
"Me too". I finally got F8 to install, and will describe how below. My system
was a FC3 box upgraded -> FC5 -> F7 -> F8. Anaconda has never done this to me
before. Definitely some new bug in F8.
I have lots of rpm's from ATrpms, and a couple from livna. My system has 2 SCSI
drives on a AIC-7892A, and 3 Gb NICs.
After hitting this bug and reading these notes, I uninstalled all ATrpms and all
livna RPM's. See bottom for actual command lines to do this easily. Tried the
upgrade again with stock F8 DVD and it still failed (froze at 26%).
I then tried uninstalling select stock fedora rpm's as per comment #15. That
didn't help (though I did leave ImageMagick in as it had too many deps).
I then tried using comment #11's update. The floppy method did not work for me
dd'ing to fd0. I got the same error as everyone else reports with the floppy.
Do we need to create a partition on the floppy first? The instructions should
be more clear on this.
Then I tried the updates=http method as per comment #60, before realizing as per
comment #66 that #60 has a typo. Anaconda just quietly continues with the bad
url (which fails). The only way you can see it failing is by switching vt's to
3 right after selecting your eth (if you have more than 1). The error quickly
scrolls by off the screen so if you're not on the screen when it scrolls off (so
you can scroll back up) then you'd never know it failed (or why).
Finally, with many rpm's removed, and updates=http... I got F8 to install. It
went from 0% to 26% in about 15 seconds, then the DVD-ROM light flashed, then it
instantly jumped to 100% and started installing. Installation took about 45mins
with 900 rpm's.
I have no idea if the atrpm/livna rpm removal was necessary or if the katzj
update would have been sufficient, but I did learn the katzj update was *required*.
The katzj update image should be put into stock F8 iso ASAP.
If you want to easily uninstall all atrpm & livna rpm's:
rpm -qia | grep -iB1 'Vendor: atrpms' | perl -ne 'print "$1\n" if /Name\s*:
(\S+)/' |sort > /root/fc8-pre-baks/atrpms.rpms
rpm -qia | grep -iPB2 'Release\s+: \S+\.lvn\d' | perl -ne 'print "$1\n" if
/Name\s*: (\S+)/' |sort > /root/fc8-pre-baks/livna.rpms
rpm -e `cat /root/fc8-pre-baks/livna.rpms`
rpm -e `cat /root/fc8-pre-baks/atrpms.rpms`
and you can reinstall with yum after the upgrade by look at the rpm list files.
2 days ago i upgraded my F7 to F8 from the DVD, graphical upgrade. it went
flawless, in like 45 minutes (Pentium IV 3GHz, 1GB RAM). dep. check took about 5
minutes (i had 952 rpms installed on F7), then it upgraded ~850 packages. that
system is working without problems ever since. i have livna repo, with a couple
of packages installed from there. i did however NOT run the lates 'yum update'
on F7 before the upgrade process, so i didn't have the latest packages
(including the new 2.6.23 kernel).
today i wanted to upgrade my work F7 system, which is kinda the same
configuration, only with 1079 packages. naturally it hangs at the dep. check
part, at 99%. now running for about 6 hours (sempron 2ghz, 1 gb ram). CPU is at
100%, ram used by anaconda is at ~70% and increasing. i DID however run 'yum
update' on this one before the install, so i had the latest F7 rpms, including
the new kernel 2.6.23.
so to sum up, on one machine upgrade worked without a problem, on the other
machine (with the newest F7 rpms) it hangs at the dependency check and eat RAM.
Shouldn't this bug be classified as 'urgent'? It is stopping a lot of people
from even experiencing Fedora 8.
Also, please apologize for the typo on comment #60, if I could only edit that
damned post =(
Somehow anaconda does not get the same level of testing (before release..) as
I had difficulties with Fedora 7 install too. See bug 242047, but 242043, bug
241949, bug 237415
anaconda gets lots of testing internally, however you must realize that it is a
very complex piece of software that deals with a lot of unusual hardware and
software combinations. There are a lot of cases here that do not get testing
simply because of the number of possibilities involved. Also, anaconda does not
receive all that widespread of testing in the larger community due to its very
nature - it is an operating system installer that if it breaks, can wreak havoc
on your system. So people tend to stay away from just trying it out.
Please understand that we are working on an updated boot.iso for this problem.
However in an effort to minimize the number of new boot.iso images we remake, we
are attempting to track down a couple of other bugs at the same time so we can
roll them all up into one fix. The most notable bug we are working on here is
bug 374311. Note that the related bug here of not being able to put updates on
a floppy should be fixed up in this new image.
Thank you for your patience as we work to address the maximum number of bugs as
we can in a short amount of time. We hope to have an update put together soon.
One final note - this bug is listed at the F8 Common bugs page on the Fedora
wiki, though it takes a little bit of navigation to get to:
Thanks for all the hard work Chris and team. I started using Redhat Linux in the
mid 90s and have been an advocate ever since. Heres hoping we have a fix before
the weekend hits so I can spend Saturday playing with new features ;-)
(In reply to comment #73)
> anaconda gets lots of testing internally, however you must realize that it is a
> very complex piece of software that deals with a lot of unusual hardware and
> software combinations. There are a lot of cases here that do not get testing
> simply because of the number of possibilities involved. Also, anaconda does
Does it get tested internally for its tolerance of third-party packages? I'm
wondering whether most of the anaconda internal testing is done on machines that
follow the strict open-source-only rules. If so, it would explain a lot: most
end users have some third party packages installed (nvidia drivers, Sun JRE, mp3
support etc.). Fedora upgrades need to be cope with that.
Otherwise, it seems odd that even a small amount of testing wouldn't find a bug
that seems to affect such a large proportion of the user base.
[a quote from Comment # 73:]
> One final note - this bug is listed at the F8 Common bugs page on the
> Fedora wiki, though it takes a little bit of navigation to get to:
The first thing anybody is seeing is usually
and the highly visible link
which contains the misleading section:
For a list of common known bugs in the F7 release, refer to:
Another "bug"? Should that be F8, and the link should be to
Sorry for the typo, hit the `Save Changes' button too early: the last link
should be of course
[I wish we could correct our own typos -- why we can't?]
Created attachment 260761 [details]
Packages removed to apply J.Katz´s fix
Finally I succeeded with the upgrade. Based con previous comments, I removed
several packages (chosen from the output of "yum list extras"; some of them
were residuals from previous upgrades) and I was able apply jkatz's fix.
Not sure which one exactly, but the conflicting package was preventing anaconda
(fixed) to finish the dependencies check normally
FYI, I had *not* updated my F7 in a couple of weeks, so I did not have the
newest levels (kernel and such). And the upgrade still did not work for me.
Also, I had removed all 3rd party (livna/atrpm) and binary-only (nvidia)
packages and depsolve still failed.
Only the updated img (or that plus removing packages) got it to work.
Has anyone had a failure with the updated img (assuming they got it to work
right, see my previous post), ignoring whether they rpm -e'd packages or not?
Perhaps the whole problem was just the buggy DVD boot img depsolve.
Can someone provide a link to a new bug for the floppy updates image failure bug?
Just a quick ACK to comment #28.
First I was getting stuck in dependency analysis, after an hour or so, at 26%. I
removed all not-from-Fedora-repositories packages and this got stuck at 99%
after several hours of thinking.
With the update image from comment #28 dependency analysis took only a few
minutes and completed successfully.
For me this was, therefore, a huge improvement.
Can't a new DVD image be done with this fix?
I experienced this bug when trying to upgrade from F6 to F8 on my Thinkpad T23
laptop. It is now works for me thanks to Jeremy Katz' update (thanks!). Here
are the steps which work for me:
1) Boot from DVD as normal
2) At the first screen, press ESC to get to boot: prompt
3) Type: linux updates=http://katzj.fedorapeople.org/updates-f8-yumloop.img
I didn't need to add "ip=dhcp" to the boot line, but maybe it is important for
some people. Fedora is now through the dependency checking and crunching away
at "preparing transaction from installation source". Wish me luck!
PS: It would be great if Fedora re-releases the FC8 ISOs once they get the
common bugs sorted out.
another ACK plus a few notes...
i have atrpms for nvidia and mythtv. no livna repo. didn't remove any
packages. the atrpms repo was disabled and still pointing at F7 after the
upgrade. i don't know if the upgrade disabled it or not.
i used the update from comment #28 and the 'make a partition' note from comment
#58. didn't try without a partition so can't confirm if comment #58 is
at the initial grub (?) screen when booting from the DVD i pressed 'tab' to edit
the boot line and added "updates" (no quotes) to the end of the line (which
during the text phase of the installer i was prompted to choose a drive to get
the updates from.
having chosen the right one (not sure how you're supposed to guess if you've got
lots) i was prompted to select the right partition - from the list of 1! (the
question actually said "that device contains more than one partition..." i think)
then i was prompted to insert a disk into the drive (or something along those lines)
during the graphical part of the upgrade i was prompted twice with a message
saying that the USB stick (or at least "/dev/sdg" .. nice) contained a loopback
(?) partition and needed to be re-initialised if i wanted to use it for the
install. hmm. i chose 'ignore' both times and that worked.
dep solve took about 20 seconds on a core 2. and that includes spinning up the DVD.
many thanks for the fix! :-)
another system, another ACK, another note.
this time upgrading from FC6 with livna for nvidia. didn't disable livna or
remove any packages.
had some sort of problem reading the USB stick but noticed that it was listing
the hard disk as a possible source for the updates - so i copied the contents of
the stick onto /boot and used that instead. worked fine.
problems - doubt these are caused by the new depsolver:
updates repo file was still pointing at 'core' after upgrade - new repo file was
setroubleshoot stuff didn't get installed.
/etc/cups/ppd/printer.ppd had wrong context.
pulse audio tools didn't get installed. not sure if it was using PA until i
installed some of that stuff.
I was also having the same problem of hanging while trying to upgrade from
Fedora 5 to Fedora 8. I removed the packages that some of the people suggested
to remove. I decided to try upgrading to Fedora 6 first. It failed the first
time. So, I switched from the SMP kernel to the standard kernel and turned off
Hyper-threading in Bios. I was able to successfully upgrade on my second
attempt. I then attempted to upgrade to Fedora 8. It worked. Now I just have a
few other configuration issues I will fix.
I experienced very slow progress (>60 min) on a powerful machine upgrading FC7
to F8, but the workaround in comment #82 (plus "ip=dhcp vnc vncpassword=x")
finished the install. I don't know if it is significant, but I had at least one
broken dependency afterwards. gnome-session was defunct because libesd was not
installed, so I just installed esound from the console.
*** Bug 390801 has been marked as a duplicate of this bug. ***
I am curious if during "Fedora 8 testing" anyone tried upgrading from F7 to F8?
One would think that it should be, if not first, then the second thing to test.
(I am here because, guess what, it did not work for me either)
*** Bug 391721 has been marked as a duplicate of this bug. ***
*** Bug 391631 has been marked as a duplicate of this bug. ***
*** Bug 393121 has been marked as a duplicate of this bug. ***
With regards to comment 73, How does one get involved in testing the install
I am generally in a pretty good position to do this. I generally have a large
number of unused (but older) systems around waiting to be reloaded for field
implementation. There are also several units just waiting in an empty
configuration waiting for a problem with a field installed unit. They are then
loaded as a duplicate of the field unit and sent out.
Since part of the process is to reload them a few times as well as wipe the
disks it would not be a problem at all to test the install system. Also it
doesn't matter if a single unit gets set aside for a few days for additional
This is absolutely THE WORST release of Fedora ever. The problems installing are
innumerable. I tried it on three computers and everywhere I had problems that
just scream "it was never really tested".
On the third computer, which is a production machine, Fedora just formatted the
hard drives and seems fully stuck in the "Starting install process" stage.
Great, I am now fsck'ed and this makes it look rather pathetic.
Instead of feature chasing, time would be better spent on testing.
It is very sad, but I will try looking into some better tested distro. I have
been a RedHat/Fedora user for 10 years. Maybe Debian.
It's been 2 weeks and there is no solution to a problem that should not even
I have had really good luck so far once it has been installed, but you are right
that the installation is a real "b" word. Over half of the stations I upgraded
to fc7 failed the install at least once, and of those about 1/3 failed it a
second time. Yeah at least two trips to the bug archives to find fixes.
There is one problem where the "fix" to do an upgrade is simply to take all the
data off, reformat and do a scratch install. The installs do seem to work
pretty well on fc7. With fc8 about half of these seem to fail. My guess is
that someone assumed that all installations and updates would be done with a dvd
and not over the net. Sorry over the net is the only real option for most of
On the other hand at least this patch seems to work. It has fixed four
machines that would not upgrade. NOte that you don't need to worry about the
ip and name server stuff. Simply hit esc at the beginning and start it with
the linux updates=http:// stuff and it works great. It takes all the ip
information you enter and applies it to this process. One complaint here for
fc9. If you enter a wrong line after updates= it doesn't give an error it
simply ignores it. This merits an error with a nice descriptive message that
repeates what you typed back to you.
Just adding some more (usefull?) information for all of those that are trying to
solve the problem.
I have installed FC7 on a brand new system 3 weeks ago and after 2 weeks I
upgrated to F8 in just 1 hour, without any problem. I must say that there
were'nt any 3rd party nstalled on that system.
These days I decided to move forward to F8 on my laptop as well (Dell Latitude
D820) with lots of 3rd party rpms. I have tried many times making previously
sure that rpm database indexes were correctly rebuilt and fsck all filesystems
(just to avoid collateral problems). Nonetheless anaconda hung as described in
most of the comments above. I also tried to leave anaconda running for about 24
hours, since I've noticed that progress bar decreased it's speed logaritmically,
meanwhile disk activity was very low, then suddenly (after about 12 hours) dist
started working like crazy. I thought "there were probably something hard to
resolve, but now seems alright". I went to sleep and the mornong aftes anaconda
was still there. hum.... something is definitively wrong with installer/upgrader.
I must also say that this is not the worst distro. this is a distro that is
suffering some problems, but the spirit of this product is to
collaborate/cooperate to solve such kind of problems, to make this distro (like
all others) something usable and problem free.
Hope my information will help somehow to drive developers in solving this
I will ask again--see comment #73--does the internal testing of anaconda involve
running the upgrade on machines that have third-party rpms installed, or only
ones that stick rigidly to the Fedora rpms? The evidence from this thread is
that it is the former, though I can't be certain because I didn't get a reply to
Whatever the beliefs about open source etc., it has to be recognized that a huge
number of Fedora users have third-party repos set up so that they can pick up
proper nvidia drivers, DVD playback software, and the like.
And that means that the upgrade has to be tested with this in mind.
So--what is the internal anaconda testing strategy, please?
Regarding comment #94, I completely agree that anaconda simply ignoring
misspelled or invalid options is definitely a no-go. On my first attempt with
the fixed .img by Jeremy Katz I typed "update=http://..." instead of
"updates=http://..." (I missed last 's'), and it took me a while stuck at the
dreadful 99% depsolve until I realized by looking at the logs that I had
misspelled one of the options. I swear I was about to give up on F8, at least
until showstopper bugs like these were fixed (which means I would probably still
be waiting since no re-spins of the official ISOs have been provided).
Anaconda is the entry point to a new Fedora version. If it sucks, it's a bad
start to what you expect to be a pleasant, hassle-free experience. Sure I know
there's no such a thing as flawless software, and you kinda expect to workaround
some issues when it comes to a new installation (specially if it's an upgrade),
but I'm sure you get the point.
I could be wrong, but it seems to me we're seeing failures for situations that
could have been tested in-house. In my case, for example, I had an up-to-date F7
installation (which was installed from scratch), and only one 3rd party RPM repo
(Freshrpms), which is a pretty common setup AFAICS. I guess it all comes down to
which packages I had installed.
Unfortunately I can't install betas on my system, it is the one I use daily,
including for work. But I would gladly provide my packages list (rpm -qa --last
or anything like it) if it could help someone from Fedora QA Team test updates
with a similar setup during the beta tests phase. Does anyone think this could help?
IMHO, the problems surrounding the installer are related to poor testing, and
too often releasing.
P.D.: Still waiting for a Fedora 8 DVD that will upgrade correctly.
According to my experience, this is not directly caused by 3rd party RPMs. I
have two systems, both with livna enabled and almost similar package sets,
including some patent encumbered software. The first upgrade (a laptop) had no
problems, the second (a desktop) had this bug, which was solved by using the
I agree with comment #99 -- this happens on pure Fedora systems without any 3rd
In my experience, the current Fedora 8 DVD is good *only* for clean installs,
but most people are upgrading from a previous version and experience hangs at
the dependency solve step.
Until this bug is fixed, Fedora 8 isn't ready for prime time.
I was bitten by the depsolve bug too.
Nevertheless, I almost feel ashamed for some of the comments made here (such as,
but not limited to comment #93).
Did it ever occur to you guys that Fedora is a *community* project ? To quote
Jeremy in the F8t3 announcement :
"This is the time when we must have full community participation. Without this
participation both hardware and software functionality suffers."
How many of you actually tested the Anaconda upgrade and filed bug reports
*before* F8 GA ? Thought so.
Not wanting to be pedantic, but I feel obliged to apologize to Fedora/Anaconda
Quit the whining. End of rant.
Yeah more community support is needed, but many of the problems I have
experienced seem to be hold overs from the fc7 world, and are still open.
Maybe fc8 needed to be held until more of the fc7 issues were dealt with.
On the other hand maybe more field testing is needed. So the community is an
issue. But maybe a month or two before the actual break out, a test version
needs to be released, with an announcement to the general web pages, and a punch
list of changes that one might want to check. I would suspect that such a list
might be taken more seriously and these issues addressed in a more complete manner.
Comment #101 about community testing of Anaconda prior to release is well taken.
I am guilty of not participating in the pre-release testing of F8 (but I have
done pre-release testing of versions in the past).
Given that Anaconda is a very important (although briefly important) part of
Fedora, I wonder whether the 'release' version of Anaconda is available for
test1, test2, test3 testing?
Or is Anaconda a last minute cobble to encompass all of the new features of the
I know this is getting a little way away from a "bug" report and resolution, but
It seems to me that I am not sure how people get involved with development and
testing. I notice that the open office.org site has a button for
participation, and that leads to a web page that start by saying that all skill
levels are needed, and a general list of "jobs" and tasks that are needed, and a
short description of each one. Each of these then is hot linked to a full page
(or multiple pages) on exactly what is needed and the procedures to participate.
I can't find anything like this on the fedora site. Maybe that is part of
the problem. From participating in this "bug" I have learned a whole lot more
about getting involved, and what is needed. (I still really need to know more
but it is a start) Before I thought that the team only really was looking for
specific people and they contacted you if they were interested in your help. I
didn't even know that they accepted "off the street" volunteers.
maybe this should be continued on a forum, or a mailing list, i don't think the
last couple of comments help on resolving this particular bug ;) i'm getting
mail for this bug like it was a mailing list :)
Then let's add something that might be usefull:
Can we get some patched DVD to test? I'm willing to test new DVD images (could
be a patch for the fedoraunity gijdo images).
P.D.: +1 for comment #104 on participation in testing.
Motivated by Imre's comment #105, I posted a message on Fedora ML with some
ideas regarding anaconda testing, please check it out and post there any
comments you might have.
Created attachment 268361 [details]
anaconda dump file for my unhandled exception
Long story short:
Attempting to upgrade FC5 to F8
I first tried the "yum upgrade" method of upgrading. In my 1895 RPMs,
apparently, too many dangling dependancies. yum was unable to complete. I have
RPMS installed from Livna (nvidia, mplayer et al), FreshRPMS, ATRPMS (mythtv,
ivtv), dribble (DVDAuthor), and a test copy of Compiz for FC5. After removing a
bunch of RPMs, the most pervasive problem is the FC5 kernel modules for the 1
FC5 kernel I have installed (and am currently running).
I was able to upgrade the fedora-release RPM, and started in upgrading certain
RPMs by hand with yum updates. I got quite a few packages upgraded, but I keep
running into Perl or Python dependancy issues, and I'm unable to upgrade RPM/YUM
et all. ATM I seem to be running quite the Frankenstein system with a number of
FC5 and FC8 RPMs installed. My HTTPD and SENDMAIL still seem to be running (or
were when I rebooted to try finishing the install with the DVD.
OK, so today I tried to finish the upgrade via the F8 DVD. AMD Athlon 2600+
CPU, running i686/i386 packages. After well over an hour or progress, I hung
near the end of depsolving (second of 3 periods over the completion bar, I
waited for over an additional hour before deciding it was hung). While hung, I
found this BUG. I tried the solution in comment #82. So, I rebooted the
install DVD, ESCed to the grub prompt, booted as described, and BOOM. Right
after selecting UPGRADE in the graphical screen, an unhandled exception
occurred. I dumped the file to my laptop. AFAICT, I haven't even started
depsolving (I could be wrong though). I am attaching it for anyone who wants to
look at it and tell me what I did wrong.
Created attachment 268371 [details]
anaconda dump file for my unhandled exception
Hm,,, i was able to update F7 (currently updated, added mplayer,
audacious, openoffice, koffice and etc) to F8 using Jeremy's
updates-f8-yumloop.img on ONE PC, BUT on other one (with _same_ hardware
(ASUS MB P5B Deluxe with 4 Gb Mem, and very similar software for FC7)
"Checking dependences" again hangs more that 3 hours at 99 %. The
same picture with notebook (ASUS S5200) and F7 -- update hangsss! Thus
dependences for N packages, where N<100 could not be resolved by new
anaconda. We are waiting for the corrected release...
Its actually not that hard to change the DVD ISO file and create a new DVD.
After using tons of hours trying to upgrade FC7 > F8 on my FujitsuSiemens E8110
laptop with every other approach from these comments I took a closer look at
this page: http://fedoraproject.org/wiki/Anaconda/Updates where its suggested:
For Fedora Core 6 and later, put the file as images/updates.img in your Fedora
For that to succeed I needed an ISO editor which I found here:
http://littlesvr.ca/isomaster/ Its called "ISO Master" and is actually in the
FC7 repo. I needed it for FC6. So.. done as described, renamed katzj's image
file, from #28, to updates.img and copied to the "images" directory in the DVD
tree, created a new ISO and a new DVD.
Thats it, it worked right away, 1487 packages updated without a glitch.
BTW, the reason I really needed to change the ISO rather than waiting for a new
is that, down here in South Africa, we pay US$ 75 for 3GB bandwidth, so
downloading a new is not an option ;-) Keep well people.
(In reply to comment #65)
> dd if=updates-f8-yumloop.img of=/dev/sdc1 bs=72k count=20
In my case (1GB USB dongle) I had to copy content of the
'updates-f8-yumloop.img' file to an EXT2 partition. The filesystem on the image
had incorrect sector size for my drive.
It is better to test if you can mount your floppy or stick on running system
before using it with anaconda.
I have tried every solution without success but #112. Resolved deps and updated
1181 files. After reboot kde has disappear and I had to reinstall it. Fedora 8
seems faster than 7.
*** Bug 409591 has been marked as a duplicate of this bug. ***
Nothing given here helps installing Fedora 8 (mainly #82). It keeps hanging at
27% resolving package dependencies. This is the same for different hardware:
- Dell Precision 390
- Dell Precision 380
- VMware Workstation 6.0 and 6.0.1
I did not test further.
I again found anaconda trying to access /dev/sr0, which is not created. There
is a device /dev/scd0 used until anaconda starts up. anaconda itself seems to
try it with /dev/sr0. The rest seems to be errors working on data never read
Have a look at Bug 409591.
Looking into anaconda binaries, I found both /dev/scd0 and /dev/sr0 mentioned.
This is another data point. I was having problems on my Inspiron E1505 laptop
with upgrading from F7 to F8. The upgrade was hanging on the dependency check
at the 99% mark. The first time that I tried Jeremy's patch, the X server
detection had some kind of spurious error, and stopped. So I then switched over
to text mode. That went through the dependency check wonderfully. But it was
always complaining about getting I/O errors in certain sectors when trying to
load stage2.img. It was trying to read /dev/sr0 at that point. These errors
came up even though the CD had just passed the media check. I then decided to
try going back to graphical upgrade mode, and that worked like a charm. I now
have a nicely running F8 laptop.
On the basis of what was said in Comment #117 though, I would guess that there
is a string /dev/sr0 in the anaconda binary that is being hit at least in text mode.
*** Bug 407711 has been marked as a duplicate of this bug. ***
I followed the clear instructions at
and it upgraded properly. Still slow, but it was hours rather than days (which
it could have been if I hadn't given up with anaconda after 24 hours checking
These instructions *might* work for some of us. But they are not working in all
cases! If for what reason ever the update process breaks later on there is no
way back (except you had a backup). In most cases any attempt to restart kill
and restart yum will end up in some library missing to run yum. In a lot of
cases you will not even be able to start a command like "ls" without being
prompted about missing libraries!
Yum is intelligent enough to find out what to replace, but it is not
intelligent enough to build an intermediate system allowing at least to restart
the upgrade after rebooting (if at all your system reboots)! Since the upgrade
takes hours, there is a high risk of loosing the system.
It would be cool if the intermediate system could be built in scratch/temp
storage so that in case of failure, the user's system is not lost.
Perhaps this can be done in stages. A minimum Fedora8 is built and tested in
scratch/temp and if good, it is committed. The user's root system can be renamed
to /<date>renamed/ or something like that. (I have done this manually in the
distant past when install/update was balky)
When the committed system is rebooted (under minimum F8), the user can then
choose which applications to add. As confidence is gained, files can be deleted
or copied over from the /<date>renamed/ directory.
Disk space is checked and problems reported to the user before bad things happen..
There does seem to be a recent SRPM of anaconda.. 05-Dec-2007 03:00 4.0M
See (for example)
Actually a good start would be some kind of a "force install" option that
overrides the "this is already installed" thing. Right now once fedora thinks
that it is properly installed, even if it is not, it insists on not reinstalling
anything that it thinks is there.
Take another bug I have reported with about zero action from redhat. I had a
problem where if you took the defaults during the install you got a nonbootable
system. Now there was a way to override the defaults and get the boot
partition and boot loader to work. However, once you had run and
upgrade/install once even if you went back and selected the right overrides the
install system would not properly install because it immediately noticed
"nothing to do" and did nothing.
I can see this same thing applying here.
Same issue here. Is the fix from comment #26 going to be rolled into an Fedora
8.1 release, or just a respin of the Fedora 8 install DVD? (And whats the ETA?)
One would think that with such severe install issues that fixing the broken
install images would be paramount.
Regarding F8 respin, I just saw on Fedora Weekly News that it's on its way:
combination of comments 28, 40 & 60(with typo corrected0 worked well for me
after update from FC6 to F8 had hung at the 27% mark of resolving
dependencies.My only additions to software were those codecs needed to get
Kaffeine playbg DVDs sourced from Livna.from Frank Ryan
(In reply to comment #112)
> So.. done as described, renamed katzj's image
> file, from #28, to updates.img and copied to the "images" directory in the DVD
> tree, created a new ISO and a new DVD.
> Thats it, it worked right away, 1487 packages updated without a glitch.
My previous upgrades with the _old_ iso all got stuck (24hrs+) at 99.99%.
After patching the DVD image I finally succeeded in upgrading my box.
Thanks again for Your suggestion,
I tried this too, but without success. There where dependencies not solvable.
The problem seems to be yum building the forward *and* backward dependency list
for *every* rpm it likes to install:
assume "yum upgrade rpm\* yum\*" I'd expect yum to select all packages 'yum*'
in it's name for these packages I'd expect to have dependencies to be resolved.
The same for 'rpm*', leading to a list of packages (for F7):
[root@ivory ~]# rpm -q --requires yum
config(yum) = 3.2.8-2.fc7
python >= 2.4
python(abi) = 2.5
rpm >= 0:4.4.2
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
yum-metadata-parser >= 1.1.0
With yum this is not only resolved forward (yum requiring something), it is
also resolved backward (yum required by someting). This is bad and it seems it
is the source of most (if not all) updating problems, because it will lead to
unresolved dependencies if packets existing with F7 are not available any more
with F8. And it is bad, since it leads to lots of dependencies only solvable by
It would be a better idea to only solve forward dependencies per default,
leaving backward dependencies up to the users choice! This way it would be
possible to update yum, rpm and all forward dependencies, making sure the
update-system works within the new environment, then updating all other
packages, without breaking the update system. This breaks some packages
depending on yum temporarily, but who cares if I can update these later, making
them work again?
At the moment it depends on what you have installed on your system if an update
to a new release succeeds or breaks.
Has anyone found a fix for this so you can do the upgrade with yum.
I don't know if our intepid upgrade system authors have found the root cause of
this, but I think that I have. I tink it has to do with something previously
wrong in the upgrades. When I try and do a yum upgrade 7-8 I get
ERROR with rpm_check_debug vs depsolve:
Package dbus needs libexpat.so.0, this is not available.
Interestingly enough I find that there is a new dbus that doesn't require
libexpat.so.0 and instead needs libexpat.so.1. the so.0 is only required byt
the fc7 dbus. I am sure that you are saying so what????
Here is the so what I do a rpm -qa | grep dbus (I know but I find when I am
debugging I get more interesting data doing it this way than the direct way.)
anyway where is what I get
Notice the duplications. Now I have an advantage here. I have some old test
machines, and so extra test drives I made backups of my "problem children". So
I was able to attempt a new upgrade of these. Low and behold every one of the
packages after "package x requires y this is not available" is duplicated when I
look at a rpm -qa. That may be a big clue here.
Interesting. If you add a 'sort' the duplicates are easier to find.
[root@hoho2 looper]# rpm -qa | grep dbus | sort
(This was done on my running Fedora 7 system - no duplicates to show)
You can also add 'uniq' to the chain of commands to print only the duplicates.
Or, use 'uniq -c' to print the number of duplicates as in:
[root@hoho2 looper]# rpm -qa | grep dbus | sort | uniq -c
I think the duplicate dbus packages is a red herring. These sorts of dups show
up all the time on x86_64 machines, because there's both an i386 and x86_64
version of the package installed, which is normal. Try using "yum list" which
will show the architecture of the packages as well. For example, here's the
output from my FC6 x86_64 system:
[root@whisper Desktop]# yum list "*dbus*"
dbus.i386 1.0.1-12.fc6 installed
dbus.x86_64 1.0.1-12.fc6 installed
dbus-glib.x86_64 0.70-6.fc6 installed
dbus-glib.i386 0.70-6.fc6 installed
dbus-glib-devel.x86_64 0.70-6.fc6 installed
dbus-python.x86_64 0.70-6 installed
dbus-x11.x86_64 1.0.1-12.fc6 installed
Interesting. This is a i386 (well 32 bit) machine.
I originally tried to upgrade from FC 5, but I got stuck at 27% and at 99% with
the fix in comment 28. I upgraded to FC7 with no problems and tried again.
Comment #53 fixed it for me. package-cleanup is part of yum-utils which I had
to install. I started out with about 20 orphans, some of which were outside
packages like gizmo. After I cleaned up many of the orphans with rpm -e
[--nodep], I reinstalled the ones yum install could find. Then using the fix in
comment #28, I tried again. The dependency checker started and I went off to
get a cup of coffee and read my email. To my surprise, by the time I'd started
on my email, the dependency check was complete.
The install is complete, and everything seems to be working. Unfortunately,
when I ran package-cleanup --orphans after the install, 928 packages of the 930
the installation installed show up as orphans.
Maybe yum-upgraders should start a new bug? This bug was originally for
anaconda issues. I've upgraded 6 boxes remotely from 5->6->7->8 via yum in the
past month and have had ZERO issues related to this bug.
Update on comment #54. I just tried the fedoraunity re-spin
(Fedora-Unity-20071218-8-x86_64-DVD.iso) and this time I had no problems
whatsoever doing an upgrade.
So, at least for me, the Dec 18 re-spin cures this bug.
Where is the "respin"? Is there a respin of the boot disk for those of us who
need to do a network install?
As for comment 137. I have done a number of remote upgrades where this is a
continuing problem. But I do think that maybe the comment that this needs to
be a separate "bug" than this one might be well taken. I will say that many of
my upgrades which gave me this problem ran 4->5->6->7->8.
Look at http://spins.fedoraunity.org/unity/fedora-unity-re-spin-f8-20071218
You need to install jigdo, then do
and chose the iso/isos you want. It will then take some time...
This will download a whole DVD (or a set of CD:s), so perhaps this is not that
usable if you only want to do network install.
(In reply to comment #82)
Thank you Gordon, your suggestions worked for me:
1) Boot from DVD as normal
2) At the first screen, press ESC to get to boot: prompt
3) Type: linux updates=http://katzj.fedorapeople.org/updates-f8-yumloop.img
Typing this was very slow - character by character so make sure not to make
I didn't need to add "ip=dhcp" to the boot line, but maybe it is important for
some people. Fedora is now through the dependency checking and was stuck at
"Preparing transaction from installation source" for more than usual time approx
20 mins or so.
Now it is installing 1064 packages...hopefully the thrid-party MAILSERVER from
my previous FC7 installation works fine.
Good Luck Folks !!!
I second the comment on the typing this correctly. If you don't get it right
the system will not error out or anything. It will just ignore it and do the
same thing. If you get it right you will get a little box telling you that it
is loading the update and then everything will work right.
This is something which definitely needs to be fixed. If you type in updates-
and get something that doesn't work then it should give you an error message.
Should I file this as a seperate bug, as a request for an enhancement or what?
God bless fedorapeople! I followed directions of comment #142 and you know what?
It works great. I couldn't believe it while I saw the dependency progress bar
growing. It took about 7-10 minutes then it started upgrade all the 1225
packages of my fc7 in my laptop Dell Latitude D820. after 45-50 minutes all pkgs
were upgraded successfully.
I still can't understand why fedora distro is 4th in the ranking of the most
installed linux: it should be the 1st! I strongly suggest to follow those
instructions and have fun.
Thanx a lot again to Gordon and to all of those that have contributed to this.
*** Bug 426920 has been marked as a duplicate of this bug. ***
*** Bug 428778 has been marked as a duplicate of this bug. ***
I'm just getting around to upgrading my system to F8 now and am running into
this one in spades.
First attempt: follow instructions from comment #58 with a floppy. fdisk
session includes a prompt for extended or primary partition; I select the
latter, number 1, then 'w'rite. I "dd" the file to the floppy, restart the
machine, hit 'esc' and enter "linux updates" at the prompt. I run into the
"install exited abnormally" problem described in comment #47 et al. Assume for
the moment that I'm constrained to using a floppy: how do I fdisk it to get
update to handle it correctly?
Second attempt: A variation on comment #48. Once I get to the "Welcome to
Fedora" screen (the earliest that I can get a response out of 'ctl+alt+F2'),
I'll enter "mount /dev/fd0 /tmp/updates". PYTHONPATH already references this.
Run overnight. Same results: I'm 99% completed the next morning. Has anaconda
already checked the /tmp/updates directory and found it to be empty before I can
mount the floppy?
I never was able to get the floppy to work. There's no info on the "right" way
to do it (read: special voodoo sacrifices). I'd bet it's just plain broken!
The web way works perfectly, pop in a NIC temporarily and do that. Unless
someone can give definitive instructions on the floppy method...
I don't know about the floppy method, but the network method, while it works
does so only if you do the proper exact "voodoo sacrifices". If you type one
thing in wrong it will just silently fail to use the update, without any error
messages. While fedora is a great product this is one part that really needs a
re think. There will be patches to the install routine, and a better way to
include them that at the very least includes error messages when the include
fails would be of incredible use as more and more linux is getting into the main
Comment 140 mentions using the Fedora Unity respin, which is definitely the way
to go for upgrading to F8 in order to avoid this problem. While the updates
images can be helpful, I know that they are also a bit of a pain to work with.
I've changed anaconda to where if you do not give it the right URL, it will
prompt you. Of course that doesn't help with this bug report but it will help
in the future.
I encourage everyone to help test F9 before its final release so we can avoid
bugs like this in the next release. While we do perform upgrade testing, people
in real-world situations often have much more complex and interesting setups
that bring out bugs we did not discover internally.
Will we be able to add 3rd party repos like livna, freshrpms, etc.?
*** Bug 430350 has been marked as a duplicate of this bug. ***
Well, I used the Fedora Unity respin idea..
I went through the Jigado downloading - took about a day and a half - at the end
of this time I concluded that it had hung (even though ps showed pyjigdo was
still consuming CPU seconds) and killed it. By this time I thought that many of
the files included in the Fedora 8 Unity i386 12/18/2007 collection were also on
the original DVD disk.
So I went through the jig procedure again, with the DVD, and using the same work
directory as in the first trial. Jig found all of the files, and I presume
grabbed a few from online, and made the new respun iso image.
I created a new DVD from the iso image and then did the upgrade of my Fedora 7
system. It took exactly 2 hours of disk spinning time.
On my reboot, I notice that it seems to be booting XEN. I had XEN on my Fedora 7
system, but it was not being used.. curious.
The Fedora 7 system had 3 RAID partitions, /dev/md0 for /boot, /dev/md1 for swap
and /dev/md2 for a LVM /dev/rootvg/... (don't have it written down at the moment).
I am writing all this because the reboot has failed. The last few lines on my
screen are: (these are eyeball/hand copied from the screen, may have typos)
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
Red Hat nash version 6.0.19 starting
mdadm: /dev/md2 not identified in conf file.
mdadm: /dev/md1 has been started with 2 drives.
Reading all physical volumes. This may take a while...
No volume groups found
Volume group "rootvg" not found
mount: could not find filesystem '/dev/root'
setuproot: moving /dev failed: No such file or directory
setuproot: error mounting /proc: No such file or directory
setuproot: error mounting /sys: No such file or directory
switchroot: mount failed: No such file or directory
(I am obviously writing this from another machine..)
Any suggestions on what to do now?
I rebooted with the DVD inserted. By very quickly hitting a key, it is possible
to interrupt the boot process and get the menu allowing selection of the rescue
In rescue mode, I went to /etc/mdadm.conf and found that only 2 of the 3 lines
were written. This is familiar as the same problem occurred during my upgrade to
Now, to find my notes on that disaster..
See bug 241949, comment #6 which refers to bug 237415, see comments #5 and #7 there.
Doing that trick (due to firstname.lastname@example.org) worked in the update from Fedora6 to
Apparently the bug is still there, so I just added the last line of the output of
to the /etc/mdadm.conf file
(and changed the /boot/grub/grub.conf default=1 to step over the XEN and changed
the timeout to 10 from 5)
These changes were not sufficient because initrd is in control during the first
few critical seconds of the boot and it was made with the bad /etc/mdadm.conf file.
So, remake the initrd file..
See bug #241949 Comment #18. I used the mkinitrd command from comment #2, but
modified to use F8 file names. Also modified /boot/grub/grub.conf to pick up the
mkinitrd /boot/initrd-184.108.40.206-63-fixed.fc8.img 220.127.116.11-63.fc8
It looks pretty good..
Now it has halted trying to go into xorg-x11-server 18.104.22.168-36.fc8
Something about Requested Entity already in use!
But that is another problem..
The mdadm.conf bug is fixed in rawhide. We changed how anaconda handles the
devices and right now the mdadm.conf is created directly by mdadm, so it should
be ok :).
using updates=http://katzj.fedorapeople.org/updates-f8-yumloop.img fixes the
problem for me.
Before the fix, my laptop cranked for hours at 100% cpu usage and went into
Comment #112 From Rene Hansen Musvoto rocks.
I am going to use this on a rescuecd iso rather than downloading a respin.
(I use askmethod/nfs for upgrades)
We are sure getting a lot of ccs on this one. It was closed as successfully fixed a release ago, So if we are suddently seeing this again maybe someone should open a new bug with more details and reference this bug with why he/she things it is relevant.
This bug did not hit me on my recent F8->F10 anaconda upgrade. I think this bug is gone as of F9 rawhide. The CC's are just from it being such a popular nasty bug!