Bug 213592 - anaconda goes south and leaves an installation in a sorry state
anaconda goes south and leaves an installation in a sorry state
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-02 00:56 EST by Michal Jaegermann
Modified: 2008-05-06 12:39 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 12:39:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
the first process snapshot (4.02 KB, text/plain)
2006-11-07 21:17 EST, Michal Jaegermann
no flags Details
the second process snapshot (4.02 KB, text/plain)
2006-11-07 21:18 EST, Michal Jaegermann
no flags Details
whole saved install.log.syslog from an installation crashing in "Performing postinstall..." (3.79 KB, text/plain)
2006-11-14 23:21 EST, Michal Jaegermann
no flags Details
stacktrace screenshot (517.07 KB, image/jpeg)
2006-11-17 07:07 EST, Ferry Huberts
no flags Details

  None (edit)
Description Michal Jaegermann 2006-11-02 00:56:14 EST
Description of problem:

This is, in principle, a repeat of posting
https://www.redhat.com/archives/fedora-test-list/2006-November/msg00012.html
Rahul asked for a bugzilla entry so here we go.

The FC6 release by itself is fine but anaconda, or something below it
looks mighty sick.  So far I had that experience on three different
machines - one i386, two x86_64 but different mobos/chipsets and two
updates (i386 and x86_64) and one a fresh install on a "virgin"
hardware.

The issue is that at some moment during an installation anaconda
dies.  Most likely at the last moment when all post-installation
tasks should be performed.  No access to anything, a keyboard is
dead, a mouse is dead too or no reaction to it, no traces in logs on
post-mortem.  The only thing one can do is to hit a power switch.
Not repeatable, as the next try can as well finish although results
will be far from clean, and not much to report beyond "it's dead,
Jim!".

With a new installation this left a machine unbootable as there was
nothing in /boot/grub/.  The hang happened when an installation of
all packages was already done. A subsequent reinstallation of FC5 on
the same hardware - everything was silky smooth.  During one of
updates a hang happened during an install of 'firstboot', which is
the last one in a queue, while progress bar still had a small bit to
advance.

For updates most of work was done but I was left with a nasty
cleanup job of tons of duplicate packages, where was not always
obvious which should be gone, and even more "interesting" task if
multilib was involved. (Those with distro indentifier in version
helped as one can do 'yum remove "*fc4*" "*FC4*"', or similar, and
this catches some dependent ones too; 'package-cleanup --orphans' is
also a good idea).  Due to known rpm issues this steps removed
assorted files common to old and new packages and now it was
necessary fish out and fix that.  All of that doable but a lot of
completely unnecesary work which left bad taste in mouth.  Sigh!
After all of this was acomplished then we were indeed in an
excellent shape.

Bug #213549 appear to talk about a similar issue but it limited to
an installation over FTP.  In cases above installation packages were
either mounted over NFS or present on a local disk.

Additional info:
I am afraid that machines just "went through my hands" and I do not
have an access to answer questions about particulars of that hardware
and/or BIOSes nor I can try there some kernel options.  Regardless
all three cases were different and, in particular, I did not have any
issues with video or otherwise.  Once the whole "post-installation"
mess was cleaned up everything just worked without any "heroic efforts"
and "exotic kernel options".
Comment 1 Jeremy Katz 2006-11-06 10:26:12 EST
So it's completely unresponsive (ie, switch vts doesn't work)?  Are the keyboard
leds flashing?
Comment 2 Michal Jaegermann 2006-11-06 10:37:54 EST
Yes, in all three cases described above there was no response.
No possibility to switch to another vt to check whatever and
no lights happening on a keyboard.

Initially a mouse cursor could be still active, so one hopes that
the whole process will still recover as some operations are really
slow, but after a while this stops responding as well and one
knows that nothing will happen anymore.
Comment 3 Jeremy Katz 2006-11-06 11:03:00 EST
No vt switch means it's fully hung in the kernel
Comment 4 Michal Jaegermann 2006-11-06 23:23:53 EST
I have one more similar case but "better" this time - in that sense that
it did not freeze.

An upgrade from FC4 on an i386 laptop.  It was sitting with an
"Estimated completion time 6 minutes" and installing "firstboot-1.3.42-1"
for a minimum 45 minutes, quite possibly longer (I was away).

