Bug 590905

Summary: F-13-RC2 install failure - AttributeError: 'Ext4FS' object has no attribute 'mapName'
Product: [Fedora] Fedora Reporter: birger <b1r63r>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 13CC: anaconda-maint-list, jlaska, jonathan, mishu, rhe, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-05-11 12:29:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Anaconda crash trace none

Description birger 2010-05-10 22:41:00 UTC 
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 1 birger 2010-05-10 22:44:41 UTC 
Created attachment 412993 [details]
Anaconda crash trace
Comment 2 James Laska 2010-05-10 23:25:03 UTC 
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 23:27:24 UTC 
I think this might be a duplicate of an F11 *old* bug (see bug#494150)
Comment 4 Jesse Keating 2010-05-10 23:30:03 UTC 
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 09:39:25 UTC 
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 10:02:34 UTC 
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 10:11:19 UTC 
(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 12:29:06 UTC 
(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 ***