Description of problem: anaconda can't install fedora on existing (encrypted) LVM. It recognizes my setup corretly but doesn't allow me to choose the mountpoint for examle. this errormessage pops up when hitting 'edit': see attachment Screenshot.png Version-Release number of selected component (if applicable): How reproducible: Always. Steps to Reproduce: 1. Encrypt a partition with luks and make an LVM on top 2. boot the fedora live CD 3. try to install in that LVM Actual results: errormessage pops up, see screenshot Expected results: option to set mountpoint and continue installation Additional info:
Created attachment 310540 [details] Screenshot of the errormessage
This error message does not appear to be related to encryption. Did you double-click the LV line in the partition list or did you click the "LVM" button? The latter will not work, while the former should.
I clicked on everything that is clickable, nothing worked. Just tried it again. The only thing I can do is to _delete_ an lv.
Have you tried to install Fedora 10 Beta on this system? There is little use in tracking down a problem in the Fedora 9 installer, since it is too late to change it. I have done several installs of F10-Beta (and more recent rawhide/development trees) onto pre-existing encrypted LVM and it seems to work quite well.
Ok, I have just found a similar problem in today's rawhide. I hit it by following a procedure I seldom use. I was able to edit mountpoints and set format flags in my pre-existing LVs on top of an encrypted PV, but once I removed the LVs and VG I started getting the error you saw if I tried to create a VG, even if I delete and then recreate the PV. I will keep you posted.
I just tried with F10beta and it's exactly the same (except that I have to luksOpen and lvchange -a y lvm myself). I hope I'm not doing something horribly wrong? Just to make sure: I have sda1 as /boot (ext2) and sda2 as dm-crypt and on top of that an LVM with several logival volumes (as shown in the screenshot). Then I double-click on 'fedora' and boom, error. In fact, I can click on everything else and I get that error (and I clicked a _lot_) Thanks for your effort, I really appreciate it.
Just ran into this doing a PXE installation of F10beta using anaconda-11.4.1.53-1.
(In reply to comment #7) > Just ran into this doing a PXE installation of F10beta using > anaconda-11.4.1.53-1. This version of anaconda has a bug that is triggered by deleting a pre-existing encrypted PV, which is fixed in anaconda-11.4.1.55-1. If you still experience this problem with the newer anaconda I would like to see the contents of /tmp/anaconda.log and a detailed, step-by-step description of the process you used to hit the bug. I have been unable to reproduce this bug, so the more details you can provide the better the chances I can figure out what is happening.
When I delete all LVM's I can easily create new one's and install Fedora. However, the installer doesn't let me choose a name without a number at the end for the volume group. My previous LVM didn't have a number (I didn't creat them with the installer), so maybe that's why it fails. So I had to do it the other way round: Instead of first installing Arch Linux and then Fedora, I installed Fedora first. If I'm the only one seeing this, I guess the bug can be closed. I'm happy now :)
Sorry for the delay. One thing I forgot to mention is that I'm running from a kickstart file *without* the passphrase included. My assumption was that anaconda would then ask me for it, but it didn't. I now have Rawhide running fine on my main laptop (which was running F9 with encryption), so I'm not to keen on erasing the drive again (which is how I solved the problem the first time).
Yeah I did the same (erasing drive). It probably boils down to using anaconda to create the lvm/dm-crypt stuff instead of creating it manually.
(In reply to comment #10) > Sorry for the delay. One thing I forgot to mention is that I'm running from a > kickstart file *without* the passphrase included. My assumption was that > anaconda would then ask me for it, but it didn't. It sounds like the problem you have experienced is not the same as the problem this bug report describes. The reporter was trying to do an interactive (non-kickstart) install onto pre-existing encrypted devices. If you would like me to look into your problem please open a separate bug and include anaconda.log, your kickstart config, and any relevant screenshots. As a side note, if you specify a passphrase for any encrypted devices it is assumed to also apply to device for which you have not specified a passphrase. Did you have other encrypted devices for which you specified a passphrase?
(In reply to comment #12) > It sounds like the problem you have experienced is not the same as the problem > this bug report describes. The reporter was trying to do an interactive > (non-kickstart) install onto pre-existing encrypted devices. If you would like > me to look into your problem please open a separate bug and include > anaconda.log, your kickstart config, and any relevant screenshots. That's fair enough. Because the error message was exactly the same as the OP's, I thought the problem was the same (which is why I didn't open a new ticket), but it looks like I was wrong. As my problem is fixed, I'll probably leave well enough alone. > As a side note, if you specify a passphrase for any encrypted devices it is > assumed to also apply to device for which you have not specified a passphrase. > Did you have other encrypted devices for which you specified a passphrase? No, but thanks for checking on this.
i had the same issue with an LVM-on-LUKS created by the debian-installer. the reason for the error is that anaconda expects the "lvm" flag on the partition to be set, and debian-installer does not seem to do this in case of LUKS partitions. the workaround is to to this with parted (don't remember exactly): > set PARTNR lvm on after doing this, anaconda recognized the LVM setup.
I am having exactly the same issue with a F-10 LiveCD and F-11 Alpha LiveCD. I have F-10 installed on my laptop using encrypted LVM, here's the disk layout: `- /dev/sda1 /boot (ext3) | `- /dev/sda2 LVM (encrypted) | `- vg_enterprise (volume group) | `- lv_root (15G logical volume - ext3) | `- lv_root_rawhide (15G logical volume - ext3) | `- lv_swap (4G logical volume - swap) | `- lv_home (100G logical volume - ext3) '/usr/bin/liveinst' from F-11 livecd does NOT ask me for the passphrase (and I have to manually activate the vg by running 'cryptsetup luksOpen /dev/sda2 vg_enterprise' and then 'lvchange -a y vg_enterprise'. After that I get the LV list but I can't edit any of them (tried to click every button on that page, tried to double-click every line too, same results as Jan Willies' screenshot). Strange thing: running 'anaconda' instead of liveinst actually shows the dialog asking for the password while 'liveinst' does not. /tmp/anaconda.log says: 13:42:52 DEBUG : ignoring PV sda2 since we cannot access it's contents anaconda seems to append one line like this everytime I click to edit the partition. This bug seems to come from F-9 but since both F-10 and F-11 Alpha have this problem I assume that this bug is not fixed yet. Plus that I think this bug has to be promoted to 'normal' or 'high' priority since this is a blocker to do proper upgrades (other than using preupgrade).
I can verify that. Exactly the same behaviour here
Similar setup here. On F11-Beta (anaconda-11.5.0.38-1) I get these dialogs: Finding Devices followed by: Warning Error processing drive sda. Maybe it needs to be reinitialized. YOU WILL LOSE ALL DATA ON THIS DRIVE! [Ignore Drive] [Re-initialize drive]
I think I've discovered the cause of my troubles, which may or may not be the same as the OP's. The system currently has F9 on it. Before trying to install F11-Beta (and F10 before that which fails similarly) I rearranged a bunch of Logical Partitions using fdisk, pvmove, etc. to make space. Several times during this procedure, I used fdisk to fix the order of the partitions (option 'x' followed by 'f'). This causes parted to barf on the partition table: # parted -l ... Error: Unable to satisfy all constraints on the partition. My symptoms match the behavior described here: http://www.mail-archive.com/bug-parted@gnu.org/msg02703.html Looking at the extended partition tables using sfdisk shows some pretty messed up entries--like the type 5 (extended) entries in slot 2 of the extended partition tables not pointing to the next extended partition table on the disk as they usually do.
(In reply to comment #17) > Similar setup here. On F11-Beta (anaconda-11.5.0.38-1) I get these dialogs: > > Finding Devices > > followed by: > > Warning > > Error processing drive sda. > Maybe it needs to be reinitialized. YOU WILL LOSE ALL DATA ON THIS DRIVE! > > [Ignore Drive] [Re-initialize drive] This is a completely unrelated problem. Please file a separate bug, against either fdisk or parted.
With the latest version of anaconda included in fedora 11 I can't reproduce this problem anymore. This is probably because of the storage backend rewrite.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. 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 '9'. 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 9'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 9 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 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 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.