Red Hat Bugzilla – Full Text Bug Listing
|Summary:||F-13-RC2 install failure - AttributeError: 'Ext4FS' object has no attribute 'mapName'|
|Product:||[Fedora] Fedora||Reporter:||birger <birger>|
|Component:||anaconda||Assignee:||Anaconda Maintenance Team <anaconda-maint-list>|
|Status:||CLOSED DUPLICATE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||13||CC:||anaconda-maint-list, jlaska, jonathan, mishu, rhe, vanmeeuwen+fedora|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-05-11 08:29:06 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description birger 2010-05-10 18:41:00 EDT
Description of problem: On my first attempt at installing F13 RC2 anaconda crashed. I tried to use encrypted ext4 root file system. The error messages I got seem to indicate some LUKS problem. On my second attempt I used exactly the same layout but without encryption. The second attempt succeeded. Version-Release number of selected component (if applicable): How reproducible: Only tried once with encryption. Steps to Reproduce: I first removed existing sda1 (windows partition) and sda2 (F12 /boot). I then created /boot on sda1 (ext4), swap on sda2 and / on sda5 (encrypted ext4) sda3 existed as my old F12 install. / and swap LV's inside a LVM volume. Actual results: Anaconda crash Expected results: Additional info: I will attach a traceback
Comment 2 James Laska 2010-05-10 19:25:03 EDT
Listing traceback for future searching ... anaconda 13.41 exception report Traceback (most recent call first): File "/usr/lib/anaconda/storage/devices.py", line 1627, in create self._name = self.slave.format.mapName File "/usr/lib/anaconda/storage/deviceaction.py", line 203, in execute self.device.create(intf=intf) File "/usr/lib/anaconda/storage/devicetree.py", line 704, in processActions action.execute(intf=self.intf) File "/usr/lib/anaconda/storage/__init__.py", line 293, in doIt self.devicetree.processActions() File "/usr/lib/anaconda/packages.py", line 109, in turnOnFilesystems anaconda.storage.doIt() File "/usr/lib/anaconda/dispatch.py", line 205, in moveStep rc = stepFunc(self.anaconda) File "/usr/lib/anaconda/dispatch.py", line 126, in gotoNext self.moveStep() File "/usr/lib/anaconda/gui.py", line 1313, in nextClicked self.anaconda.dispatch.gotoNext() AttributeError: 'Ext4FS' object has no attribute 'mapName'
Comment 3 James Laska 2010-05-10 19:27:24 EDT
I think this might be a duplicate of an F11 *old* bug (see bug#494150)
Comment 4 Jesse Keating 2010-05-10 19:30:03 EDT
I'm able to do an install with a fresh partition set, /boot ext4, swap and / as ext4 encrypted. This works without issue, so it doesn't seem to be a systemic problem. I don't consider this a blocker at this time.
Comment 5 He Rui 2010-05-11 05:39:25 EDT
I did a similar test by removing existing sda1 (vfat), sda2 (/boot), and then creating /boot on sda1 (ext4), swap on sda2 and / on sda5 (encrypted ext4) sda3 existed as my old F12 install. / and swap LV's inside a LVM volume. It works normally without this issue happening. So it seems that general use with / as ext4 encrypted won't hit this issue.
Comment 6 birger 2010-05-11 06:02:34 EDT
I just retried twice on the same hardware. I could not provoke the same problem. Could it be triggered by the existing partition table? Sadly i didnt make a dump of the whole disk before that first attempt. The laptop is now happily installing on encrypted btrfs. Obviously not a blocker.
Comment 7 He Rui 2010-05-11 06:11:19 EDT
(In reply to comment #6) > I just retried twice on the same hardware. I could not provoke the same > problem. Could it be triggered by the existing partition table? Sadly i didnt > make a dump of the whole disk before that first attempt. > > The laptop is now happily installing on encrypted btrfs. > > Obviously not a blocker. Thanks for your retrying, birger. Removing it from blocker list. Thanks.
Comment 8 James Laska 2010-05-11 08:29:06 EDT
(In reply to comment #6) > I just retried twice on the same hardware. I could not provoke the same > problem. Could it be triggered by the existing partition table? Sadly i didnt > make a dump of the whole disk before that first attempt. Definitely, this issue is specific to the layout of your disk prior to install. I'm going to mark this is a DUPLICATE of the older issue. This is still a problem, but seems to be an existing issue we've yet to pinpoint the root cause of. *** This bug has been marked as a duplicate of bug 494150 ***