Created attachment 112167 [details] kde-partition-manager-luks-decrypted-no-volumes KDE Partition Manager 3.3.1 does not show volumes inside the luks. Command line tools do show the volumes inside the luks volume once the luks is unlocked with the password: root@kubuntu:/dev/mapper# lvscan ACTIVE '/dev/ubuntu/swap' [6.00 GiB] contiguous ACTIVE '/dev/ubuntu/root' [<231.88 GiB] inherit root@kubuntu:/dev/mapper# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdc 8:32 0 238.5G 0 disk ├─sdc1 8:33 0 512M 0 part └─sdc2 8:34 0 238G 0 part └─luks-e2f4536d-2140-46c8-4518-19b2da32dd35 253:0 0 237.9G 0 crypt ├─ubu-swap 253:1 0 6G 0 lvm └─ubu-root 253:2 0 231.9G 0 lvm root@kubuntu:/dev/mapper# ls /dev/mapper control luks-e2f4536d-2140-46c8-4518-19b2da32dd35 ubuntu-root ubuntu-swap
What is the output of sudo vgs --noheadings -o vg_name
(In reply to Andrius Štikonas from comment #1) > What is the output of > sudo vgs --noheadings -o vg_name Outputs: ubu
root@kubuntu:/dev/mapper# lvscan ACTIVE '/dev/ubu/swap' [6.00 GiB] contiguous ACTIVE '/dev/ubu/root' [<231.88 GiB] inherit
root@kubuntu:/dev/mapper# ls /dev/mapper control luks-e2f4536d-2140-46c8-4518-19b2da32dd35 ubu-root ubu-swap
(In reply to Teddy from comment #2) > (In reply to Andrius Štikonas from comment #1) > > What is the output of > > sudo vgs --noheadings -o vg_name > > Outputs: > ubu Hmm, strange... This is basically the command that KPM uses to list volume groups. You should see ubu in the list of devices... So you can't see it on the left? I use this setup (LVM inside LUKS) myself and I saw it working on Kubuntu 17.10 too.
(In reply to Andrius Štikonas from comment #5) > (In reply to Teddy from comment #2) > > (In reply to Andrius Štikonas from comment #1) > > > What is the output of > > > sudo vgs --noheadings -o vg_name > > > > Outputs: > > ubu > > Hmm, strange... This is basically the command that KPM uses to list volume > groups. > You should see ubu in the list of devices... So you can't see it on the left? > > I use this setup (LVM inside LUKS) myself and I saw it working on Kubuntu > 17.10 too. The ubu appears at the left if the device if it's the boot device, if I start the operating system actually from sdc. However, in the bug report, I was using the live environment "kubuntu-18.04-beta2-desktop-amd64.iso", and connected sdc to the USB port (which is the luks encrypted drive), which corresponds to the first screenshot.
Created attachment 112177 [details] Actually booting from the luks drive
(In reply to Teddy from comment #7) > Created attachment 112177 [details] > Actually booting from the luks drive Did you run that command I asked ("sudo vgs --noheadings -o vg_name") from the live environment, i.e. where partition manager fails to list ubu device? In principle it should correctly and automatically activate all volume groups using "vgchange -ay" as long as lvm is installed.
(In reply to Andrius Štikonas from comment #8) > (In reply to Teddy from comment #7) > > Created attachment 112177 [details] > > Actually booting from the luks drive > > Did you run that command I asked ("sudo vgs --noheadings -o vg_name") from > the live environment, i.e. where partition manager fails to list ubu device? > > In principle it should correctly and automatically activate all volume > groups using "vgchange -ay" as long as lvm is installed. Yes, I did run the command from the live environment. Finally found the culprit, running 'Decrypt' from the UI does NOT automatically refresh devices (F5). After manually refreshing> - 'Type' changes from 'luks' to 'lvm2 pv [luks]' - Mount point changes from nothing to ubu (with a lock symbol) - A new device is added on the left called ubu (/dev/ubu), which doesn't show before refreshing, and inside there are the root and swap partitions. The opposite happens when running 'Deactivate' So, running those commands should refresh all devices, and not only the current one (/dev/sdc). IF you don't want to do that for any reason, at least display a toast message to the user, like "Refresh Devices from Tools to display changes"
When running Deactivate doen't refresh either.
(In reply to Teddy from comment #10) > When running Deactivate doen't refresh either. Oh yeah... This is actually simply not implemented yet. So it is more of a feature request than a bug.
(In reply to Andrius Štikonas from comment #11) > (In reply to Teddy from comment #10) > > When running Deactivate doen't refresh either. > > Oh yeah... This is actually simply not implemented yet. So it is more of a > feature request than a bug. Then just refresh. All partition manager for Microsoft Windows do that automatically, always.
(In reply to Teddy from comment #12) > (In reply to Andrius Štikonas from comment #11) > > (In reply to Teddy from comment #10) > > > When running Deactivate doen't refresh either. > > > > Oh yeah... This is actually simply not implemented yet. So it is more of a > > feature request than a bug. > > Then just refresh. All partition manager for Microsoft Windows do that > automatically, always. It's better to just rescan what's necessary, not everything. Note that refreshing also means clearing all pending operations.
(In reply to Andrius Štikonas from comment #13) > (In reply to Teddy from comment #12) > > (In reply to Andrius Štikonas from comment #11) > > > (In reply to Teddy from comment #10) > > > > When running Deactivate doen't refresh either. > > > > > > Oh yeah... This is actually simply not implemented yet. So it is more of a > > > feature request than a bug. > > > > Then just refresh. All partition manager for Microsoft Windows do that > > automatically, always. > > It's better to just rescan what's necessary, not everything. Note that > refreshing also means clearing all pending operations. Avoiding automatic refresh causes problems, because enables option in the user interface which shouldn't be there. For example, follow this steps: 1) Select luks volume (sdc2) > Decrypt > Enter proper passphrase 2) Select again same volume (sdc2) > Deactivate > ERROR: "The encrypted file system on partition /dev/sdc2 could not be locked.". Details>> doesn't show why it happened (see bug #393393) This happens, because it displays the option "Deactivate", when shouldn't be available until you Deactivate Volume Group on new created device, which isn't visible until you refresh. And if you want to refresh, you have to cancel the queue anyway, so it doesn't make sense to overlap both things. You are mixing operations that can be queued (create new simple partition), with others that take effect immediately, like unlocking/re-locking luks volumes. The User Interface must be consistent at all times, so a way to mix both types of operations has to be found.
Created attachment 112202 [details] error-when-refreshing-is-skipped
Executing commands that take immediate action should have the same refresh behavior than clicking the Apply button, because you are applying changes in both cases.
My suggestion is to do it in either one of two ways: 1) Add lock/unlock luks to the queue, and the same for every command. The problem is that you can't see the result immediately (the unlock requires a passphrase,and until you Apply you don't know if the passphrase is valid or not) unless you implement a smart logic to test without applying changes. That way you could see what the possible unlocked volumes and queue more upon them. 2) In case you want to take immediate action, prompt the user that there are pending operations and refresh is required.
(In reply to Teddy from comment #14) > (In reply to Andrius Štikonas from comment #13) > > (In reply to Teddy from comment #12) > > > (In reply to Andrius Štikonas from comment #11) > > > > (In reply to Teddy from comment #10) > > > > > When running Deactivate doen't refresh either. > > > > > > > > Oh yeah... This is actually simply not implemented yet. So it is more of a > > > > feature request than a bug. > > > > > > Then just refresh. All partition manager for Microsoft Windows do that > > > automatically, always. > > > > It's better to just rescan what's necessary, not everything. Note that > > refreshing also means clearing all pending operations. > > Avoiding automatic refresh causes problems, because enables option in the > user interface which shouldn't be there. > For example, follow this steps: > > 1) Select luks volume (sdc2) > Decrypt > Enter proper passphrase > > 2) Select again same volume (sdc2) > Deactivate > ERROR: "The encrypted file > system on partition /dev/sdc2 could not be locked.". Details>> doesn't show > why it happened (see bug #393393) > > This happens, because it displays the option "Deactivate", when shouldn't be > available until you Deactivate Volume Group on new created device, which > isn't visible until you refresh. > > And if you want to refresh, you have to cancel the queue anyway, so it > doesn't make sense to overlap both things. You are mixing operations that > can be queued (create new simple partition), with others that take effect > immediately, like unlocking/re-locking luks volumes. > > The User Interface must be consistent at all times, so a way to mix both > types of operations has to be found. Hmm, but Volume groups shouldn't be activated by just unlocking LUKS volume? It only runs "crypsetup open", so I don't understand why your Volume group is active? Maybe I'll have to test to see if I can reproduce failure to lock.(In reply to Teddy from comment #14) > (In reply to Andrius Štikonas from comment #13) > > (In reply to Teddy from comment #12) > > > (In reply to Andrius Štikonas from comment #11) > > > > (In reply to Teddy from comment #10) > > > > > When running Deactivate doen't refresh either. > > > > > > > > Oh yeah... This is actually simply not implemented yet. So it is more of a > > > > feature request than a bug. > > > > > > Then just refresh. All partition manager for Microsoft Windows do that > > > automatically, always. > > > > It's better to just rescan what's necessary, not everything. Note that > > refreshing also means clearing all pending operations. > > Avoiding automatic refresh causes problems, because enables option in the > user interface which shouldn't be there. > For example, follow this steps: > > 1) Select luks volume (sdc2) > Decrypt > Enter proper passphrase > > 2) Select again same volume (sdc2) > Deactivate > ERROR: "The encrypted file > system on partition /dev/sdc2 could not be locked.". Details>> doesn't show > why it happened (see bug #393393) > > This happens, because it displays the option "Deactivate", when shouldn't be > available until you Deactivate Volume Group on new created device, which > isn't visible until you refresh. > > And if you want to refresh, you have to cancel the queue anyway, so it > doesn't make sense to overlap both things. You are mixing operations that > can be queued (create new simple partition), with others that take effect > immediately, like unlocking/re-locking luks volumes. > > The User Interface must be consistent at all times, so a way to mix both > types of operations has to be found. Hmm, but Volume groups shouldn't be activated by just unlocking LUKS volume? It only runs "crypsetup open", so I don't understand why your Volume group is active? Maybe I'll have to test to see if I can reproduce failure to lock.
(In reply to Andrius Štikonas from comment #18) > > Maybe I'll have to test to see if I can reproduce failure to lock. > Maybe it's some kde service that auto-mounts the file systems?
(In reply to Andrius Štikonas from comment #18) > (In reply to Teddy from comment #14) > > Hmm, but Volume groups shouldn't be activated by just unlocking LUKS volume? > It only runs "crypsetup open", so I don't understand why your Volume group > is active? > > Maybe I'll have to test to see if I can reproduce failure to lock. In any case there's no option to "reactivate" the volume groups, even if I click deactivate still shows deactivate, and if I refresh before locking the luks I have to deactivate again otherwise fails like in last attachment.
(In reply to Teddy from comment #20) > (In reply to Andrius Štikonas from comment #18) > > (In reply to Teddy from comment #14) > > > > Hmm, but Volume groups shouldn't be activated by just unlocking LUKS volume? > > It only runs "crypsetup open", so I don't understand why your Volume group > > is active? > > > > Maybe I'll have to test to see if I can reproduce failure to lock. > > In any case there's no option to "reactivate" the volume groups, even if I > click deactivate still shows deactivate, and if I refresh before locking the > luks I have to deactivate again otherwise fails like in last attachment. This behaviour is expected. If you refresh devices before locking, KPM performs full rescan and reactivates all volume groups, so LUKS partition becomes busy.
(In reply to Teddy from comment #19) > (In reply to Andrius Štikonas from comment #18) > > > > Maybe I'll have to test to see if I can reproduce failure to lock. > > > > Maybe it's some kde service that auto-mounts the file systems? Hmm, could be. Plasma automounter is disabled while operations are running, but I'm not sure about these individual actions. I can investigate this further.
(In reply to Andrius Štikonas from comment #21) > (In reply to Teddy from comment #20) > > (In reply to Andrius Štikonas from comment #18) > > > (In reply to Teddy from comment #14) > > > > > > Hmm, but Volume groups shouldn't be activated by just unlocking LUKS volume? > > > It only runs "crypsetup open", so I don't understand why your Volume group > > > is active? > > > > > > Maybe I'll have to test to see if I can reproduce failure to lock. > > > > In any case there's no option to "reactivate" the volume groups, even if I > > click deactivate still shows deactivate, and if I refresh before locking the > > luks I have to deactivate again otherwise fails like in last attachment. > > This behaviour is expected. If you refresh devices before locking, KPM > performs full rescan and reactivates all volume groups, so LUKS partition > becomes busy. I did the test without refreshing, yet looks like the volume groups are mounted anyway. If you can check it better.
(In reply to Teddy from comment #23) > (In reply to Andrius Štikonas from comment #21) > > (In reply to Teddy from comment #20) > > > (In reply to Andrius Štikonas from comment #18) > > > > (In reply to Teddy from comment #14) > > > > > > > > Hmm, but Volume groups shouldn't be activated by just unlocking LUKS volume? > > > > It only runs "crypsetup open", so I don't understand why your Volume group > > > > is active? > > > > > > > > Maybe I'll have to test to see if I can reproduce failure to lock. > > > > > > In any case there's no option to "reactivate" the volume groups, even if I > > > click deactivate still shows deactivate, and if I refresh before locking the > > > luks I have to deactivate again otherwise fails like in last attachment. > > > > This behaviour is expected. If you refresh devices before locking, KPM > > performs full rescan and reactivates all volume groups, so LUKS partition > > becomes busy. > > I did the test without refreshing, yet looks like the volume groups are > mounted anyway. If you can check it better. Maybe you can check if plasma automounter is running? I think this is the main culprint. Without automounting the current behaviour is not as bad.
(In reply to Andrius Štikonas from comment #24) > (In reply to Teddy from comment #23) > > (In reply to Andrius Štikonas from comment #21) > > > (In reply to Teddy from comment #20) > > > > (In reply to Andrius Štikonas from comment #18) > > > > > (In reply to Teddy from comment #14) > > > > > > > > > > Hmm, but Volume groups shouldn't be activated by just unlocking LUKS volume? > > > > > It only runs "crypsetup open", so I don't understand why your Volume group > > > > > is active? > > > > > > > > > > Maybe I'll have to test to see if I can reproduce failure to lock. > > > > > > > > In any case there's no option to "reactivate" the volume groups, even if I > > > > click deactivate still shows deactivate, and if I refresh before locking the > > > > luks I have to deactivate again otherwise fails like in last attachment. > > > > > > This behaviour is expected. If you refresh devices before locking, KPM > > > performs full rescan and reactivates all volume groups, so LUKS partition > > > becomes busy. > > > > I did the test without refreshing, yet looks like the volume groups are > > mounted anyway. If you can check it better. > > Maybe you can check if plasma automounter is running? I think this is the > main culprint. Without automounting the current behaviour is not as bad. I'm running from the beta-2 kubuntu iso, and automount is disabled by default. ----------------------- With locked luks: root@kubuntu:~# ls /dev/mapper/ control root@kubuntu:~# ls /dev/ubu ls: cannot access '/dev/ubu': No such file or directory root@kubuntu:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 1.8G 0 loop /cdrom loop1 7:1 0 1.7G 1 loop /rofs sdb 8:16 1 119.2G 0 disk └─sdb1 8:17 1 119.2G 0 part /isodevice sdc 8:32 0 238.5G 0 disk ├─sdc1 8:33 0 512M 0 part └─sdc2 8:34 0 238G 0 part root@kubuntu:~# vgscan Reading volume groups from cache. ----------------------- Just after Decrypt and NO refresh. swap and root are not mounted at least "mount" does not display them: control luks-xxxxxxxxx ubu-root ubu-swap root@kubuntu:~# ls /dev/ubu root swap root@kubuntu:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 1.8G 0 loop /cdrom loop1 7:1 0 1.7G 1 loop /rofs sdb 8:16 1 119.2G 0 disk └─sdb1 8:17 1 119.2G 0 part /isodevice sdc 8:32 0 238.5G 0 disk ├─sdc1 8:33 0 512M 0 part └─sdc2 8:34 0 238G 0 part └─luks-xxxxxxxxxxxxxxxxxxxxxxxxxx 253:0 0 237.9G 0 crypt ├─ubu-swap 253:1 0 6G 0 lvm └─ubu-root 253:2 0 231.9G 0 lvm root@kubuntu:~# vgscan Reading volume groups from cache. Found volume group "ubu" using metadata type lvm2 NOTE: If I choose on KPM "Deactivate Volume Group" and I refresh the volume is re-activated. This shouldn't happen because I didn't choose to Activate Volume Group. Even more, there is no such option for that.
Created attachment 112206 [details] kde live 18.04 beta-2 no automount by default
More information why it may fail: The operation "Deactivate Volume Group" tries to umount also /dev/mapper/luks-xxxxx when it should umount only "ubu-root" and "ubu-swap". umount "/dev/mapper/luks-xxxxx" is reserved to Lock the encryption again I think. Running the command "cryptsetup luksOpen /dev/sdc2 sdc2-crypt", besides unlocking luks, also activates the luks volumes, I've tried it. The problem is that when I "Deactivate Volume Group" the "Activate Volume Group" is not present because luks-xxxxxx (sdc2-crypt) is missing from /dev/mapper. Please check how gparted does, it works perfectly for Activate/Deactivate luks volumes (although doesn't have the Decrypt option and doesn't show ubu either on the list of devices).
Also the naming convention is different. You use 'luks-xxxxxx' while on ubuntu the standard is 'sdc2-crypt'.
What are you going to do finally about this?
(In reply to Teddy from comment #29) > What are you going to do finally about this? I didn't have time to look at this yet.