Red Hat Bugzilla – Bug 737278
GPF during initial device scan
Last modified: 2011-09-12 11:36:07 EDT
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):
Steps to Reproduce:
1. boot F16 Beta TC2 DVD
2. select defaults and basic devices
during initial device scan, GPF failure occurs. Screenshot attached.
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
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 ***