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
Created attachment 412993 [details] Anaconda crash trace
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'
I think this might be a duplicate of an F11 *old* bug (see bug#494150)
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.
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.
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.
(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.
(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 ***