The following was filed automatically by anaconda: anaconda 12.32 exception report Traceback (most recent call first): File "/usr/lib/anaconda/storage/devices.py", line 1441, in create self._name = self.slave.format.mapName File "/usr/lib/anaconda/storage/deviceaction.py", line 204, in execute self.device.create(intf=intf) File "/usr/lib/anaconda/storage/devicetree.py", line 707, in processActions action.execute(intf=self.intf) File "/usr/lib/anaconda/storage/__init__.py", line 265, in doIt self.devicetree.processActions() File "/usr/lib/anaconda/packages.py", line 110, in turnOnFilesystems anaconda.id.storage.doIt() File "/usr/lib/anaconda/dispatch.py", line 200, in moveStep rc = stepFunc(self.anaconda) File "/usr/lib/anaconda/dispatch.py", line 123, in gotoNext self.moveStep() File "/usr/lib/anaconda/gui.py", line 1195, in nextClicked self.anaconda.dispatch.gotoNext() AttributeError: 'LVMPhysicalVolume' object has no attribute 'mapName'
Created attachment 363521 [details] Attached traceback automatically from anaconda.
I'm trying to test bug #497005 (and then bug #526971, which I encountered along the way), so the steps I'm following are: " Installing on one 80 G SATA hard disk... 1. Install from boot.iso dated 20091001. 2. Make disk setup like so: /dev/sda1 = 200MB, ext3, /boot /dev/sda2 = approx 23564 MB, LVM (encrypted) on VG: lv_root = 20480 MB, ext4, / lv_swap = 3072 MB, swap /dev/sda3 = 52552 MB, ext4, /home (encrypted) " But that's as far as I got. More specifically, the way I was creating this disk setup was to: 1. Pick "Replace existing linux install", "Encrypt Disk", and "Let me review/modify partitions" 2. Delete VG on sda2. 3. Edit sda2 down to 23564MB. (Note that "encrypt partition" is still checked, but when this screen closes, there is no lock next to sda2.) 4. Click on sda2 then LVM. 5. When the LVM editor comes up, there are two volumes listed, "sda2" and "luks-sda2" (It may actually be "sda2-luks"). I unchecked "sda2", since the lv's should reside within the luks device. Note that while both are checked, it reports there is twice the storage available than is actually available. 6. Create lv_root, 20480MB, ext4, / 7. Create lv_swap, 3072MB, swap. 8. Okay the above changes, then create /dev/sda3 = 52552 MB, ext4, /home (encrypted). 9. When writing changes, the bug presents.
I was able to get past this bug by deleting the LVM partition on sda2 and recreating it instead of editing it down to the size I wanted. When doing it this way, I also noticed that only one volume was listed when I set up the lv's. I believe it was called 'luks4'.
Created attachment 363581 [details] Attached traceback automatically from anaconda.
I get this error without the need to customize partitions, I can just select encrypt with either replace existing linux system, or use entire hard disc, and after writing changes I get an Authenticate window (without a password prompt since running on the live CD) but before I can authenticate I get two windows reading Unable to mount 210 MB File system Not Authorized followed by this error.
I get a similar error with a custom partitionning : AttributeError: 'DeviceName' object has no attribute 'mapName' (as I didn't use LVM) With a 500 Go hard disk : - a little /boot partition (200MB) (ext2) - a 150Go / partition (ext4, with encrypt option) - the rest for /home (ext4, with encrypt option) And I get the same two windows that Robert gets. If I uncheck the 'Encrypt' box, I didn't get the error.
Created attachment 363656 [details] Attached traceback automatically from anaconda.
Created attachment 363936 [details] Attached traceback automatically from anaconda.
Created attachment 363942 [details] Attached traceback automatically from anaconda.
Steps to reproduce: create: partition1 | |-> Raid1 /dev/md0 -> Volgrp -> LV with / partition2 | boot live cd installer... try to create the layout: partition1 | |-> Raid1 /dev/md0 -> encrypt -> Volgrp -> LV with / partition2 |
Created attachment 363943 [details] md0 setup
Created attachment 363944 [details] overall setup
Created attachment 364288 [details] Attached traceback automatically from anaconda.
still present with 20091008.x86_64.iso
This is probably going to be resolved by the fix for bug 526899, which prevented anaconda's LUKS support module from loading, leading to major problems with device encryption. Please verify with the version of anaconda noted in that bug and either mark as CLOSED->DUPLICATE if fixed or set back to ASSIGNED if not.
Created attachment 364568 [details] Attached traceback automatically from anaconda.
reproduced in anaconda 12.36 steps: On Partitioning: 1. create custom layout. 2. create: /dev/sda12 = 200MB, ext4, /boot /dev/sda13 = 9GB, LVM, encrypted on VG: lv_swap = 1000MB, swap, encrypted lv_root = (about)8000MB, ext3, /, encrypted
The fix is in anaconda-12.37-1, so it is expected that you see the problem 12.36.
Is someone able to verify this issue is fix using the steps to reproduce noted by Harald in comment#10?
(In reply to comment #19) > Is someone able to verify this issue is fix using the steps to reproduce noted > by Harald in comment#10? The attached screenshot in comment#11 and #12 showed it was RAID0 not RAID1, right? I tested anaconda 12.37 of f12_rc2_i386_dvd.iso regarding it. For : partition1 | |-> Raid0 /dev/md0 -> Volgrp -> LV with / partition2 | It worked fine in my pc and this issue didn't happen. For: partition1 | |-> Raid0 /dev/md0 -> encrypt -> Volgrp -> LV with / partition2 | Instead, a new bug happened: https://bugzilla.redhat.com/show_bug.cgi?id=528921 it's not 100% reproducible, about 50%.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Created attachment 372927 [details] Attached traceback automatically from anaconda.
Created attachment 382567 [details] Attached traceback automatically from anaconda.
Created attachment 390643 [details] Attached traceback automatically from anaconda.
Created attachment 402937 [details] Attached traceback automatically from anaconda.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.