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 453322 - anaconda can't install fedora on existing (encrypted) LVM
Summary: anaconda can't install fedora on existing (encrypted) LVM
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 9
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: David Lehman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-29 17:27 UTC by Jan Willies
Modified: 2009-07-14 17:54 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-07-14 17:54:17 UTC


Attachments (Terms of Use)
Screenshot of the errormessage (deleted)
2008-06-29 17:27 UTC, Jan Willies
no flags Details

Description Jan Willies 2008-06-29 17:27:48 UTC
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:

Comment 1 Jan Willies 2008-06-29 17:27:48 UTC
Created attachment 310540 [details]
Screenshot of the errormessage

Comment 2 David Lehman 2008-09-30 19:24:05 UTC
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.

Comment 3 Jan Willies 2008-10-30 17:20:31 UTC
I clicked on everything that is clickable, nothing worked. Just tried it again. The only thing I can do is to _delete_ an lv.

Comment 4 David Lehman 2008-10-30 17:37:59 UTC
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.

Comment 5 David Lehman 2008-10-30 17:49:12 UTC
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.

Comment 6 Jan Willies 2008-10-30 18:33:31 UTC
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.

Comment 7 Jonathan Dieter 2008-11-04 12:11:12 UTC
Just ran into this doing a PXE installation of F10beta using anaconda-11.4.1.53-1.

Comment 8 David Lehman 2008-11-04 16:01:26 UTC
(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.

Comment 9 Jan Willies 2008-11-04 16:11:36 UTC
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 :)

Comment 10 Jonathan Dieter 2008-11-13 12:29:25 UTC
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).

Comment 11 Jan Willies 2008-11-13 12:39:40 UTC
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.

Comment 12 David Lehman 2008-11-13 15:49:57 UTC
(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?

Comment 13 Jonathan Dieter 2008-11-13 16:01:40 UTC
(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.

Comment 14 Michael Stahl 2009-01-18 19:04:26 UTC
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.

Comment 15 Lorenzo Villani 2009-03-01 13:49:10 UTC
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).

Comment 16 Jan Willies 2009-03-01 13:53:54 UTC
I can verify that. Exactly the same behaviour here

Comment 17 Charles R. Anderson 2009-04-05 04:13:35 UTC
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]

Comment 18 Charles R. Anderson 2009-04-05 15:55:09 UTC
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.

Comment 19 David Lehman 2009-04-06 15:24:40 UTC
(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.

Comment 20 Lorenzo Villani 2009-05-08 09:17:39 UTC
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.

Comment 21 Bug Zapper 2009-06-10 01:50:31 UTC
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

Comment 22 Bug Zapper 2009-07-14 17:54:17 UTC
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.


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