Bug 372011 - (f8upgdephang) depsolve hang in F7 to F8 upgrade
depsolve hang in F7 to F8 upgrade
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
8
All Linux
low Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
: 366641 371111 384081 390801 391631 391721 393121 407711 409591 426920 428778 430350 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-08 20:36 EST by Nicholas Miell
Modified: 2009-03-17 03:56 EDT (History)
48 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-24 11:14:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
anaconda.log (23.29 KB, text/plain)
2007-11-08 20:36 EST, Nicholas Miell
no flags Details
Representative strace output (2.21 MB, application/octet-stream)
2007-11-08 20:38 EST, Nicholas Miell
no flags Details
lsof output (19.65 KB, application/octet-stream)
2007-11-08 20:38 EST, Nicholas Miell
no flags Details
top and ps ax output on the system shortly before I killed it (5.90 KB, text/plain)
2007-11-08 20:40 EST, Nicholas Miell
no flags Details
output from yum on fc7 demonstrating loop (656.76 KB, application/x-gzip)
2007-11-09 13:32 EST, Brian Wheeler
no flags Details
anaconda.log with yum depsolving output (483.09 KB, text/plain)
2007-11-11 23:29 EST, Nicholas Miell
no flags Details
anacoda backtrace update from fd0 (56.76 KB, image/jpeg)
2007-11-13 15:13 EST, Danny Yarbrough
no flags Details
Machine hangs: graphical display (101.93 KB, image/jpeg)
2007-11-14 21:20 EST, Matthieu Pupat
no flags Details
Machine hangs: top display (90.23 KB, image/jpeg)
2007-11-14 21:20 EST, Matthieu Pupat
no flags Details
Packages removed to apply J.Katz´s fix (2.05 KB, application/octet-stream)
2007-11-15 23:30 EST, Esteban Xandri
no flags Details
anaconda dump file for my unhandled exception (57.93 KB, application/octet-stream)
2007-11-25 17:47 EST, Kevin J. Cummings
no flags Details
anaconda dump file for my unhandled exception (57.93 KB, application/octet-stream)
2007-11-25 17:49 EST, Kevin J. Cummings
no flags Details

  None (edit)
Description Nicholas Miell 2007-11-08 20:36:11 EST
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.
Comment 1 Nicholas Miell 2007-11-08 20:36:11 EST
Created attachment 252271 [details]
anaconda.log
Comment 2 Nicholas Miell 2007-11-08 20:38:06 EST
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.)
Comment 3 Nicholas Miell 2007-11-08 20:38:54 EST
Created attachment 252291 [details]
lsof output

lsof on anaconda, to make the strace log more meaningful
Comment 4 Nicholas Miell 2007-11-08 20:40:00 EST
Created attachment 252301 [details]
top and ps ax output on the system shortly before I killed it
Comment 5 Vladimir Florinski 2007-11-08 21:27:40 EST
Confirm bug on x86_64. Anaconda consumes 100% CPU and stalls at package
dependence check.
Comment 6 Vladimir Florinski 2007-11-08 21:37:26 EST
Just noticed that this is a duplicate of bug 371111. Looks like anaconda is
seriously broken...
Comment 7 Alexei Podtelezhnikov 2007-11-08 21:43:17 EST
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. 
Comment 8 Todd J Martin 2007-11-09 00:25:38 EST
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.
Comment 9 Sergio Morais Lietti 2007-11-09 05:52:39 EST
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.
Comment 10 Yovko Ilchev Yovkov 2007-11-09 08:05:25 EST
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).
Comment 11 Jeremy Katz 2007-11-09 09:11:08 EST
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
Comment 12 Phil 2007-11-09 10:51:49 EST
Jeremy, your update image didn't help. anaconda still hangs at 26%.
Comment 13 Todd J Martin 2007-11-09 10:54:16 EST
I just tried the update image and it did not solve the problem for me.  I see
exactly the same behavior as before.
Comment 14 Brian Wheeler 2007-11-09 13:32:59 EST
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.
Comment 15 Vladimir Florinski 2007-11-09 17:09:55 EST
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.
Comment 16 Phil 2007-11-09 18:39:01 EST
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.
Comment 17 Joachim Backes 2007-11-10 06:59:46 EST
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. 
Comment 18 growl 2007-11-10 09:34:36 EST
Have the same problem on i386.
It just always stuck at 26% on "Checking package
dependencies..." =\
Comment 19 Jim 2007-11-10 13:50:16 EST
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

Comment 20 Josep S. Blanes 2007-11-11 05:40:35 EST
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...
Comment 21 Michael Merwitz 2007-11-11 11:54:26 EST
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

