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".
So it's completely unresponsive (ie, switch vts doesn't work)? Are the keyboard leds flashing?
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.
No vt switch means it's fully hung in the kernel
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.
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.
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.
Created attachment 140614 [details] the second process snapshot
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?
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.
Created attachment 141221 [details] whole saved install.log.syslog from an installation crashing in "Performing postinstall..."
Created attachment 141469 [details] stacktrace screenshot
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
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
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!!!
> 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.
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
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
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.
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.
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
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.