Description of problem: When installing F13b on a pair of drives, one of which (or just the second?) has no partition table, with multiple md RAID sets, anaconda crashes (python traceback) with a message about /dev/md-1 not existing, just after prompting to re-initialize. Version-Release number of selected component (if applicable): Fedora 13 beta How reproducible: unknown Steps to Reproduce: 1. Install F12 on 1 TB /dev/sda, creating a valid partition table on it in the process. 2. Add a new matching 1 TB drive to the system, and attempt to install F13 beta with the following storage configuration (taken from successful F12 install tried later): #clearpart --none #volgroup vg_fast --pesize=4096 pv.iVw31v-Em4B-pjZi-padv-wndv-q50T-0CbICV #logvol /var/lib/libvirt/images --fstype=ext4 --name=host_images --vgname=vg_fast --size=100000 #logvol /srv/scratch --fstype=ext4 --name=host_scratch --vgname=vg_fast --size=20000 #logvol swap --name=host_swap --vgname=vg_fast --size=4000 #volgroup vg_safe --pesize=4096 pv.MyC3Yn-2cJG-bbyM-fexG-AwDw-hGen-5AadpG #logvol /home --fstype=ext4 --name=host_home --vgname=vg_safe --size=100000 #logvol / --fstype=ext4 --name=host_root --vgname=vg_safe --size=20000 #logvol /var --fstype=ext4 --name=host_var --vgname=vg_safe --size=10000 #raid /boot --fstype=ext4 --level=1 --device=md0 raid.None raid.None #raid pv.MyC3Yn-2cJG-bbyM-fexG-AwDw-hGen-5AadpG --level=1 --device=md1 raid.None raid.None #raid pv.iVw31v-Em4B-pjZi-padv-wndv-q50T-0CbICV --level=0 --device=md2 raid.None raid.None #part raid.None --size=1000 #part raid.None --size=750000 #part raid.None --size=200000 #part raid.None --size=1000 #part raid.None --size=750000 #part raid.None --size=200000 3. Click on "re-initialize drive" when installer complains that /dev/sdb doesn't have a valid partition table. Actual results: Anaconda crashes and spits out a traceback. Expected results: Install completes successfully, as with F12. Additional info: Did not have opportunity to capture traceback, but it complained that /dev/md-1 didn't exist. Another user on #fedora has the same problem and may be uploading a screenshot shortly.
To clarify the storage config, that's a 1 GB RAID 1 /boot, a 2x750 GB RAID 1 root VG, and an additional 2x200 GB RAID 0 VG for swap and mountpoints that don't actually get used during the install. I doubt the precise filesystem layout is critical to reproducing the bug, but unfortunately I had to get the system in question up and running and no longer have the ability to reproduce the problem myself. It may be possible to reproduce in a virtual machine.
If it is possible, please add the /tmp/*log files to this bug
Chris, As Brian already indicated, please reproduce this, and then when anaconda crashes collect all files under /tmp ending with log and also the file with tb in its name. You can use for example scp to copy these files out of the installer environment. Without these log files there is very little we can do to fix this bug. Regards, Hans
Sadly, I've been unable to reproduce the bug, and the other user appears to have been hitting something else.
(In reply to comment #4) > Sadly, I've been unable to reproduce the bug, and the other user appears to > have been hitting something else. Ok, closing this as insufficient info then. If you ever hit an anaconda problem in the future, collect the logs immediately when you hit the problem. Thanks for reporting!