At that time on vt1 there was continuously scrolling, at a rate
approximately one line every 20-30 seconds, the following message:

rpmdb: unable to allocate space from the buffer cache

The moment I decided to investigate on vt2 which processes may be
involved I got "Reboot" screen and that upgrade was at last
complete - or at least it claimed to be.  See below.

I saved anaconda.log and syslog but there is really nothing interesting
there.  They were written last time really hours before a completion
time.  The last entry in anaconda.log says:

Initial install time estimate = 820.882977437

which is really out-of-whack (but later estimates displayed on
a screen were talking about something like 945 minutes or maybe even
longer).

To make things more "interesting" after all this to and fro
an output from 'package-cleanup --dupes | grep -v 'Setting up' 
is 1014 lines long (yes, you read that correctly) and that means
that I have a big cleanup job ahead even if an upgrade apparently
finished ok.  Even bigger SIGH!  Yes, it could be done but clearly
not a job for a casual user.
Comment 5 Michal Jaegermann 2006-11-07 01:42:39 EST
Closer examination of results of an "update" described in comment #4
revealed that a mess is much more substantial than I thought.
Among duplicate packages I ended up with

fedora-release-6-4.noarch
fedora-release-4-2.noarch

Even after fedora-release-4-2.noarch removal yum was somehow convinced
that I have an FC4 installation and tried to pick corresponding packages,
say, from "extras".  Moreover, the _sole_ version of yum reported was
yum-2.4.1-1.fc4.noarch and all 'rpm...' packages were 4.4.1-23 while
they should be 4.4.2-32.

While it was possible to install, with a help of rpm, 'yum-3.0-6',
as various underlying python packages were among duplicates, yum now
is reporting errors and resolves badly anyway.  All in all - a total
mess.  The whole installation is likely not recoverable in a sane
manner (despite of beeing bootable - at least to level 3 but not
higher as xorg-x11-server-Xorg-1.1.1-47.fc6 was not installed at
all although some 'xorg-x11-*fc6*' packages are in). Over many
years and distro upgrades I do not ever recall a disaster even close
to that one.
Comment 6 Michal Jaegermann 2006-11-07 21:17:18 EST
Created attachment 140613 [details]
the first process snapshot

These are results of the second attempt to run an update
on the same laptop as before.  I restored the whole
system to an initial state using a backup, just in case
run 'rpm --rebuilddb' twice, and started an update from
scratch. 'anaconda' reached "Preparing ... transaction"
(or something in this sense) and for roughly two and
a half ours was twirling on a screen an hourglass cursor
without getting anywhere.  At that moment I decided that
enough is enough and abandoned the project.  At least
the system was not left in some messed up state.

There is currently 952 packages listed on this system
in /var/log/rpmpkgs and, counting retrieved headers,
an upgrade should replace and/or install 963 packages.

The last line in anaconda.log (all times UTC) reads

21:55:38 DEBUG	 : Adding Package xorg-x11-drv-i128 - 1.2.0-4.i386 in mode u

Nothing of a particular interest in syslog.

I tried to look at an output of 'ps uwwaxf' and 'free -m' at
23:08:53 UTC 2006 and 00:22:11 UTC 2006.  Results do not
differ very much.  Attached. 'top' also did not show up
any process taking really any resources or memory (actually
everything but 'top' was at 0 or very close to it). A peek
at /tmp/cache, just before I broke the whole attempt around
0:40 UTC showed this:

# ls -l /tmp/cache
total 0
drwxr-xr-x 4 root 0 0 Nov  7 21:50 anaconda-base-200610172011.i386
drwxr-xr-x 2 root 0 0 Nov  7 21:41 headers
# ls -lrt /tmp/cache/anaconda-base-200610172011.i386
total 20568
-rw-r--r-- 1 root 0   790254 Oct 18 00:44 primary.xml.gz
-rw-r--r-- 1 root 0  2491036 Oct 18 00:44 filelists.xml.gz
-rw-r--r-- 1 root 0	1296 Oct 18 00:44 repomd.xml
-rw-r--r-- 1 root 0   853899 Oct 18 00:44 comps.xml
drwxr-xr-x 2 root 0	   0 Nov  7 21:41 packages
-rw-r--r-- 1 root 0	   0 Nov  7 21:41 cachecookie
-rw-r--r-- 1 root 0  4645888 Nov  7 21:41 primary.xml.gz.sqlite
-rw-r--r-- 1 root 0 12264448 Nov  7 21:50 filelists.xml.gz.sqlite
drwxr-xr-x 2 root 0	   0 Nov  7 21:55 headers

