Created attachment 744316 [details]
anaconda.log

Created attachment 744317 [details]
program.log

Created attachment 744318 [details]
storage.log

Created attachment 744319 [details]
storage.state

Created attachment 744320 [details]
anaconda-tb

Proposing as beta blocker: "When using the custom partitioning flow, the installer must be able to Reject or disallow invalid disk and volume configurations without crashing."

Discussed at 2013-05-08 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-08/f19beta-blocker-review-4.2013-05-08-16.00.log.txt . Accepted as a blocker per criterion cited in comment #6 - https://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria#Custom_partitioning .

The problem appears to be that it is setting bitmap on a raid0:

May  6 16:11:29 localhost program: Running... mdadm --create /dev/md/nameroot --run --level=0 --raid-devices=4 --metadata=1.0 --bitmap=internal /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
May  6 16:11:29 localhost program: mdadm: bitmaps not meaningful with level raid0

But I can't reproduce this with 3 disks and a TC3 DVD. blivet also has code to make sure bitmaps aren't used with level 0. When I create a / (with no /boot) I see it set it up with metadata 1.0 and no bitmaps.

What install media are you using? TC3?

Reproducer:

1. custom part with / (no /boot) as raid1, return to hub.
2. return to custom and change raid1 to raid0
3. install

It doesn't reset the bitmap flag when the level is changed.

That's a lot different to cmurf's description; if the actual bug is more as bcl suggested, we might want to re-vote on blocker status. I'll try and take a look at it later and see if I'm able to reproduce without changing the RAID level or entering custom part multiple times.

Bug description is based on Fedora-Live-Desktop-x86_64-19-Beta-TC3.iso

In Step 3, starting at RAID 1 is assumed because it's the default.

As for comment 9, step 2, I still haven't even been able to figure out in the UI how to return to custom from hub, so I definitely know I didn't do that. I just tried to reproduce, instead of a crash, I get an AVC denial instead.

Created attachment 745501 [details]
journalctl | grep avc

Created attachment 745502 [details]
ausearch -m avc

But does the denial actually stop it working? IIRC, lives and install run in Permissive mode.

*** Bug 961165 has been marked as a duplicate of this bug. ***

See the above bug duplicate. The crash is consistently reproducible if I change to device type RAID, click Apply, then change the level to 0, then Apply again, then Done, then Begin installation. So I inadvertently omitted that I had clicked Apply more than once.

The original crash wasn't captured by libreport because I was on a plane and the upload had some sort of corruption error; so duplicate bug 961165 has the captured reports.

Changing the description of the bug, as it has nothing to do with the name of the md device. It's the bitmap issue, as a consequence of changing to device type RAID and clicking apply, which sets default of raid1 (with bitmap), and then I decide to change to raid 0 and click apply again. Is reproducible without touching either the Name or Label fields.

python-blivet-0.13-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/python-blivet-0.13-1.fc19

Description of problem:
I was testing to verify that the old bug #799154 was fixed, using a kickstart with the partitioning commands from that bug, in text install mode.

Version-Release number of selected component:
anaconda-19.24-1

Additional info:
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2019-Beta-TC3\x20x86_64 quiet text inst.ks=http://www.happyassassin.net/extras/btrfs_test.ks BOOT_IMAGE=vmlinuz 
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.9.0-301.fc19.x86_64
product:        Fedora
release:        Cannot get release name.
type:           anaconda
version:        19-Beta-TC3

Truncated backtrace:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 141, in run
    threading.Thread.run(self, *args, **kwargs)
  File "/usr/lib64/python2.7/threading.py", line 766, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 117, in doInstall
    turnOnFilesystems(storage, mountOnly=flags.flags.dirInstall)
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 162, in turnOnFilesystems
    storage.doIt()
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 303, in doIt
    self.devicetree.processActions()
  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 237, in processActions
    action.execute()
  File "/usr/lib/python2.7/site-packages/blivet/deviceaction.py", line 272, in execute
    self.device.create()
  File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 789, in create
    raise DeviceCreateError(str(e), self.name)
DeviceCreateError: ('1', 'f17')

Well hey, I guess we have ourselves another reproducer :)

The kickstart I used in this test is http://www.happyassassin.net/extras/btrfs_test.ks .

anaconda-19.25-1.fc19, python-blivet-0.13-1.fc19, pykickstart-1.99.30-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/python-blivet-0.13-1.fc19,pykickstart-1.99.30-1.fc19,anaconda-19.25-1.fc19

Package anaconda-19.25-1.fc19, python-blivet-0.13-1.fc19, pykickstart-1.99.30-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-19.25-1.fc19 python-blivet-0.13-1.fc19 pykickstart-1.99.30-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-7834/python-blivet-0.13-1.fc19,pykickstart-1.99.30-1.fc19,anaconda-19.25-1.fc19
then log in and leave karma (feedback).

Description of problem:
I installed with mount points with unicode characters (a bad idea) to check how anaconda handlet it.
With standard partitions, it just does it.

Here obviously anaconda hit a barrier with lvm.


Version-Release number of selected component:
anaconda-19.25-1

Additional info:
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2019-Beta-TC4\x20x86_64 quiet BOOT_IMAGE=vmlinuz 
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.9.0-301.fc19.x86_64
product:        Fedora
release:        Cannot get release name.
type:           anaconda
version:        19-Beta-TC4

Truncated backtrace:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 168, in run
    threading.Thread.run(self, *args, **kwargs)
  File "/usr/lib64/python2.7/threading.py", line 766, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 126, in doInstall
    turnOnFilesystems(storage, mountOnly=flags.flags.dirInstall)
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 162, in turnOnFilesystems
    storage.doIt()
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 303, in doIt
    self.devicetree.processActions()
  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 237, in processActions
    action.execute()
  File "/usr/lib/python2.7/site-packages/blivet/deviceaction.py", line 272, in execute
    self.device.create()
  File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 789, in create
    raise DeviceCreateError(str(e), self.name)
DeviceCreateError: ('lvcreate failed for fedora_fnext-tst2/: running lvm lvcreate -L 12m -n  --config  devices { filter=["r|/loop3$|","r|/loop4$|","r|/loop5$|","r|/loop6$|","r|/loop7$|"] }  fedora_fnext-tst2 failed', 'fedora_fnext-tst2-')

Reartes: we think your bug was reported as a dupe of this bug incorrectly, it doesn't look much like this bug at all. Can you manually report it as a new bug and attach all the appropriate logs? Sorry for the inconvenience :(

I think any kind of error in /usr/lib/python2.7/site-packages/blivet/devices.py line 789 is showing up as a dupe of this bug (probably via 961165), even when the failures are actually different. My btrfs case is still broken with TC4.

https://bugzilla.redhat.com/show_bug.cgi?id=962006 for my btrfs issue.

Definitively it looks different.
Yeah, ABRT sometimes does that. :-)

I opened bug 962010 for the mount points with Unicode and LVM.

Chris, can you confirm whether or not your original bug here is resolved with TC4? Thanks!

This bug is resolved with beta TC4.

OK, let's close this. Reartes and I have filed our 'reproducers' separately.

If anyone else hits a bug that comes up as a dupe of this in future, please file it as a new bug manually and attach all the relevant log files; it's likely not really a dupe of this. We apologize for the inconvenience.