Created attachment 650623 [details] screenshot showing 4 MB root volume Description of problem: With encryption enabled, the root volume may be created with 4 MB capacity instead of 3000 MB capacity even when ample disk space is available. Version-Release number of selected component (if applicable): anaconda-0:18.29.2-1.fc18.x86_64 Fedora-18-Beta-x86_64-Live-Desktop.iso (RC1) How reproducible: Always. Steps to Reproduce: Create 12 GB empty disc image: $ qemu-img create f18-test-3.img 12G Start installer from Live CD: $ qemu-kvm -m 2048 -hda f18-test-3.img -cdrom ~/xfr/fedora/F18/F18-Beta/RC1/Fedora-18-Beta-x86_64-Live-Desktop.iso -usb -vga qxl -boot menu=on -usbdevice mouse Click Installation Destination. Check "Encrypt my data. ..." Click Continue. Check "Let me customize ..." Click Continue. Click to auto-create mount points. Click "+" Customize to expand. Click Root to select. Uncheck Encrypt. Click Root to select. Click "-" to remove. Click "+' to add. Enter "/" for mount point. Enter 3000 for capacity. Click Add mount point. Actual results: Root volume is created with 4 MB capacity. See attached screenshot. Expected results: Root volume is created with 3000 MB capacity. Additional info: Observed while verifying the fix for: Bug 874714 - AttributeError: 'LUKSDevice' object has no attribute 'disk'
Created attachment 650650 [details] anaconda-tb-all.log log file corresponding to reproducer. This was captured with: # pkill -USR2 -o anaconda
(In reply to comment #1) > Created attachment 650650 [details] > anaconda-tb-all.log log file corresponding to reproducer. > > This was captured with: > # pkill -USR2 -o anaconda ... after entering a LUKS passphrase and returning to the Installation Summary. The Installation Destination link did not show any errors. The install failed at "Installing software 1%" with "rsync exited with code 12".
Created attachment 650651 [details] anaconda-tb-1NhmJb with PayloadInstallError: rsync exited with code 12
I have a patch. Once I've tested it I'll send it off for review. Meanwhile, you can work around this by toggling encryption in a separate operation. As of now, encryption applies to the entire vg -- not individual lvs.
I realize now that your workflow was different from what I inferred from the logs. There are two things going on here: 1) new device defaults are overriding setting in an already-defined container 2) there are issues with management of containers while also enabling encryption I have a patch for each which I have tested and will soon post for review.
pykickstart-1.99.22-1.fc18, anaconda-18.34-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/FEDORA-2012-19380/pykickstart-1.99.22-1.fc18,anaconda-18.34-1.fc18
Package pykickstart-1.99.22-1.fc18, anaconda-18.34-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing pykickstart-1.99.22-1.fc18 anaconda-18.34-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-19380/pykickstart-1.99.22-1.fc18,anaconda-18.34-1.fc18 then log in and leave karma (feedback).
Package pykickstart-1.99.22-1.fc18, anaconda-18.35-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing pykickstart-1.99.22-1.fc18 anaconda-18.35-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-19380/pykickstart-1.99.22-1.fc18,anaconda-18.35-1.fc18 then log in and leave karma (feedback).
pykickstart-1.99.22-1.fc18, anaconda-18.35-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.