Bug 587813 - anaconda crashes when creating md RAID with uninitialized drive on F13 beta
Summary: anaconda crashes when creating md RAID with uninitialized drive on F13 beta
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda   
(Show other bugs)
Version: 13
Hardware: x86_64 Linux
low
high
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-04-30 23:02 UTC by Chris Snook
Modified: 2010-05-04 13:12 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-04 13:12:04 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Chris Snook 2010-04-30 23:02:33 UTC
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.

Comment 1 Chris Snook 2010-04-30 23:10:15 UTC
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.

Comment 2 Brian Lane 2010-04-30 23:36:18 UTC
If it is possible, please add the /tmp/*log files to this bug

Comment 3 Hans de Goede 2010-05-04 11:34:30 UTC
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

Comment 4 Chris Snook 2010-05-04 12:29:44 UTC
Sadly, I've been unable to reproduce the bug, and the other user appears to have been hitting something else.

Comment 5 Hans de Goede 2010-05-04 13:12:04 UTC
(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!


Note You need to log in before you can comment on or make changes to this bug.