Bug 590905 - F-13-RC2 install failure - AttributeError: 'Ext4FS' object has no attribute 'mapName'
F-13-RC2 install failure - AttributeError: 'Ext4FS' object has no attribute '...
Status: CLOSED DUPLICATE of bug 494150
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
13
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-10 18:41 EDT by birger
Modified: 2010-05-11 08:29 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-11 08:29:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Anaconda crash trace (402.78 KB, text/plain)
2010-05-10 18:44 EDT, birger
no flags Details

  None (edit)
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 1 birger 2010-05-10 18:44:41 EDT
Created attachment 412993 [details]
Anaconda crash trace
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 ***

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