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. How reproducible: Always. Steps to Reproduce: 1. Boot upgrade CD 2. Click buttons 3. Wait Actual results: 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] anaconda.log
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 output 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 dependence check.
Just noticed that this is a duplicate of bug 371111. Looks like anaconda is seriously broken...
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 problem? The use of update images is described at http://fedoraproject.org/wiki/Anaconda/Updates
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: [main] cachedir=/var/cache/yum keepcache=0 debuglevel=2 logfile=/var/log/yum.log exactarch=1 obsoletes=1 gpgcheck=1 plugins=1 metadata_expire=1800 installonly_limit=2 # PUT YOUR REPOS HERE OR IN separate files named file.repo # in /etc/yum.repos.d [InstallMedia] name=Fedora 8 mediaid=1194015916.783841 metadata_expire=-1 gpgcheck=0 cost=500 baseurl=file:///media/Fedora%208%20x86_64%20DVD/ 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 following: mplayer and dependencies vlc and dependencies (incl. compat-wxGTK) k3b libdga gnome office and dependencies (gnucash, gnumeric, goffice04, libgsf-gnome) inkscape, ImageMagick-c++, ImageMagick-perl, pstoedit gstreamer-plugins-bad 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 "Everything"-repository, though). So my thought is that the F8 installation dvd is incomplete and missing some packages.
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 dependencies..." =\
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. Jim Cicon
anaconda hangs in postselection in F7 to F8 upgrade From Fedora 7 (i386) In directory Packages of DVD Fedora 8: # rpm -Uvh fedora-release-* No problem! But, # 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 package: openoffice.org-emailmerge --> Processing Dependency: kdemultimedia = 6:3.5.7-2.fc7 for package: kdemultimedia-extras --> Processing Dependency: kdeutils = 6:3.5.7-1.fc7.1 for package: kdeutils-extras --> 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: openoffice.org-pyuno --> Processing Dependency: openoffice.org-core = 1:2.3.0-6.4.fc7 for package: openoffice.org-javafilter --> Processing Dependency: openoffice.org-core = 1:2.3.0-6.4.fc7 for package: openoffice.org-base --> Processing Dependency: tcp_wrappers-libs = 7.6-48.fc7 for package: tcp_wrappers-devel --> 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: gnome-python2-gtksourceview 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) ant-apache-bsf-1.6.5-4jpp.2.fc7.i386 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-1.5.3.3-3.fc7.i386 freeglut = 2.4.0-11.fc7 is needed by (installed) freeglut-devel-2.4.0-11.fc7.i386 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) glib-devel-1.2.10-26.fc7.i386 gnome-python2-desktop = 2.18.0-1.fc7 is needed by (installed) gnome-python2-gtksourceview-2.18.0-1.fc7.i386 gnome-python2-extras = 2.14.3-5.fc7 is needed by (installed) gnome-python2-gtkspell-2.14.3-5.fc7.i386 gtk+ = 1:1.2.10-57.fc7 is needed by (installed) gtk+-devel-1.2.10-57.fc7.i386 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) kdemultimedia-extras-3.5.7-2.fc7.i386 kernel-i686 = 2.6.23.1-10.fc7 is needed by (installed) kmod-nvidia-100.14.19-1.2.6.23.1_10.fc7.i686 kernel-i686 = 2.6.23.1-21.fc7 is needed by (installed) kmod-nvidia-100.14.19-1.2.6.23.1_21.fc7.i686 libgpod.so.1 is needed by (installed) gtkpod-0.99.8-3.fc7.i386 libgsf = 1.14.3-4.fc7 is needed by (installed) libgsf-gnome-1.14.3-4.fc7.i386 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) libusb-devel-0.1.12-7.fc7.i386 libutempter = 1.1.4-3.fc6 is needed by (installed) libutempter-devel-1.1.4-3.fc6.i386 lucene = 0:1.4.3-1jpp.18 is needed by (installed) lucene-demo-1.4.3-1jpp.18.i386 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-base-2.3.0-6.4.fc7.i386 openoffice.org-core = 1:2.3.0-6.4.fc7 is needed by (installed) openoffice.org-pyuno-2.3.0-6.4.fc7.i386 openoffice.org-writer = 1:2.3.0-6.4.fc7 is needed by (installed) openoffice.org-emailmerge-2.3.0-6.4.fc7.i386 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) poppler-utils-0.5.4-7.fc7.i386 qt-devel = 1:3.3.8-7.fc7 is needed by (installed) qt-devel-docs-3.3.8-7.fc7.i386 subversion = 1.4.4-1.fc7 is needed by (installed) subversion-perl-1.4.4-1.fc7.i386 unixODBC = 2.2.12-2.fc7 is needed by (installed) unixODBC-kde-2.2.12-2.fc7.i386 vim-common = 2:7.1.12-1.fc7 is needed by (installed) vim-X11-7.1.12-1.fc7.i386 xine-lib = 1.1.7 is needed by (installed) xine-lib-extras-nonfree-1.1.7-1.lvn7.i386
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 afternoon.
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... Robert Gadsdon
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 http://fedoraproject.org/wiki/Anaconda/Updates 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 in: `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.
Mariusz, 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, backes.de, 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.
Trying "linux updates=http://http://katzj.fedorapeople.org/updates-f8-yumloop.img ip=... nameserver=... gateway=... fails too: 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: linux updates. 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: linux updates=http://my.website.com/path/to/updates-f8-yumloop.img ..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: [0x804a030] [0x110420] [0x81a53bb] [0x818e0b7] [0x8198ca6] [0x81929b2] [0x804a460] [0x804c0f6] [0x8175004] [0x8048151] 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 case)
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 disks) - 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. Jim Cicon
I can confirm the behaviour described in Comment #43 by backes.de. 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 same place.
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 the problem. System here is Fedora 7, x86_64, fully updated.
Hi, 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. Regards, Andre
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. So fdisk /dev/sdc create new partition "n" write w don't forget to quit :-) dd if=xxxx.img of=/dev/sdc1 //!!!!!!! there's a 1 there Should work. 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 linux updates=http://katzj.fedoraproject.org/updates-f8-yumloop.img ip=dhcp 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) HTH Andre
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 attached picture). 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 dialog. 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 be installed. 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 updates=http://katzj.fedorapeople.org/updates-f8-yumloop.img 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 other components. 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: https://fedoraproject.org/wiki/Bugs/F8Common
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 ;-) Jim Cicon
(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. James
[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: > https://fedoraproject.org/wiki/Bugs/F8Common The first thing anybody is seeing is usually http://docs.fedoraproject.org/ and the highly visible link http://docs.fedoraproject.org/release-notes/ which contains the misleading section: Common bugs For a list of common known bugs in the F7 release, refer to: http://fedoraproject.org/wiki/Bugs/F7Common Another "bug"? Should that be F8, and the link should be to http://fedoraproject.org/wiki/Bugs/F7Common instead?
Sorry for the typo, hit the `Save Changes' button too early: the last link should be of course http://fedoraproject.org/wiki/Bugs/F8Common [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 definitely needed. 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 contained "initrd=") 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 .rpmnew 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 system? 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 testing.
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 have existed.
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 my machines. 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.
Hi all, 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 problem soon.
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 comment #73. 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 updated image.
I agree with comment #99 -- this happens on pure Fedora systems without any 3rd party RPMs. 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 developers. 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 main release?
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). Jeremy? 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 installation tree. 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 from DVD. 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 http://www.howtoforge.com/upgrading-fedora7-desktop-to-fedora8 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 for compatibilities)
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) http://mirrors.kernel.org/fedora/development/source/SRPMS/anaconda-11.4.0.5-1.src.rpm
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: http://kanarip.blogspot.com/2007/12/fedora-8-re-spin-in-making.html
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 /usr/bin/python config(yum) = 3.2.8-2.fc7 python >= 2.4 python(abi) = 2.5 python-sqlite rpm >= 0:4.4.2 rpm-python rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 urlgrabber 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 hand. 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 Running rpm_check_debug ERROR with rpm_check_debug vs depsolve: Package dbus needs libexpat.so.0, this is not available. Complete! 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 dbus-python-0.82.3-1.fc7 dbus-devel-1.0.2-6.fc7 dbus-glib-0.73-3.fc7 dbus-x11-1.0.2-6.fc7 dbus-1.0.2-6.fc7 dbus-1.0.2-6.fc7 dbus-glib-0.73-3.fc7 dbus-qt-0.70-1.fc7 dbus-devel-1.0.2-6.fc7 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 dbus-1.0.2-6.fc7 dbus-devel-1.0.2-6.fc7 dbus-glib-0.73-3.fc7 dbus-glib-devel-0.73-3.fc7 dbus-python-0.81.1-1.fc7 dbus-sharp-0.63-6.fc6 dbus-x11-1.0.2-6.fc7 [root@hoho2 looper]# (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 1 dbus-1.0.2-6.fc7 1 dbus-devel-1.0.2-6.fc7 1 dbus-glib-0.73-3.fc7 1 dbus-glib-devel-0.73-3.fc7 1 dbus-python-0.81.1-1.fc7 1 dbus-sharp-0.63-6.fc6 1 dbus-x11-1.0.2-6.fc7 [root@hoho2 looper]#
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*" [...] Installed Packages 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. Same symptoms. 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.
Interesting. 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 jigdo-lite http://jigdo.fedoraunity.org/templates/20071218/Fedora-Unity-20071218-8.jigdo 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 spelling mistakes. 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? TIA..
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 stream.
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)... (XEN)... (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 mode. 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 Fedora 7. 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 bbaetz) worked in the update from Fedora6 to Fedora7. Apparently the bug is still there, so I just added the last line of the output of mdadm -Es 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 new initrd. cd /boot mkinitrd /boot/initrd-2.6.23.8-63-fixed.fc8.img 2.6.23.8-63.fc8 ---- It looks pretty good.. Now it has halted trying to go into xorg-x11-server 1.3.0.0-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 thermal shutdown. 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) *nice*
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!
Todo os Veículos seminovos, venda de carros estão no portal do AnuncicarBH, onde contamos também com um Blog de carros notícias onde você acompanha Notícias do mundo automobilístico, https://anuncicarbh.com/blog seminovos em Belo Horizonte. Você de de MG pode fazer seu cadastro, super rápido no portal e anunciar gratuitamente, Carros novos e seminovos e https://anuncicarbh.com Compra e venda de motos.