Created attachment 522529 [details] screenshot of F16 beta TC2 gpf Description of problem: GPF during initial device scan with F16 Beta TC2 Version-Release number of selected component (if applicable): anaconda 16.17 How reproducible: every time Steps to Reproduce: 1. boot F16 Beta TC2 DVD 2. select defaults and basic devices 3. Actual results: during initial device scan, GPF failure occurs. Screenshot attached. Expected results: Continue with installation Additional info: I recognize that this is probably not anaconda, and is probably mdadm, but I don't know how the two interact and since I did not see this error on any of the alpha dvds or live cds, then this is some kind of regression. I also saw this with the test boot.iso created earlier this week, but couldn't follow up due to flooding. I did try to start a netconsole to capture more info but was not successful. If there is a way to start a netconsole before beginning the initial device scan, could someone, please, tell me how. I followed the instructions in the Fedora docs, but I wonder if they apply to the anaconda world.
From F15 running on same machine: $ sudo mdadm --detail /dev/md127 /dev/md127: Version : 0.90 Creation Time : Tue Aug 25 23:23:50 2009 Raid Level : raid10 Array Size : 81919872 (78.12 GiB 83.89 GB) Used Dev Size : 40959936 (39.06 GiB 41.94 GB) Raid Devices : 4 Total Devices : 4 Preferred Minor : 127 Persistence : Superblock is persistent Update Time : Sat Sep 10 10:52:42 2011 State : active Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0 Layout : near=2 Chunk Size : 64K UUID : b9438b55:1d815c8b:bfe78010:bc810f04 Events : 0.332344 Number Major Minor RaidDevice State 0 8 1 0 active sync /dev/sda1 1 8 17 1 active sync /dev/sdb1 2 8 33 2 active sync /dev/sdc1 3 8 49 3 active sync /dev/sdd1 $ sudo blkid /dev/sd* | grep raid /dev/sda1: UUID="b9438b55-1d81-5c8b-bfe7-8010bc810f04" TYPE="linux_raid_member" /dev/sdb1: UUID="b9438b55-1d81-5c8b-bfe7-8010bc810f04" TYPE="linux_raid_member" /dev/sdc1: UUID="b9438b55-1d81-5c8b-bfe7-8010bc810f04" TYPE="linux_raid_member" /dev/sdd1: UUID="b9438b55-1d81-5c8b-bfe7-8010bc810f04" TYPE="linux_raid_member"
Proposing as Beta blocker, under criterion "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot " (which we're interpreting as meaning the installer must be able to read existing RAID layouts).
(In reply to comment #0) > > I did try to start a netconsole to capture more info but was not successful. > If there is a way to start a netconsole before beginning the initial device > scan, could someone, please, tell me how. I followed the instructions in the > Fedora docs, but I wonder if they apply to the anaconda world. Nevermind. Got syslog working and am attaching a syslog of similar failure.
Created attachment 522551 [details] syslog of kernel bug syslog of a crash that was not complete in that tty2 was still available. FWIW: retrying and specifying devices and not selecting the raid devices allowed an install to a standard ext4 partition.
this is probably a duplicate of 736521.
I can't install F16betaTC2 with mdadm. The installation's OK but at first reboot, I'm dropped to a "grub rescue" prompt (similar to what happened previously with an alpha but this time with the latest grub2). I tried to boot into Anaconda's rescue mode twice but I got a GPF after hitting "continue" and my computer froze completely. I'm using VirtualBox on OS X. I re-installed and hit the "grub rescue" prompt again. I've unfortunately deleted the two vistual disks but if I have the time later today, I'll do a re-install and both look at the array before Anaconda shuts down and try to bring up it through another install.
*** This bug has been marked as a duplicate of bug 736521 ***