Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 960271
Summary: | crash when changing from raid 1 (default) to raid 0 | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Chris Murphy <bugzilla> | ||||||||||||||||
Component: | anaconda | Assignee: | David Lehman <dlehman> | ||||||||||||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||||||||
Priority: | unspecified | ||||||||||||||||||
Version: | 19 | CC: | anaconda-maint-list, awilliam, g.kaviyarasu, jonathan, mkolman, robatino, rtguille, sbueno, vanmeeuwen+fedora | ||||||||||||||||
Target Milestone: | --- | ||||||||||||||||||
Target Release: | --- | ||||||||||||||||||
Hardware: | Unspecified | ||||||||||||||||||
OS: | Unspecified | ||||||||||||||||||
Whiteboard: | AcceptedBlocker | ||||||||||||||||||
Fixed In Version: | python-blivet-0.13-1 | Doc Type: | Bug Fix | ||||||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||||||
Clone Of: | Environment: | ||||||||||||||||||
Last Closed: | 2013-05-13 18:14:44 UTC | Type: | Bug | ||||||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||||||
Documentation: | --- | CRM: | |||||||||||||||||
Verified Versions: | Category: | --- | |||||||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||
Embargoed: | |||||||||||||||||||
Bug Depends On: | |||||||||||||||||||
Bug Blocks: | 834087 | ||||||||||||||||||
Attachments: |
|
Description
Chris Murphy
2013-05-06 20:29:04 UTC
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. |