Maybe I will try one more time or maybe I will just
write a script, using an information from retrieved headers,
and will ask 'rpm' to install needed packages and will be
done with it.

Over many years this is the first time I run into so
many problems.	It appears that 'yum' got too big chunk
to chew on.

BTW - all three machines from an initial report had way
more than 256K of memory.
Comment 7 Michal Jaegermann 2006-11-07 21:18:15 EST
Created attachment 140614 [details]
the second process snapshot
Comment 8 Michal Jaegermann 2006-11-09 16:29:01 EST
The same laptop as in comment #4.  Against a better judgement I tried
the same upgrade operation for the third time.  Surprise!  This time
it worked.  Nothing seriously messed up or got stuck.  It took a very
long time but it eventually finished.  It was sitting for something
like an hour, or maybe even longer, in a screen telling me
"Installing firstboot-1.4.23-1" and "Estimated completion time 6 minutes",
but it got through it eventually.  I was moving a mouse pointer from
time to time to check if it makes an impression of beeing still alive
but it reacted.

This time the full list of duplicates looks as follows:

librsvg2-2.16.0-2.fc6.i386
librsvg2-2.9.5-2.i386
libwmf-0.2.8.4-10.i386
libwmf-0.2.8.3-8.2.i386
selinux-policy-strict-1.27.1-2.27.noarch
selinux-policy-strict-2.3.18-10.noarch

All cases of "scriptlet failed, exit status 1" and trivial to
clean up.

Here are the last lines from anaconda.log:

01:50:32 DEBUG   : Adding Package xorg-x11-drv-i128 - 1.2.0-4.i386 in mode u
02:36:01 INFO    : Initial install time estimate = 196.838670509
06:50:51 INFO    : moving (1) to step postinstallconfig
06:50:55 INFO    : moving (1) to step instbootloader
06:50:59 INFO    : moving (1) to step copylogs
06:50:59 INFO    : Copying anaconda logs
06:50:59 INFO    : moving (1) to step dopostaction
06:50:59 INFO    : moving (1) to step methodcomplete
06:50:59 INFO    : moving (1) to step complete

Pay attention to times recorded.

My best guess is that the current anaconda is using yum to perform
not only dependency resolution but the whole job.  yum has this
unfortunate characteristic that first it does all updates/installations
and cleanups later all in one transaction.  This is fine for a typical
amount of packages in a usual update but it seems to elicit
a "quadratic behaviour" when a transaction gets bigger.  Maybe not
on really fast machines with tons of memory but I have seen that
many times on more usual occasions.  For example, it is not a wise
move to start at this time with a fresh FC5 installation and apply all
updates, even if available locally, in one scoop instead of doing
something like this (or a bit more smarter):

  for p in a b c d e f g h i j k l m n o p q r s t u v w x y z ; do
     yum update "$p*"
  done
  yum update

Even with an extra dependency resolution one usually ends up
seriously ahead.

Also a failure mode with one huge transaction is really nasty.
If something will go wrong, and from time to time it does for
whatever reasons, then one is left with a huge pile of duplicate
packages not really trivial to clean up and preatty good chance
that even a "system recovery minimum" is not in a workable state.

It would be likely much safer, quicker and lighter on resources
if after an initial dependency resolution anaconda would do

   rpm -Uvh --force --nodeps ....

with a list of packages simple to produce from what is collected
in /tmp/cache/anaconda-base-200610172011.i386/headers/
Actually this is what I planned to do if that upgrade attempt would
fail too.  Surely I would not wait that long.  This is serious if
you have a number of machines to upgrade.

