Created attachment 402834 [details] screen when freezing occurs Description of problem: Installing Fedora 13 Beta RC1 x86_64 from DVD: http://serverbeach1.fedoraproject.org/pub/alt/stage/13-Beta.RC1/ Standard default install next-next-next in KVM, tried both Graphical and Minimal package set. The installation always freezes with dialog "Installing bootloader" (see screenshot). The system is hard frozen, nothing helps. Once I have seen getting black screen instead, mouse cursor worked. After an attempt to switch to VT1 the system froze. I attached serial console to the virtual machine, but nothing is printed out before or during the freeze. Any ideas how to gather more information? Version-Release number of selected component (if applicable): Fedora 13 Beta RC1 x86_64 anaconda 13.37 How reproducible: 3 attempts froze, 1 attempt got black screen and then froze
If I setup utelnetd to access the system and watch the logs before the hang occurs, I see the following information... 13:04:57,084 ERR kernel:end_request: I/O error, dev sr0, sector 181068 13:04:57,086 INFO kernel:sr 1:0:0:0: [sr0] Device not ready 13:04:57,086 INFO kernel:sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE 13:04:57,086 INFO kernel:sr 1:0:0:0: [sr0] Sense Key : Not Ready [current] 13:04:57,086 WARN kernel:Info fld=0x0 13:04:57,086 INFO kernel:sr 1:0:0:0: [sr0] Add. Sense: Medium not present 13:04:57,086 INFO kernel:sr 1:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 b0 d5 00 00 02 00 13:04:57,086 ERR kernel:end_request: I/O error, dev sr0, sector 181076 13:04:57,089 INFO kernel:sr 1:0:0:0: [sr0] Device not ready 13:04:57,089 INFO kernel:sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE 13:04:57,089 INFO kernel:sr 1:0:0:0: [sr0] Sense Key : Not Ready [current] 13:04:57,089 WARN kernel:Info fld=0x0 13:04:57,089 INFO kernel:sr 1:0:0:0: [sr0] Add. Sense: Medium not present 13:04:57,089 INFO kernel:sr 1:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 b0 d5 00 00 02 00 13:04:57,089 ERR kernel:end_request: I/O error, dev sr0, sector 181076 13:04:57,091 INFO kernel:sr 1:0:0:0: [sr0] Device not ready 13:04:57,091 INFO kernel:sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE 13:04:57,091 INFO kernel:sr 1:0:0:0: [sr0] Sense Key : Not Ready [current] 13:04:57,091 WARN kernel:Info fld=0x0 13:04:57,091 INFO kernel:sr 1:0:0:0: [sr0] Add. Sense: Medium not present 13:04:57,091 INFO kernel:sr 1:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 b0 d5 00 00 02 00 13:04:57,091 ERR kernel:end_request: I/O error, dev sr0, sector 181076 13:04:57,094 INFO kernel:sr 1:0:0:0: [sr0] Device not ready 13:04:57,094 INFO kernel:sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE 13:04:57,094 INFO kernel:sr 1:0:0:0: [sr0] Sense Key : Not Ready [current] 13:04:57,094 WARN kernel:Info fld=0x0 13:04:57,094 INFO kernel:sr 1:0:0:0: [sr0] Add. Sense: Medium not present 13:04:57,094 INFO kernel:sr 1:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 b0 d5 00 00 02 00 13:04:57,094 ERR kernel:end_request: I/O error, dev sr0, sector 181076 13:04:57,098 INFO kernel:sr 1:0:0:0: [sr0] Device not ready 13:04:57,098 INFO kernel:sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE 13:04:57,098 INFO kernel:sr 1:0:0:0: [sr0] Sense Key : Not Ready [current] 13:04:57,098 WARN kernel:Info fld=0x0 13:04:57,098 INFO kernel:sr 1:0:0:0: [sr0] Add. Sense: Medium not present 13:04:57,098 INFO kernel:sr 1:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 b0 a5 00 00 02 00 13:04:57,098 ERR kernel:end_request: I/O error, dev sr0, sector 180884 13:04:57,098 ERR kernel:SQUASHFS error: squashfs_read_data failed to read block 0x35a53b8 13:04:57,098 ERR kernel:SQUASHFS error: Unable to read data cache entry [35a53b8] 13:04:57,098 ERR kernel:SQUASHFS error: Unable to read page, block 35a53b8, size a9b3 Could this be a problem introduced by the fix for bug#569377?
When I install from netinst.iso from HTTP or NFS repo, no freezes occur.
Well, the netinst.iso is a completely different image, with much less data, on a completely different piece of physical media. Did you run media check on the original DVD before installation?
(In reply to comment #3) > Well, the netinst.iso is a completely different image, with much less data, on > a completely different piece of physical media. Did you run media check on the > original DVD before installation? Yeah, the DVD passed media check.
Created attachment 402862 [details] anaconda-logs.tgz -rw-rw-r-- jlaska/jlaska 27721 2010-03-26 09:21 tmp/minimon/anaconda.log -rw-rw-r-- jlaska/jlaska 7903 2010-03-26 09:21 tmp/minimon/install.log -rw-rw-r-- jlaska/jlaska 39675 2010-03-26 09:21 tmp/minimon/program.log -rw-rw-r-- jlaska/jlaska 180088 2010-03-26 09:21 tmp/minimon/storage.log -rw-rw-r-- jlaska/jlaska 134937 2010-03-26 09:25 tmp/minimon/syslog -rw-rw-r-- jlaska/jlaska 26577 2010-03-26 09:21 tmp/minimon/X.log -rw-rw-r-- jlaska/jlaska 25341 2010-03-26 09:17 tmp/minimon/yum.log
Created attachment 402867 [details] anaconda-logs.tgz
in storage.log: 11:20:29,077 DEBUG storage: looking for device 'sr0'... 11:20:29,082 DEBUG storage: OpticalDevice.mediaPresent: sr0 ; status: True ; 11:20:29,089 DEBUG storage: Iso9660FS.supported: supported: True ; 11:20:29,089 DEBUG storage: found OpticalDevice instance (0x7ffb548544d0) -- name = sr0 status = True parents = [] kids = 0 id = 2 uuid = None format = <storage.formats.fs.Iso9660FS object at 0x7ffb54854390> size = 3606.58203125 major = 11 minor = 0 exists = True sysfs path = /devices/pci0000:00/0000:00:01.1/host1/target1:0:0/1:0:0:0/block/sr0 partedDevice = <parted.device.Device object at 0x7ffb3e682250> target size = 0 path = /dev/sr0 format args = [] originalFormat = Iso9660FS instance (0x7ffb54854390) -- type = iso9660 name = iso9660 status = True device = /dev/sr0 uuid = None exists = True options = ro supported = True formattable = False resizable = False mountpoint = None mountopts = None label = Fedora_13-Beta_x86_64_DVD size = 0 targetSize = 0 11:20:29,092 DEBUG storage: OpticalDevice.eject: sr0 ; status: True ; 11:20:29,094 DEBUG storage: OpticalDevice.teardown: sr0 ; status: True ; And at the same time (GMT though) in syslog: 15:20:29,282 ERR kernel:ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 15:20:29,282 ERR kernel:ata2.00: BMDMA stat 0x5 15:20:29,282 INFO kernel:sr 1:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 eb 75 00 00 02 00 15:20:29,283 ERR kernel:ata2.00: cmd a0/01:00:00:00:10/00:00:00:00:00/a0 tag 0 dma 4096 in 15:20:29,283 ERR kernel: res 01/60:00:00:00:10/00:00:00:00:00/a0 Emask 0x3 (HSM violation) 15:20:29,283 ERR kernel:ata2.00: status: { ERR } 15:20:29,283 INFO kernel:ata2: soft resetting link 15:20:29,435 DEBUG kernel:ata2.01: NODEV after polling detection 15:20:29,436 INFO kernel:ata2.00: configured for MWDMA2 15:20:29,439 INFO kernel:ata2: EH complete 15:20:29,439 INFO kernel:sr 1:0:0:0: [sr0] Device not ready 15:20:29,440 INFO kernel:sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE 15:20:29,440 INFO kernel:sr 1:0:0:0: [sr0] Sense Key : Not Ready [current]
So, that definitely looks like we wouldn't see it without the eject fix, but it doesn't look like the eject fix is the actual /cause/ of the problem. It merely enables the real bug to show through.
This was reported from a virt install (disks in storage.log are vda, vdb). The original eject bug (bug 569377) did not even manifest in virt. We should find out if this happens on real hardware.
So we've been doing some real hardware tests. Seems sometimes we can reproduce, sometimes not. Here's my result: I tested installing to a 4GB USB stick, to save messing up my real disk at all. So at the disk selection stage, I picked only the USB drive. I then picked 'use entire disk', but also 'review and modify layout'. The layout it chose was a 500MB /boot, with the rest of the disk as an LVM, with a 2GB swap partition and the rest - 1.5GB -as / . I changed this to be just a 400GB /boot partition and the rest of the disk as a / partition: no LVM, no swap partition. I chose the minimal package set, to make sure it'd fit on the stick and to make the install process quicker. This test succeeded: it didn't hit the bug. The install process completed, ejected the DVD, and displayed the 'yay we're done' screen. The installed system on the USB stick boots fine. I can provide anaconda logs from the stick if desired. Jesse's been testing also, if he could add his results on this thread it'd be great. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I've discovered a pattern. If the install either involves installing to LVM or the disks were part of a pre-existing LVM I get the hang at the end. If the disks were not involved in a previous LVM, and if the install is to a non-LVM setup, there is no hang at the end. My conclusion is that the existence of LVM is what's causing this to fall over.
Further data, I've been doing all this testing with bios raid, so it's not device-mapper.
as discussed on IRC, I just tested - again installing to my 4GB USB key - using auto-partitioning. I zero'ed the key before doing the install. Auto-partitioning definitely set up an LVM, I checked that at the console. Again the install completed successfully, no bug. I was using the minimal package set again. I'll try doing an install over the now-LVM'ed stick and see what happens with that. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I did some tests on this issue using F13-beta-rc1-x86_64-DVD.iso. 1. In virt-install, it hanged at installing bootloader and was 100% reproducible no matter it's minimal or graphical, lvm or no lvm... 2. On bare metal, the screen hanged after it ejected the DVD and the screen(tty6) hanged with black screen. As far as I tested, it didn't happen in minimal install. Then I used the same ext4 partitions(/ and /boot) to install it only with package differences: a. Minimal install - pass. b. gnome + office + base + xwindow - pass c. graphical default - fail The failure info on tty3: ... INFO anaconda: leaving (1) step dopostaction INFO anaconda: moving (1) to step complete WARNING anaconda: /usr/lib/anaconda/gui.py:1533: GTKWarning: Error loading theme icon 'gtk-quit' for stock: Error reading from file: Input/output error _ Info on tty5 : ... GNU GRUB version 0.97 (640K lower / 3072K upper memory) [ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename.] grub> root (hd0,4) Filesystem type is ext2fs, partition type 0x83 grub> install --stage2=/boot/grub/stage2 /grub/stage1 d (hd0) /grub/stage2 p (hd0,4)/grub/grub.conf grub> Backtrace:
anaconda-13.37.1-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/anaconda-13.37.1-1.fc13
I tested on anaconda 13.37.1, it has been fixed.
Closing this issue based on feedback from Liam (comment#16) and additional F-13-Beta-RC2 test results
anaconda-13.37.2-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/anaconda-13.37.2-1.fc13
anaconda-13.37.2-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.