Red Hat Bugzilla – Bug 651478
FormatCreateError: ('invalid device specification', '/dev/dasdb1')
Last modified: 2010-11-27 18:36:32 EST
The following was filed automatically by anaconda: anaconda 14.17.2 exception report Traceback (most recent call first): File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/formats/__init__.py", line 266, in create raise FormatCreateError("invalid device specification", self.device) File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/formats/fs.py", line 849, in create DeviceFormat.create(self, *args, **kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/deviceaction.py", line 290, in execute options=self.device.formatArgs) File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 700, in processActions action.execute(intf=self.intf) File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 313, in doIt self.devicetree.processActions() File "/usr/lib64/python2.7/site-packages/pyanaconda/packages.py", line 110, in turnOnFilesystems anaconda.storage.doIt() File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 212, in moveStep rc = stepFunc(self.anaconda) File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 131, in gotoNext self.moveStep() File "/usr/lib64/python2.7/site-packages/pyanaconda/text.py", line 510, in run anaconda.dispatch.gotoNext() File "/usr/bin/anaconda", line 902, in <module> anaconda.intf.run(anaconda) FormatCreateError: ('invalid device specification', '/dev/dasdb1')
Created attachment 459185 [details] Attached traceback automatically from anaconda.
Steps to reproduce: 1. clear all DASD disks before installing (dd if=/dev/zero of=/dev/dasdX bs=1M count=100) 2. start new installation in z/VM, select text mode 3. reinitialize all drives when asked 4. select "Replace existing Linux system" or "Use entire drive", all DASD drives are selected 5. confirm writing changes to disk and wait for traceback installation source: http://secondary.fedoraproject.org/pub/alt/spins/S390/current/ kernel, initrd.img and install.img from 20-Oct-2010
As this is still happening with the latest packages I had a further look. 'udevadm monitor' shows no 'add' events when new DASD partitions are created with parted or anything using libparted and thus no new device-nodes for the partitions get created. But the 'add' udev events show up when you run 'sfdisk -R /dev/dasdX' afterwards. So it looks like the BLKRRPART ioctl doesn't get executed from parted for DASD devices. This is one of only a few remaining blockers for F14 on s390x, so I'll mark it urgent, please have a look
The partition resync was being skipped for DASD after the BLKRRPART code was removed from parted. This build may fix things: http://koji.fedoraproject.org/koji/taskinfo?taskID=2610186 It handles DASD partition changes the same as all the others. If there's still a problem I'd blame the kernel.
Created attachment 461413 [details] resync DASD partitions
looks good, an installation with newly initialized DASDs without any pre-existing partitions finished where it would have failed before. Thanks a lot for that quick fix ! I'll leave this bugzilla open until the fix is committed to git
parted-2.3-4.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/parted-2.3-4.fc14
parted-2.3-4.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update parted'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/parted-2.3-4.fc14
parted-2.3-4.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.