Hide Forgot
Description of problem: During a bare-metal install, the DVD installer hangs during package installation. The keyboard is responsive (caps lock, num lock control lights). However, it is not possible to switch to an installer console. In a second run, I switched to the syslog console before the hang. The kernel is periodically dumping call traces referring to kswapd. The DVD passes media check. The target system has ~3.7 GB physical memory and two disks, each with a swap partition. Version-Release number of selected component (if applicable): F15-Beta-Final DVD x86_64 How reproducible: Twice. Steps to Reproduce: 1. In custom layout, specify a preexisting partition to be formatted as ext4 root. The partition is 12 GB. 2. Use preexisting swap without formatting. 3. Specify a default desktop install. Actual results: Hangs during package installation. Expected results: Install completes. Additional info: Screenshot to follow.
Created attachment 493923 [details] screenshot showing kernel call traces on installer syslog console
Created attachment 493936 [details] screenshot: BUG: soft lockup - CPU#0 stuck for 67s! [kswapd0:52]
BUG: soft lockup - CPU#0 stuck for 67s! [kswapd0:52]
Workaround report: 1. disable one swap partition: failed with call traces displayed on syslog console 2. disable all swap partitions: failed but no call traces were displayed 3. disable all swap partitions and do a minimal install: SUCCESS, system boots to root login
Created attachment 493964 [details] dmesg just before package installation; captured from installer console FWIW: "swapon -s" Filename Type Size Used Priority /dev/sda8 partition 1835004 0 -1 /dev/sdb7 partition 3999964 0 -2
(In reply to comment #4) ... > 3. disable all swap partitions and do a minimal install: > SUCCESS, system boots to root login After completing the minimal install, I manually installed enough packages to run the gnome desktop. With one swap partition enabled, the system seems to be running normally. $ uname -a Linux fir 2.6.38.2-9.fc15.x86_64 #1 SMP Wed Mar 30 16:55:57 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux $ free total used free shared buffers cached Mem: 3799600 758540 3041060 0 20800 200948 -/+ buffers/cache: 536792 3262808 Swap: 3999964 0 3999964 $ swapon -s Filename Type Size Used Priority /dev/sdb7 partition 3999964 0 -1
(In reply to comment #4) > Workaround report: > 1. disable one swap partition: > failed with call traces displayed on syslog console > 2. disable all swap partitions: > failed but no call traces were displayed > 3. disable all swap partitions and do a minimal install: > SUCCESS, system boots to root login This also succeeds: leave both swap partitions enabled, do a minimal install (The previous tests were targeting a partition on sdb, but since I have that running, I did this last test to a spare partition on sda, if that matters.)
Two more tests: Both tests targeted sda7 with a full, default graphical install. Both swap partitions were enabled. 1: Running "top" in the installer's shell console to monitor memory usage (default 3 second updates) SUCCESS: The install completed and booted to firstboot. Memory usage peaked around 3.2 GB, IIRC. Swap was never used. 2: Monitoring the installer's syslog console FAIL: The install hung. kswapd messages were displayed. Caps-lock and num-lock did not control the lights. It was not possible to switch to another console. Ctrl-alt-del switched to the installer's 1 console, but was unresponsive after that. Rebooted with the reset button.
Has anyone ever found a better solution to this issue? We can reproduce it on a few dozen Dell Optiplex 755. Keeping top running on tty2 is a valid workaround - don't understand why that help, though.
We can't fix F15 install media, nor F16 at this point. While we can't fix F17 install media, it would be good to know if this still happens with that so we can move this bug to rawhide and work on it for F18 if so.
I think we never saw this issue in F16 or F17. FWIW, back in F15: the "keep top running in tty2" workaround only helped in about 3 out of 4 installations - not exactly sure whether some systems were more often affected than others or if it was just the number of tries per system, though.
(In reply to comment #11) > I think we never saw this issue in F16 or F17. FWIW, back in F15: the "keep > top running in tty2" workaround only helped in about 3 out of 4 > installations - not exactly sure whether some systems were more often > affected than others or if it was just the number of tries per system, > though. OK. Thanks for letting us know. If anyone does see this in F17/rawhide, please reopen or open a new bug.