Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 590905 - F-13-RC2 install failure - AttributeError: 'Ext4FS' object has no attribute 'mapName'
Summary: F-13-RC2 install failure - AttributeError: 'Ext4FS' object has no attribute '...
Keywords:
Status: CLOSED DUPLICATE of bug 494150
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 13
Hardware: x86_64
OS: Linux
low
high
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-10 22:41 UTC by birger
Modified: 2010-05-11 12:29 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-05-11 12:29:06 UTC


Attachments (Terms of Use)
Anaconda crash trace (deleted)
2010-05-10 22:44 UTC, birger
no flags Details

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 ***


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