BTW - what for is an empty directory /tmp/cache/headers/?  Some
leftover or it is really used?  
Comment 9 Michal Jaegermann 2006-11-14 23:19:01 EST
Yesterday I had an opportunity to do some installation experimentes.
Hardware was x86_64 ASUS M2NPV-VM mobo with an updated BIOS.
FC5 installs on there without any trace of hiccups and the latest
FC5 kernels work just fine (as well as FC6 kernels if you will get
through an installation).  In all trials a network boot was used
and an installation tree was mounted via NFS.  All installation
were "from scratch", i.e. remove all partitions, accept a default
partitioning, continue from there.

Adding options like 'noapic', 'acpi=off' or even 'selinux=0' (I tried
that in an attempt to reduce a disk traffic) has no influence on an outcome
- positive or negative.

There is a way to install FC6 with a 100% success rate.  Namely
one needs to choose, on a appriopriate screen, "Customize now" and
deselect _everything_ which is by default selected with an exception
of "Base" and "Administration tools".  This ends up installing roughly
1 Gig of sofware.  The whole process finishes in few minutes, all
packages are so quickly transferred to a disk that this is joyfull to
watch, and no erros ever show up.  I tried that at least five times
adding extra kernel parameters or not.  Reboot and then it is possible
to use yum to expand on a list of installed packages.  No problems.

I did not try to find out what is a minimum which I need to deselect
in order to finish an installation.

That picture is markedly different if defaults are accepted everywhere
where they can be.  On many attempts (and a friend of mine previously
tried to get FC6 on that machine a few times) NONE succeeded.
Anaconda invariably wedges.  This happens and diffrent times.
While "Preparing transaction to install" with not a single package
put to a disk yet, in the middle of an installation, while
installing "firstboot-1.4.23-1" (an extremely popular "choice") and
once even while "Performing a postinstallation configuration".

The last case was "interesting" one.  The machine turned out to be
actually bootable but I had to type everything at 'grub>' prompt
because /boot/grub/ was totally empty save of splash.xpm.gz, of course
there was no /etc/grub.conf, there was '*' for a root password, or any
other one, so all logins were disabled and basically no any other
configuration but a boot sector was already there (hm, maybe a leftover
from earlier tries).  In /root/ I found install.log, which looked
complete and install.log.syslog but that one was only 45 lines long.
I attach that one for an evidence.  With some, not necessarily trivial,
work this particular installation was salvageable but that is all one
could tell here.

The problem is that when anaconda wedges then, while a mouse pointer may
or may not be "alive" while there is no further progress happen, touching
a keyboard in an attempt to switch to any of text screens immediately
freezes everything and only a power switch is left.

The above invariably happenend in all cases of an attempted "full"
installation save one.  Once I was able to toggle between text
screens.  Shell on tty2 was gone, so I was unable to save anythings
or try to check if someting else is still running, but on "syslog"
screen, after all kind of "normal" stuff, the last two lines read:

<3> SQUASHFS error: sb_bread failed reading block 0x4f17
<3> SQUASHFS error: unable to read page; block 13bf618, size 6994

and that is all I got for all my trouble.
Comment 10 Michal Jaegermann 2006-11-14 23:21:32 EST
Created attachment 141221 [details]
whole saved install.log.syslog from an installation crashing in "Performing postinstall..."
Comment 11 Ferry Huberts 2006-11-17 07:07:45 EST
Created attachment 141469 [details]
stacktrace screenshot
Comment 12 Ferry Huberts 2006-11-17 07:11:01 EST
I have the same kind of problems. I tried installing from CD and from NFS to no
avail. I got 2 installations working out of the 40 times I tried all kinds of
combinations of my BIOS settings. Anaconda crashes (almost) consistently on the
squashfs error.

I have brand new hardware: asus p5w mb (newest bios),sapphire 1950xt, 2GB ddr2,
seagate 7200.10 320GB x2.
it does not matter how setup the bios or harddiscs, raid/no raid. it failseverytime.
I was able to install it on an ide disc after a few tries but that smelled like
dumb luck
Comment 13 Ferry Huberts 2006-11-17 08:28:16 EST
I have some more output:

/proc/cpuinfo:
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 15
model name	: Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz
stepping	: 6
cpu MHz		: 2404.241
cache size	: 4096 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monitor
ds_cpl vmx est tm2 cx16 xtpr lahf_lm
bogomips	: 4816.88

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 15
model name	: Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz
stepping	: 6
cpu MHz		: 2404.241
cache size	: 4096 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monitor
ds_cpl vmx est tm2 cx16 xtpr lahf_lm
bogomips	: 4808.31

