+++ This bug was initially created as a clone of Bug #1348688 +++ Description of problem: On accessing the MANUAL PARTITIONING screen, my hard disk layout is displayed as follows Unknown ext4 sda1 Encrypted (LUKS) sda2 BIOS boot sda9 On selecting the "Encrypted (LUKS)" partition, I can enter my passphrase and decrypt the device. Anaconda now shows my hard disk layout as follows Unknown physical volume (LVM) luks-123.... ext4 sda1 BIOS boot sda9 I can find no way to access and use my LVM configuration on the LVM physical volume. However, from the shell I can see the partition has been decrypted and Volume Group and all the Logical Volumes contained have been activated. It seems like in Fedora 24 Anaconda simply does not try to detect any LVM configuration within a LUKS-encrypted partition when it is decrypted. Version-Release number of selected component (if applicable): (as shipped in Fedora-Workstation-netinst-x86_64-24-1.2.iso) How reproducible: Steps to Reproduce: 1. LUKS-encrypt a disk partition 2. Decrypt the partition and create LVM Volume Group using the partion. 3. Create some Logical Volumes in the VG 4. Reboot using Fedora 24 installation media and try to access the LVs when creating a manual partition layout. Actual results: After decrypting the LUKS partition, Anaconda only recognizes the contents as an LVM Physical Volume and so the only option available is to reformat. Expected results: Anaconda detects the LVM configuration on the Physical Volume, and allows the LVs to be added to the filesystem tree. Additional info: I was able to use this disk layout when installing Fedora 23 (admittedly I have converted the hdd format from MBR to GDM since then). --- Additional comment from Brian Lane on 2016-06-21 23:53:19 CEST --- Please attach the logs from /tmp/*log as individual text/plain attachments. --- Additional comment from Steve Bryant on 2016-06-22 00:15 CEST --- --- Additional comment from Steve Bryant on 2016-06-22 00:16 CEST --- --- Additional comment from Steve Bryant on 2016-06-22 00:16 CEST --- --- Additional comment from Steve Bryant on 2016-06-22 00:17 CEST --- --- Additional comment from Steve Bryant on 2016-06-22 00:17 CEST --- --- Additional comment from Steve Bryant on 2016-06-22 00:18 CEST --- --- Additional comment from Steve Bryant on 2016-06-22 00:19 CEST --- --- Additional comment from Steve Bryant on 2016-06-22 00:19 CEST --- --- Additional comment from Steve Bryant on 2016-06-22 00:20 CEST --- --- Additional comment from Steve Bryant on 2016-06-22 00:20 CEST --- --- Additional comment from Steve Bryant on 2016-06-22 00:27:48 CEST --- Cannot attach "syslog" and "X.log" - perhaps 10-attachment limit? If you require either of these, can you nominate a file to be replaced? --- Additional comment from Steve Bryant on 2016-06-22 01:12:50 CEST --- Note that the LUKS partition is the only PV used by VG "vg_miles": # pvs PV VG Fmt Attr PSize PFree /dev/mapper/luks-5b484048-e56e-4c04-be51-bba5553a3752 vg_miles lvm2 a-- 464.75g 280.75g --- Additional comment from Rob Foehl on 2016-06-23 03:32:57 CEST --- Same problem here, LVM volumes within LUKS aren't recognized by Anaconda after successfully unlocking the LUKS volume. Correct entries exist in /dev/mapper, pvs output is correct, ... but Anaconda never notices. Affects the netinst media for both Workstation and Server, haven't tried anything else thus far. --- Additional comment from Steve Bryant on 2016-06-23 09:39:21 CEST --- I think I might see the issue - in "/tmp/storage.log" (attached), it actually finds the devices used by LVM volumes listed in /dev/mapper: > 23:01:40,132 DEBUG storage.ui: DeviceTree.getDeviceByName: hidden: False ; incomplete: False ; name: vg_miles-libvirt ; > 23:01:40,133 DEBUG storage.ui: DeviceTree.getDeviceByName returned None > 23:01:40,134 INFO storage.ui: vg_miles-libvirt is an lvm logical volume However, it fails to find a corresponding device for the LVM volume group: > 23:01:40,150 DEBUG storage.ui: DeviceTree.getDeviceByName: hidden: False ; incomplete: False ; name: vg_miles ; > 23:01:40,152 DEBUG storage.ui: DeviceTree.getDeviceByName returned None > 23:01:40,152 ERR storage.ui: failed to find vg 'vg_miles' after scanning pvs This is to be expected as LVM volume groups have no corresponding device special file ("DeviceTree.getDeviceByName" will always fail for a VG name?) In the "/dev" file system LVM volume groups only exist as directories containing links from the names of the logical volumes they contain to the corresponding "dm" devices: # find /dev -name vg_miles /dev/vg_miles # ls -lh /dev/vg_miles total 0 lrwxrwxrwx. 1 root root 7 Jun 23 07:40 F21Root -> ../dm-5 lrwxrwxrwx. 1 root root 7 Jun 23 07:40 F23Root -> ../dm-1 lrwxrwxrwx. 1 root root 7 Jun 23 07:40 F24Root -> ../dm-7 lrwxrwxrwx. 1 root root 7 Jun 23 07:40 Home -> ../dm-6 lrwxrwxrwx. 1 root root 7 Jun 23 07:40 lfs -> ../dm-3 lrwxrwxrwx. 1 root root 7 Jun 23 07:40 libvirt -> ../dm-4 lrwxrwxrwx. 1 root root 7 Jun 23 07:40 Swap -> ../dm-2 --- Additional comment from David Lehman on 2016-06-23 18:37:45 CEST --- It looks like we can't get information about the recently-decrypted PV. Now that we're using the lvm-dbus plugin I can't see what the PV info looks like -- maybe the path for a device-mapper PV isn't using the map name (using 'dm-2' instead?). --- Additional comment from Steve Bryant on 2016-06-23 18:53 CEST --- File permissions were preventing me uploading this... --- Additional comment from Steve Bryant on 2016-06-23 18:54 CEST --- --- Additional comment from Vratislav Podzimek on 2016-06-24 10:49:33 CEST --- (In reply to David Lehman from comment #16) > It looks like we can't get information about the recently-decrypted PV. Now > that we're using the lvm-dbus plugin I can't see what the PV info looks like > -- maybe the path for a device-mapper PV isn't using the map name (using > 'dm-2' instead?). The problem here is that the lvmdbusd doesn't notice and react on the even of the LUKS device being opened. So while the 'pvs' utility knows about the PV, which means that the pvscan was performed, the DBus API doesn't know about it. Reassigning this to LVM. --- Additional comment from Vratislav Podzimek on 2016-06-24 14:36:50 CEST --- The following updates.img should work around this issue by avoiding the use of the DBus API: http://vpodzime.fedorapeople.org/1348688_updates.img --- Additional comment from Tomas Dolezal on 2016-06-24 14:56:12 CEST --- I've succeeded in reusing encrypted partitions after specifying this updates= image file. --- Additional comment from Steve Bryant on 2016-06-24 17:31:28 CEST --- The 1348688_updates.img patch also allowed me to install F24 using my LVM configuration on the LUKS-encrypted volume after decryption. Thanks! --- Additional comment from Tony Asleson on 2016-06-27 19:06:31 CEST --- lvm fedora package isn't being built with '--enable-notify-dbus', thus the lvm dbus service is not getting notifications from lvm to refresh its state. So at the moment the lvm dbus service is quite broken. One potential workaround is to change the service file to add back in the '--udev' option until a new package with '--enable-notify-dbus' is available. --- Additional comment from Tony Asleson on 2016-06-28 00:44:42 CEST --- I found a bug when running with 'enable-notify-dbus'. When doing a lv move, vg move or lv snapshot merge the client will hang if they specify that they willing to wait definitely. Immediate work around is to use --udev option when running service instead of compiling with notify dbus support. Once we get a fix in for this hang then we should compile with 'enable-notify-dbus'. --- Additional comment from Tony Asleson on 2016-06-28 21:31:58 CEST --- Hang when using 'enable-notify-dbus' has been committed upstream. To reiterate, the issue which pertains to the bz can be addressed by 2 different ways: 1. Repackage existing version, but patch the lvmdbusd service file to use --udev 2. Release a new version of lvm which contains https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=dd5d865020acd545712d4bcc0f3236143de4d76d and utilize 'enable-notify-dbus' when building lvm. --- Additional comment from Brian Lane on 2016-06-28 23:26:38 CEST --- --- Additional comment from Peter Rajnoha on 2016-07-01 08:41:03 CEST --- Fedora 24 anaconda installer is fixed in current version using update image from https://fedoraproject.org/wiki/Common_F24_bugs#lvm-on-luks-reuse-broken. I'll also provide updated lvm2 package in Fedora 24 as well.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. 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 EOL if it remains open with a Fedora 'version' of '24'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.