Created attachment 523115 [details]
anaconda.log

Created attachment 523116 [details]
program.log

Created attachment 523117 [details]
storage.log

I have system with installed F15 on encrypted partition. I tried to install F16 on LVM encrypted partition to have dual boot. It crashes after I selected "write changes on disk" button.


Proposing as F16 Beta blocker, because it fails this criterion:

The installer must be able to complete an installation using the entire disk, existing free space, or existing Linux partitions methods, with or without encryption or LVM enabled
https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria

Could you attach the /tmp/anaconda-tb-* file when you hit this?  The logs are helpful, but the traceback file also tells us what device specification was invalid.

I tried to reproduce this in a VM but was not successful. I'm not sure that I understand your partition layout, though. Can you provide more details (PV encryption vs LV encryption, was everything on the same VG, separate /boot etc.)?

To grab the anaconda tb, you can use a test boot.iso that has a newer version of libreport in it:

http://tflink.fedorapeople.org/iso/20110914_preRC_boot3.x86_64.iso
http://tflink.fedorapeople.org/iso/20110914_preRC_boot3.x86_64.iso.sha256

However, unless I'm misunderstanding something I don't think that this would be a beta blocker since it is a very non-default partitioning scheme. It would qualify as a final blocker, though.

Unless more information comes up, I'm -1 beta blocker, +1 final blocker.

Created attachment 523346 [details]
traceback for anaconda

Created attachment 523357 [details]
disk layout

In layout.png you can find my disk layout. sda3 partition is encrypted and lv_devel is encrypted (not whole lvm volume). You can also see that I wanted to install root on lv_devel and /boot on sda4. Anaconda asked me for password to both encrypted partitions.

bug 722952 I reproduced this bug when I unchecked encrypt in lv_devel (on which I wanted to have root) and then I tried to install as above.

This is the same scenario as 722952 except that in this case the user first tried to reuse the root lv without reformatting and received an error stating the he/she must reformat the root device. The fix for bug 723303 would have caught the invalid path except that it is only checked if the device is not being reformatted. The fix for this will be to move that check up so that it gets performed whenever an existing lv is being reused.

So, this (and 722952) is a clear final blocker under the 'any workable layout' final criterion. For Beta the situation is less clear: it's a partial infringement of "The installer must be able to complete an installation using the entire disk, existing free space, or existing Linux partitions methods, with or without encryption or LVM enabled" (Alpha criterion). Now we have an RC and a deadline, we're at the point where we need to judge the benefit/danger trade-off of taking another anaconda build. Let's talk it over at the blocker review meeting tomorrow. On instinct I'm lightly in favour of taking this as a blocker and including a new anaconda build with the patches for this in RC2.

dlehman remarks "[unless we take the fixes], changing anything in the lvm dialogs is fraught with danger"..."if these patches weren't all three fixes to regressions caused by similarly simple-seeming fixes in those dialogs I would be telling you that they are pretty safe".

the patches for this are to be found in this anaconda-devel thread:

https://www.redhat.com/archives/anaconda-devel-list/2011-September/msg00122.html

they look nice and small, but as dlehman notes, we already know that small, 'obvious' changes can break a lot of stuff when it comes to handling LVs.

Note that if we took an anaconda build that fixed these bugs but it caused major, major regressions, we would have the option of changing our minds and going back to 16.18, I guess: we wouldn't be stuck trying to firefight the regressions.

An updates image is available for those who would like to test/verify a fix. Add the following to the boot command line if interested:

  updates=http://dlehman.fedorapeople.org/updates-lvm.img

*** Bug 732861 has been marked as a duplicate of this bug. ***

we are also interested in general testing of RC1 with the updates image, not just specific testing to see if it resolves this bug, but also to see if it causes any other problems.

I did some simple testing with dlehman's update.img and haven't seen any issues yet.

I did a couple of vanilla full disk installs with lvm and a more complicated setup. I did hit #733449 but nothing LVM related.

Discussed in the 2011-09-16 blocker review meeting. Rejected as Fedora 16 blocker as it doesn't hit any of the release criteria. However, it would be nice to fix and a patch is almost ready - accepted as NTH for Fedora 16 Beta.

This was accepted as a blocker for Fedora 16 final because it hist the following final release criteria [1]:

The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above 

[1] https://fedoraproject.org/wiki/Fedora_16_Final_Release_Criteria

Works for me with dlehman's update.img. Installation completed successfully.

dlehman: again, is this going to be committed for 16.19? thanks!

Yes. It will be in anaconda-16.19.

anaconda-16.19-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/anaconda-16.19-1.fc16

anaconda-16.19-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.