/proc/interrupts:
           CPU0       CPU1       
  0:     137033          0    IO-APIC-edge  timer
  1:        631          0    IO-APIC-edge  i8042
  6:         44          0    IO-APIC-edge  floppy
  8:          1          0    IO-APIC-edge  rtc
  9:          0          0   IO-APIC-level  acpi
 14:        696          0    IO-APIC-edge  ide0
 58:         65          0   IO-APIC-level  ehci_hcd:usb1, uhci_hcd:usb2
 66:          0          0   IO-APIC-level  uhci_hcd:usb4
 74:          3          0   IO-APIC-level  ohci1394
 82:          1          0         PCI-MSI  sky2
 90:          1          0         PCI-MSI  sky2
 98:         27          0   IO-APIC-level  libata
177:          0          0   IO-APIC-level  uhci_hcd:usb5
185:         30          0   IO-APIC-level  uhci_hcd:usb3, libata
NMI:          0          0 
LOC:     114146     114146 
ERR:          0
MIS:          0

lspci -v:
00:00.0 Host bridge: Intel Corporation 82975X Memory Controller Hub (rev c0)
	Subsystem: ASUSTeK Computer Inc. Unknown device 8178
	Flags: bus master, fast devsel, latency 0
	Capabilities: [e0] Vendor Specific Information

00:01.0 PCI bridge: Intel Corporation 82975X PCI Express Root Port (rev c0)
(prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=06, subordinate=06, sec-latency=0
	I/O behind bridge: 0000c000-0000cfff
	Memory behind bridge: ff900000-ff9fffff
	Prefetchable memory behind bridge: 00000000cff00000-00000000efe00000
	Capabilities: [88] #0d [0000]
	Capabilities: [80] Power Management version 2
	Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
	Capabilities: [a0] Express Root Port (Slot+) IRQ 0

00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition
Audio Controller (rev 01)
	Subsystem: ASUSTeK Computer Inc. Unknown device 81d8
	Flags: bus master, fast devsel, latency 0, IRQ 5
	Memory at ffafc000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [50] Power Management version 2
	Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
	Capabilities: [70] Express Unknown type IRQ 0

00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1
(rev 01) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=05, subordinate=05, sec-latency=0
	Prefetchable memory behind bridge: 00000000cfe00000-00000000cfe00000
	Capabilities: [40] Express Root Port (Slot+) IRQ 0
	Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
	Capabilities: [90] #0d [0000]
	Capabilities: [a0] Power Management version 2

00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4
(rev 01) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
	I/O behind bridge: 0000b000-0000bfff
	Memory behind bridge: ff800000-ff8fffff
	Capabilities: [40] Express Root Port (Slot-) IRQ 0
	Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
	Capabilities: [90] #0d [0000]
	Capabilities: [a0] Power Management version 2

00:1c.4 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express
Port 5 (rev 01) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
	I/O behind bridge: 0000a000-0000afff
	Memory behind bridge: ff700000-ff7fffff
	Capabilities: [40] Express Root Port (Slot-) IRQ 0
	Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
	Capabilities: [90] #0d [0000]
	Capabilities: [a0] Power Management version 2

00:1c.5 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express
Port 6 (rev 01) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	I/O behind bridge: 00009000-00009fff
	Memory behind bridge: ff600000-ff6fffff
	Capabilities: [40] Express Root Port (Slot-) IRQ 0
	Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
	Capabilities: [90] #0d [0000]
	Capabilities: [a0] Power Management version 2

00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev
01) (prog-if 00 [UHCI])
	Subsystem: ASUSTeK Computer Inc. Unknown device 8179
	Flags: bus master, medium devsel, latency 0, IRQ 58
	I/O ports at e480 [size=32]

00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev
01) (prog-if 00 [UHCI])
	Subsystem: ASUSTeK Computer Inc. Unknown device 8179
	Flags: bus master, medium devsel, latency 0, IRQ 185
	I/O ports at e800 [size=32]