Comment 22 Nicholas Miell 2007-11-11 23:29:18 EST
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.
Comment 23 Martin A. Boegelund 2007-11-12 04:13:37 EST
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.
Comment 24 Jared Robinson 2007-11-12 11:10:35 EST
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.
Comment 25 Jeremy Katz 2007-11-12 14:53:14 EST
*** Bug 366641 has been marked as a duplicate of this bug. ***
Comment 26 Jeremy Katz 2007-11-12 14:53:25 EST
*** Bug 371111 has been marked as a duplicate of this bug. ***
Comment 27 Jeremy Katz 2007-11-12 16:12:05 EST
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.
Comment 28 Jeremy Katz 2007-11-12 16:42:26 EST
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?
Comment 29 Robert Gadsdon 2007-11-12 18:37:56 EST
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 
Comment 30 Nick Lamb 2007-11-12 20:35:53 EST
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.
Comment 31 Paul Lemmons 2007-11-12 20:43:00 EST
Looks like it fixed it. I was able to get it installed and this update is coming
from a freshly upgraded system. Thank you!
Comment 32 Joe 2007-11-12 21:55:53 EST
I was also able to upgrade from FC6 to F8 using the updates-f8-yumloop.img from
comment #28. Thanks for the fix.
Comment 33 Void Main 2007-11-12 22:03:34 EST
I was also able to upgrade using this image. Thanks!
Comment 34 Esteban Xandri 2007-11-12 22:34:39 EST
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
Comment 35 Mariusz Wodzicki 2007-11-13 00:10:03 EST
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.
Comment 36 Joachim Backes 2007-11-13 01:49:47 EST
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).
Comment 37 Mariusz Wodzicki 2007-11-13 02:48:09 EST
Thank you, backes@rhrk.uni-kl.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.
Comment 38 Joachim Backes 2007-11-13 03:10:38 EST
Trying "linux
updates=http://http://katzj.fedorapeople.org/updates-f8-yumloop.img ip=...
nameserver=... gateway=... 

fails too: 

install exited abnormally

