Bug 960271 - crash when changing from raid 1 (default) to raid 0
Summary: crash when changing from raid 1 (default) to raid 0
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: David Lehman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
: 961165 (view as bug list)
Depends On:
Blocks: F19Beta, F19BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2013-05-06 20:29 UTC by Chris Murphy
Modified: 2013-05-13 18:14 UTC (History)
9 users (show)

Fixed In Version: python-blivet-0.13-1
Clone Of:
Environment:
Last Closed: 2013-05-13 18:14:44 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
anaconda.log (24.47 KB, text/plain)
2013-05-06 20:31 UTC, Chris Murphy
no flags Details
program.log (32.14 KB, text/plain)
2013-05-06 20:32 UTC, Chris Murphy
no flags Details
storage.log (355.71 KB, text/plain)
2013-05-06 20:32 UTC, Chris Murphy
no flags Details
storage.state (20.00 KB, application/octet-stream)
2013-05-06 20:32 UTC, Chris Murphy
no flags Details
anaconda-tb (573.73 KB, text/plain)
2013-05-06 20:32 UTC, Chris Murphy
no flags Details
journalctl | grep avc (5.80 KB, text/plain)
2013-05-09 02:21 UTC, Chris Murphy
no flags Details
ausearch -m avc (1.45 KB, text/plain)
2013-05-09 02:23 UTC, Chris Murphy
no flags Details

Description Chris Murphy 2013-05-06 20:29:04 UTC
Description of problem:
Installer allows me to set a Name for a device type of RAID, and then proceeds to crash because of this.

Version-Release number of selected component (if applicable):
anaconda 19.24-1

How reproducible:
Always

Steps to Reproduce:
1. Select 4 devices.
2. Go to Manual Partitioning
3. Create a new mount point, /, 500gb, change device type to RAID, raid0, set Name field to nameroot, set Label to labelroot, click Apply.
4. At hub, click Begin installation.
  
Actual results:
Crash shortly after preparing containers.

Expected results:
Disallowo user from setting Name field; instead the field should be Device: and propose a name automatically, or maybe only allow certain mdX values? In any case, not crash.

Additional info:

Comment 1 Chris Murphy 2013-05-06 20:31:47 UTC
Created attachment 744316 [details]
anaconda.log

Comment 2 Chris Murphy 2013-05-06 20:32:01 UTC
Created attachment 744317 [details]
program.log

Comment 3 Chris Murphy 2013-05-06 20:32:21 UTC
Created attachment 744318 [details]
storage.log

Comment 4 Chris Murphy 2013-05-06 20:32:35 UTC
Created attachment 744319 [details]
storage.state

Comment 5 Chris Murphy 2013-05-06 20:32:46 UTC
Created attachment 744320 [details]
anaconda-tb

Comment 6 Chris Murphy 2013-05-06 20:35:38 UTC
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."

Comment 7 Adam Williamson 2013-05-08 17:03:31 UTC
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 .

Comment 8 Brian Lane 2013-05-09 00:22:59 UTC
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?

Comment 9 Brian Lane 2013-05-09 00:46:08 UTC
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.

Comment 10 Adam Williamson 2013-05-09 01:28:43 UTC
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.

Comment 11 Chris Murphy 2013-05-09 02:21:17 UTC
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.

Comment 12 Chris Murphy 2013-05-09 02:21:47 UTC
Created attachment 745501 [details]
journalctl | grep avc

Comment 13 Chris Murphy 2013-05-09 02:23:48 UTC
Created attachment 745502 [details]
ausearch -m avc

Comment 14 Adam Williamson 2013-05-09 02:31:21 UTC
But does the denial actually stop it working? IIRC, lives and install run in Permissive mode.

Comment 15 Chris Murphy 2013-05-09 02:37:56 UTC
*** Bug 961165 has been marked as a duplicate of this bug. ***

Comment 16 Chris Murphy 2013-05-09 02:40:24 UTC
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.

Comment 17 Chris Murphy 2013-05-09 02:50:42 UTC
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.

Comment 18 Fedora Update System 2013-05-09 18:47:14 UTC
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

Comment 19 Adam Williamson 2013-05-10 00:21:44 UTC
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')

Comment 20 Adam Williamson 2013-05-10 00:23:31 UTC
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 .

Comment 21 Fedora Update System 2013-05-10 00:54:44 UTC
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

Comment 22 Fedora Update System 2013-05-10 15:30:40 UTC
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).

Comment 23 Reartes Guillermo 2013-05-10 21:23:14 UTC
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-')

Comment 24 Adam Williamson 2013-05-10 22:12:07 UTC
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 :(

Comment 25 Adam Williamson 2013-05-10 22:40:06 UTC
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.

Comment 26 Adam Williamson 2013-05-10 22:59:52 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=962006 for my btrfs issue.

Comment 27 Reartes Guillermo 2013-05-10 23:22:07 UTC
Definitively it looks different.
Yeah, ABRT sometimes does that. :-)

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

Comment 28 Adam Williamson 2013-05-13 17:23:13 UTC
Chris, can you confirm whether or not your original bug here is resolved with TC4? Thanks!

Comment 29 Chris Murphy 2013-05-13 17:57:05 UTC
This bug is resolved with beta TC4.

Comment 30 Adam Williamson 2013-05-13 18:14:44 UTC
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.


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