00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev
01) (prog-if 00 [UHCI])
	Subsystem: ASUSTeK Computer Inc. Unknown device 8179
	Flags: bus master, medium devsel, latency 0, IRQ 66
	I/O ports at e880 [size=32]

00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev
01) (prog-if 00 [UHCI])
	Subsystem: ASUSTeK Computer Inc. Unknown device 8179
	Flags: bus master, medium devsel, latency 0, IRQ 177
	I/O ports at ec00 [size=32]

00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI
Controller (rev 01) (prog-if 20 [EHCI])
	Subsystem: ASUSTeK Computer Inc. Unknown device 8179
	Flags: bus master, medium devsel, latency 0, IRQ 58
	Memory at ffafbc00 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 2
	Capabilities: [58] Debug port

00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) (prog-if 01
[Subtractive decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
	Memory behind bridge: ff500000-ff5fffff
	Capabilities: [50] #0d [0000]

00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface
Bridge (rev 01)
	Subsystem: ASUSTeK Computer Inc. Unknown device 8179
	Flags: bus master, medium devsel, latency 0
	Capabilities: [e0] Vendor Specific Information

00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller
(rev 01) (prog-if 8a [Master SecP PriP])
	Subsystem: ASUSTeK Computer Inc. Unknown device 8179
	Flags: bus master, medium devsel, latency 0, IRQ 50
	I/O ports at <unassigned>
	I/O ports at <unassigned>
	I/O ports at <unassigned>
	I/O ports at <unassigned>
	I/O ports at ffa0 [size=16]

00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) Serial ATA
Storage Controller IDE (rev 01) (prog-if 8f [Master SecP SecO PriP PriO])
	Subsystem: ASUSTeK Computer Inc. Unknown device 2601
	Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 98
	I/O ports at e400 [size=8]
	I/O ports at e080 [size=4]
	I/O ports at e000 [size=8]
	I/O ports at dc00 [size=4]
	I/O ports at d880 [size=16]
	Memory at ffafb800 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [70] Power Management version 2

00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01)
	Subsystem: ASUSTeK Computer Inc. Unknown device 8179
	Flags: medium devsel
	I/O ports at 0400 [size=32]