as described in #35
Comment 39 Mariusz Wodzicki 2007-11-13 03:51:37 EST
Thank you, backes@rhrk.uni-kl.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.
Comment 40 adriano 2007-11-13 06:36:01 EST
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).
Comment 41 Esteban Xandri 2007-11-13 07:44:18 EST
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
Comment 42 growl 2007-11-13 09:13:17 EST
Have the same trouble - "install exited abnormally [1/1]"
tested a floppy and a USB and nothings helped =(
Comment 43 Joachim Backes 2007-11-13 09:35:42 EST
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.
Comment 44 Chris Lumens 2007-11-13 10:16:59 EST
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.
Comment 45 jar 2007-11-13 11:43:46 EST
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.
Comment 46 Danny Yarbrough 2007-11-13 15:13:24 EST
Created attachment 257411 [details]
anacoda backtrace update from fd0
Comment 47 Danny Yarbrough 2007-11-13 15:15:04 EST
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)
Comment 48 Roy 2007-11-13 19:37:25 EST
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.
Comment 49 Jim 2007-11-13 19:47:57 EST
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
Comment 50 Mariusz Wodzicki 2007-11-13 22:49:07 EST
I can confirm the behaviour described in Comment #43 by backes@rhrk.uni-kl.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?
Comment 51 Mariusz Wodzicki 2007-11-13 23:00:54 EST
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.
Comment 52 Joachim Backes 2007-11-14 01:33:22 EST
(In reply to comment #48)

Was not helpful for me: the anaconda dependendcy checker stalled as usual at the
same place.
Comment 53 Tomas Linden 2007-11-14 04:58:14 EST
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.
Comment 54 Lars E. Pettersson 2007-11-14 05:08:33 EST
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.
Comment 55 Andre Costa 2007-11-14 07:29:56 EST
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
Comment 56 Joe Orton 2007-11-14 09:17:36 EST
Fixed for me with the newer updates.img - thanks Jeremy.
Comment 57 John W. Lockhart 2007-11-14 11:14:11 EST
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.
Comment 58 Ronald Kuetemeier 2007-11-14 16:13:04 EST
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.



  
Comment 59 Alejandro Gonzalez Hernandez - Imoq 2007-11-14 17:19:44 EST
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 :(
Comment 60 Andre Costa 2007-11-14 21:16:13 EST
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
Comment 61 Matthieu Pupat 2007-11-14 21:18:57 EST
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).
Comment 62 Matthieu Pupat 2007-11-14 21:20:07 EST
Created attachment 259251 [details]
Machine hangs: graphical display
Comment 63 Matthieu Pupat 2007-11-14 21:20:43 EST
Created attachment 259261 [details]
Machine hangs: top display
Comment 64 Esteban Xandri 2007-11-14 21:28:36 EST
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
Comment 65 Mariusz Wodzicki 2007-11-14 23:21:03 EST
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.
Comment 66 Jim 2007-11-15 10:22:29 EST
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.
Comment 67 Chris Lumens 2007-11-15 10:35:29 EST
*** Bug 384081 has been marked as a duplicate of this bug. ***
Comment 68 Esteban Xandri 2007-11-15 11:40:25 EST
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?
Comment 69 Trevor Cordes 2007-11-15 11:58:49 EST
"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.
Comment 70 Imre Gergely 2007-11-15 13:42:23 EST
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.
Comment 71 Andre Costa 2007-11-15 15:59:55 EST
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 =(
Comment 72 Bob Gustafson 2007-11-15 17:04:01 EST
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
Comment 73 Chris Lumens 2007-11-15 17:46:29 EST
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
Comment 74 Jim 2007-11-15 18:06:50 EST
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
Comment 75 James Heather 2007-11-15 18:29:09 EST
(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
Comment 76 Mariusz Wodzicki 2007-11-15 23:15:25 EST
[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?
Comment 77 Mariusz Wodzicki 2007-11-15 23:18:22 EST
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?]
Comment 78 Esteban Xandri 2007-11-15 23:30:12 EST
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
Comment 79 Trevor Cordes 2007-11-16 10:34:14 EST
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?
Comment 80 Daniel Thompson 2007-11-17 06:44:35 EST
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.
Comment 81 Martí­n Marqués 2007-11-17 12:10:05 EST
Can't a new DVD image be done with this fix?
Comment 82 Gordon L 2007-11-17 15:35:24 EST
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.
Comment 83 cje 2007-11-17 19:09:58 EST
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! :-)
Comment 84 cje 2007-11-18 15:50:01 EST
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.
Comment 85 Jeff Peterson 2007-11-18 22:11:15 EST
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.
Comment 86 Andrew 2007-11-19 09:15:13 EST
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.
Comment 87 Chris Lumens 2007-11-19 13:25:12 EST
*** Bug 390801 has been marked as a duplicate of this bug. ***
Comment 88 Igor Chudov 2007-11-19 14:56:05 EST
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)
Comment 89 Panu Matilainen 2007-11-20 05:37:00 EST
*** Bug 391721 has been marked as a duplicate of this bug. ***
Comment 90 Jeremy Katz 2007-11-20 11:19:50 EST
*** Bug 391631 has been marked as a duplicate of this bug. ***
Comment 91 Jeremy Katz 2007-11-21 09:19:52 EST
*** Bug 393121 has been marked as a duplicate of this bug. ***
Comment 92 Ray Todd Stevens 2007-11-21 09:39:02 EST
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.
Comment 93 Igor Chudov 2007-11-21 15:24:36 EST
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. 
Comment 94 Ray Todd Stevens 2007-11-21 16:11:02 EST
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.
Comment 95 Massimo Di Primio 2007-11-22 06:25:39 EST
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.
Comment 96 James Heather 2007-11-22 06:44:51 EST
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?
Comment 97 Andre Costa 2007-11-22 06:46:45 EST
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?
Comment 98 Martí­n Marqués 2007-11-22 06:56:51 EST
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.
Comment 99 Ville-Pekka Vainio 2007-11-22 08:39:56 EST
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.
Comment 100 josip 2007-11-22 13:55:53 EST
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.
Comment 101 Didier 2007-11-22 17:20:57 EST
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.
Comment 102 Ray Todd Stevens 2007-11-22 20:01:27 EST
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 103 Bob Gustafson 2007-11-23 02:18:13 EST
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?
Comment 104 Ray Todd Stevens 2007-11-23 11:05:31 EST
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.
Comment 105 Imre Gergely 2007-11-23 12:27:41 EST
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 :)
Comment 106 Martí­n Marqués 2007-11-23 12:40:41 EST
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.
Comment 107 Andre Costa 2007-11-23 14:11:22 EST
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.
Comment 108 Kevin J. Cummings 2007-11-25 17:47:24 EST
Created attachment 268361 [details]
anaconda dump file for my unhandled exception
Comment 109 Kevin J. Cummings 2007-11-25 17:48:21 EST
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.
Comment 110 Kevin J. Cummings 2007-11-25 17:49:34 EST
Created attachment 268371 [details]
anaconda dump file for my unhandled exception
Comment 111 Sergei Trushkin 2007-11-30 07:02:20 EST
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...
Comment 112 Rene Hansen Musvoto 2007-11-30 20:25:16 EST
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.
Comment 113 Rene Hansen Musvoto 2007-11-30 20:30:19 EST
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.
Comment 114 Cezary Zemis 2007-12-03 05:34:48 EST
(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.  
Comment 115 kraniask 2007-12-03 14:47:48 EST
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.
Comment 116 Chris Lumens 2007-12-03 17:55:07 EST
*** Bug 409591 has been marked as a duplicate of this bug. ***
Comment 117 Thomas Schweikle 2007-12-03 18:53:09 EST
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.
Comment 118 John Guthrie 2007-12-04 14:24:32 EST
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.
Comment 119 Jeremy Katz 2007-12-04 16:46:35 EST
*** Bug 407711 has been marked as a duplicate of this bug. ***
Comment 120 Nigel Horne 2007-12-05 03:09:15 EST
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)
Comment 121 Thomas Schweikle 2007-12-05 16:19:21 EST
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.
Comment 122 Bob Gustafson 2007-12-05 17:30:25 EST
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..
Comment 123 Bob Gustafson 2007-12-05 17:42:32 EST
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
Comment 124 Ray Todd Stevens 2007-12-05 18:01:18 EST
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.
Comment 125 Steve Lacy 2007-12-12 21:31:52 EST
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. 
Comment 126 Andre Costa 2007-12-13 14:26:04 EST
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
Comment 127 Frank Ryan 2007-12-15 00:07:33 EST
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
Comment 128 Giovanni Trevisan 2007-12-17 12:56:25 EST
(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, 
Comment 129 Thomas Schweikle 2007-12-17 19:55:18 EST
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.
Comment 130 Ray Todd Stevens 2007-12-20 22:21:04 EST
Has anyone found a fix for this so you can do the upgrade with yum.
Comment 131 Ray Todd Stevens 2007-12-20 22:59:21 EST
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.
Comment 132 Bob Gustafson 2007-12-21 00:13:55 EST
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)
Comment 133 Bob Gustafson 2007-12-21 00:22:30 EST
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]# 
Comment 134 Steve Lacy 2007-12-21 01:27:12 EST
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       
[...]
Comment 135 Ray Todd Stevens 2007-12-21 10:05:29 EST
Interesting.   This is a i386 (well 32 bit) machine.
Comment 136 harry 2007-12-23 20:16:35 EST
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.
Comment 137 Trevor Cordes 2007-12-24 09:11:53 EST
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.
Comment 138 Lars E. Pettersson 2007-12-27 10:34:05 EST
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.
Comment 139 Ray Todd Stevens 2007-12-27 10:55:22 EST
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.
Comment 140 Lars E. Pettersson 2007-12-27 11:25:14 EST
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.
Comment 141 Niraj Kapadia 2007-12-27 17:52:53 EST
(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 !!!
Comment 142 Ray Todd Stevens 2007-12-27 19:32:05 EST
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?
Comment 143 Massimo Di Primio 2007-12-28 15:03:53 EST
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.
Comment 144 Jeremy Katz 2007-12-29 20:46:06 EST
*** Bug 426920 has been marked as a duplicate of this bug. ***
Comment 145 Chris Lumens 2008-01-15 10:03:33 EST
*** Bug 428778 has been marked as a duplicate of this bug. ***
Comment 146 Frank Solensky 2008-01-15 11:00:00 EST
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..
Comment 147 Trevor Cordes 2008-01-15 15:34:06 EST
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...
Comment 148 Ray Todd Stevens 2008-01-15 23:39:20 EST
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 149 Chris Lumens 2008-01-24 11:14:18 EST
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.
Comment 150 Martí­n Marqués 2008-01-24 13:24:40 EST
Will we be able to add 3rd party repos like livna, freshrpms, etc.?
Comment 151 Jon Stanley 2008-01-26 17:44:21 EST
*** Bug 430350 has been marked as a duplicate of this bug. ***
Comment 152 Bob Gustafson 2008-02-05 12:53:55 EST
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?
Comment 153 Bob Gustafson 2008-02-05 13:17:07 EST
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..
Comment 154 Bob Gustafson 2008-02-05 17:23:37 EST
See bug 241949, comment #6 which refers to bug 237415, see comments #5 and #7 there.

Doing that trick (due to bbaetz@acm.org) 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..


Comment 155 Joel Andres Granados 2008-02-06 04:54:04 EST
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 :).
Comment 156 Frank DiPrete 2008-05-03 21:24:21 EDT
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*
Comment 157 Ray Todd Stevens 2009-03-11 19:58:40 EDT
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.
Comment 158 Trevor Cordes 2009-03-12 04:22:12 EDT
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!

Note You need to log in before you can comment on or make changes to this bug.