01:03.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000
Controller (PHY/Link) (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. Unknown device 815b
	Flags: bus master, medium devsel, latency 64, IRQ 74
	Memory at ff5ff800 (32-bit, non-prefetchable) [size=2K]
	Memory at ff5f8000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: [44] Power Management version 2

02:00.0 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI
Controller (rev 02) (prog-if 01 [PriO])
	Subsystem: ASUSTeK Computer Inc. Unknown device 81e4
	Flags: bus master, fast devsel, latency 0, IRQ 185
	Memory at ff6fe000 (32-bit, non-prefetchable) [size=8K]
	Expansion ROM at ff6e0000 [disabled] [size=64K]
	Capabilities: [68] Power Management version 2
	Capabilities: [50] Express Legacy Endpoint IRQ 1

02:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI
Controller (rev 02) (prog-if 85 [Master SecO PriO])
	Subsystem: ASUSTeK Computer Inc. Unknown device 81e4
	Flags: bus master, fast devsel, latency 0, IRQ 169
	I/O ports at 9c00 [size=8]
	I/O ports at 9880 [size=4]
	I/O ports at 9800 [size=8]
	I/O ports at 9480 [size=4]
	I/O ports at 9400 [size=16]
	Capabilities: [68] Power Management version 2

03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit
Ethernet Controller (rev 20)
	Subsystem: ASUSTeK Computer Inc. Marvell 88E8053 Gigabit Ethernet controller
PCIe (Asus)
	Flags: bus master, fast devsel, latency 0, IRQ 90
	Memory at ff7fc000 (64-bit, non-prefetchable) [size=16K]
	I/O ports at a800 [size=256]
	Expansion ROM at ff7c0000 [disabled] [size=128K]
	Capabilities: [48] Power Management version 2
	Capabilities: [50] Vital Product Data
	Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable+
	Capabilities: [e0] Express Legacy Endpoint IRQ 0

04:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit
Ethernet Controller (rev 20)
	Subsystem: ASUSTeK Computer Inc. Marvell 88E8053 Gigabit Ethernet controller
PCIe (Asus)
	Flags: bus master, fast devsel, latency 0, IRQ 82
	Memory at ff8fc000 (64-bit, non-prefetchable) [size=16K]
	I/O ports at b800 [size=256]
	Expansion ROM at ff8c0000 [disabled] [size=128K]
	Capabilities: [48] Power Management version 2
	Capabilities: [50] Vital Product Data
	Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable+
	Capabilities: [e0] Express Legacy Endpoint IRQ 0

06:00.0 VGA compatible controller: ATI Technologies Inc R580 [Radeon X1900]
(prog-if 00 [VGA])
	Subsystem: ATI Technologies Inc Unknown device 0b12
	Flags: bus master, fast devsel, latency 0, IRQ 11
	Memory at d0000000 (64-bit, prefetchable) [size=256M]
	Memory at ff9f0000 (64-bit, non-prefetchable) [size=64K]
	I/O ports at c800 [size=256]
	Expansion ROM at ff9c0000 [disabled] [size=128K]
	Capabilities: [50] Power Management version 2
	Capabilities: [58] Express Endpoint IRQ 0
	Capabilities: [80] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-

06:00.1 Display controller: ATI Technologies Inc Unknown device 7264
	Subsystem: ATI Technologies Inc Unknown device 0b13
	Flags: bus master, fast devsel, latency 0
	Memory at ff9e0000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: [50] Power Management version 2
	Capabilities: [58] Express Endpoint IRQ 0


/proc/meminfo:
MemTotal:      2074860 kB
MemFree:       1918680 kB
Buffers:          7808 kB
Cached:         108488 kB
SwapCached:          0 kB
Active:          34452 kB
Inactive:        94576 kB
HighTotal:     1179136 kB
HighFree:      1047408 kB
LowTotal:       895724 kB
LowFree:        871272 kB
SwapTotal:           0 kB
SwapFree:            0 kB
Dirty:               0 kB
Writeback:           0 kB
AnonPages:       12712 kB
Mapped:           6544 kB
Slab:             8960 kB
PageTables:        208 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:   1037428 kB
Committed_AS:    19532 kB
VmallocTotal:   114680 kB
VmallocUsed:     10076 kB
VmallocChunk:   103616 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     4096 kB
Comment 14 Ferry Huberts 2006-11-17 21:42:40 EST
after trying to install fc6 about 30 more times i've gone nuts...
fc6 is a very bad release

just tried ubuntu 6.10 and it installs without a hitch!!!
i'm switching! which is not something i would like, i'm used to fc and like it
but these install problemsare the worst i've ever seen.

hope the fc team brings out a stable realease soon that fixes all the problemsso
many people are having!!!
Comment 15 Michal Jaegermann 2006-11-18 02:01:43 EST
> fc6 is a very bad release

???  FC6 has a bug in an installer.  I think that actually this is
a very nice release despite of this bug (which, indeed, makes a truly bad
first impression).  OTOH in the comment #9 of this report I explicitely
gave a quick and reliable method of installation.  Read a paragraph
which starts with "There is a way ....".  Yum 'groupinstall' command
is pretty helpful when you are adding packages to an initial system.

As a matter of fact you are installing Ubuntu in a way pretty similar
in principle to what I described in the paragraph in question.
Comment 16 Ferry Huberts 2006-11-18 07:32:53 EST
I tried that a few times, didn't work for me.
I did it another way: by some miracle I got fc6 installed on an old ide drive. I
then transferred the installation onto my sata drive by hand: this was
relatively simple:
- boot the installation cd in rescue mode and let it mount your installation
- generate desired layout for new install and mount on temporary dirs
- umount dev, proc, sys, ... on your mounted installation (look in/proc/mounts)
- tar everything in the mounted installation while preserving permissions (tar
cpsf tarfile *)
- untar on your new installation
- adjust /etc/fstab
- adjust /boot/grub/grub.conf
- chroot to your new installation
- create a devs.grub file with '(hd0) /dev/sda'(example)
- run grub with the devs.grub file (--device-map=devs.grub) and install: 'root
(hd0,1)' (my boot partition is /dev/sda2), and 'setup(hd0)'
- run mkinitrdin /boot to adjust the stuff in the initrd

that's it
Comment 17 Ferry Huberts 2006-11-18 07:36:04 EST
o yeah

if you add a .autorelabel file to your new / then selinux permissions will be
updated on the first boot off your transferred installation
Comment 18 Michal Jaegermann 2006-11-25 14:12:11 EST
Yesterday I was running an upgrade of an FC5 to FC6 and I managed
to collect some information which possibly sheds some extra light
on underlying troubles.  The difference is that I was doing that
in a _text_ mode from a local disk where I had _one_ image of
an installation DVD.  I also used 'selinux=0'.

This proceeded as usual.  Anaconda was installing a package after
a package and from time to time it went into a "funk mode" where nothing
was happening for a long time.  These spots are readily recognizable as
"crash points" from my previous experiences and they happened after
installing each of the following packages:

   xorg-x11-drivers - 7.1-3.i386
   firstboot - 1.4.23-1.noarch
   system-config-kickstart - 2.6.13-1.noarch
   system-config-boot - 0.2.12-1.i386
   hwbrowser - 0.27-2.noarch

with 'hwbrowser' beeing the terminating one installed.  One crucial
change.  While in a graphics mode once anacoda gets stuck it will
stay there apparently forever (I left it waiting for many hours
on some occasions) and an attempt to ctrl-alt-F2 to go to a shell
prompt, to try to see what is going on, means an instant lockup and
a power switch as the only recourse.  In a text mode, though,
ctrl-alt-F2 did work and checks, with 'ps' or 'top', were showing
that anaconda was still alive.  It was the most busy process, as
reported by 'top', but usually reported either in "D" or in "S" state;
still from time to time also as "R" and CPU and memory usages were
fluctuating even if regularly in lower "teen" percentages.

When the above was happening then, after a long pause of an
order of five minutes or maybe even longer, one could suddenly see
on a screen "Preparing transaction from an installation sources"
progress bar (not after 'hwbrowser' got installed although a long
pause was still there), which was going reasonably quickly from
0 to 100%, and anaconda was picking up and continuing in a brisk
pace until the next stop.

Checking 'upgrade.log' one can find after each of packages listed
above:

/usr/bin/update-gdk-pixbuf-loaders: line 27:
/etc/gtk-2.0/i386-redhat-linux-gnu/gdk-pixbuf.loaders: No such file or directory
error: %postun(librsvg2-2.14.4-1.fc5.1.i386) scriptlet failed, exit status 1

and also additionally, at the very end:

libsemanage.semanage_direct_remove: Module dpkg was not found.
semodule:  Failed on dpkg!
error: %trigger(selinux-policy-strict-2.3.7-2.fc5.noarch) scriptlet failed, exit
status 1
libsemanage.semanage_direct_remove: Module dpkg was not found.
semodule:  Failed on dpkg!
error: %trigger(selinux-policy-strict-2.3.18-10.noarch) scriptlet failed, exit
status 1

It appears also that each of those pauses is correlated with
"switching from iso n to n+1" in anaconda.log.  That I am not so
sure but it would be consistent with appearances of "Preparing ..."
progress bar.  So it looks like that in this case anaconda is able
to finish some recovery procedures, "switch" to the next image even
if there is really nothing to switch to, and complete the whole
process.

OTOH a fresh instalation should not run into
"error: %postun(librsvg2-2.14.4-1.fc5.1.i386)" scriptlet troubles
and it clearly gives a hard time to many people as well.  So far
I did not try to do a full instalation an text mode.  It may even
finish.

Regardless, apparently there is a silent assumption that there
will be no package installation errors or recovery, even if completed,
would not take so much time.  Obviously this is something which
cannot be relied upon.
Comment 19 Michal Jaegermann 2006-11-25 14:23:46 EST
Oh, I was not precise enough in comment #18.  After an installation
of packages was completed with 'hwbrowser' I did not see "Preparing..."
progress bar anymore.  Instead an installation progress indicator
got stuck on 99% for a really loooong time but eventually I got
"Reboot" button, as expected, and the whole upgrade was truly finished.
Comment 20 Bug Zapper 2008-04-04 00:20:43 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 21 Bug Zapper 2008-05-06 12:39:54 EDT
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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