[partitionmanager] [Bug 393397] KDE Partition Manager does not refresh all devices when executing a permanent action

[soredake]

https://bugs.kde.org/show_bug.cgi?id=393397

soredake  changed:

   What|Removed |Added

 CC||ndrzj1...@relay.firefox.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[partitionmanager] [Bug 393397] KDE Partition Manager does not refresh all devices when executing a permanent action

[Andrius Štikonas]

https://bugs.kde.org/show_bug.cgi?id=393397

--- Comment #30 from Andrius Štikonas  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[partitionmanager] [Bug 393397] KDE Partition Manager does not refresh all devices when executing a permanent action

[Teddy]

https://bugs.kde.org/show_bug.cgi?id=393397

--- Comment #29 from Teddy  ---
What are you going to do finally about this?

-- 
You are receiving this mail because:
You are watching all bug changes.

[partitionmanager] [Bug 393397] KDE Partition Manager does not refresh all devices when executing a permanent action

[Teddy]

https://bugs.kde.org/show_bug.cgi?id=393397

--- Comment #28 from Teddy  ---
Also the naming convention is different. You use 'luks-xx' while on ubuntu
the standard is 'sdc2-crypt'.

-- 
You are receiving this mail because:
You are watching all bug changes.

[partitionmanager] [Bug 393397] KDE Partition Manager does not refresh all devices when executing a permanent action

[Teddy]

https://bugs.kde.org/show_bug.cgi?id=393397

--- Comment #27 from Teddy  ---
More information why it may fail:

The operation "Deactivate Volume Group" tries to umount also
/dev/mapper/luks-x when it should umount only "ubu-root" and "ubu-swap".
umount "/dev/mapper/luks-x" 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-xx (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).

-- 
You are receiving this mail because:
You are watching all bug changes.

[partitionmanager] [Bug 393397] KDE Partition Manager does not refresh all devices when executing a permanent action

[Teddy]

https://bugs.kde.org/show_bug.cgi?id=393397

--- Comment #26 from Teddy  ---
Created attachment 112206
  --> https://bugs.kde.org/attachment.cgi?id=112206=edit
kde live 18.04 beta-2 no automount by default

-- 
You are receiving this mail because:
You are watching all bug changes.

[partitionmanager] [Bug 393397] KDE Partition Manager does not refresh all devices when executing a permanent action

[Teddy]

https://bugs.kde.org/show_bug.cgi?id=393397

--- Comment #25 from Teddy  ---
(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
NAMEMAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0 7:00   1.8G  0 loop /cdrom
loop1 7:10   1.7G  1 loop /rofs
sdb   8:16   1 119.2G  0 disk 
└─sdb18:17   1 119.2G  0 part /isodevice
sdc   8:32   0 238.5G  0 disk 
├─sdc18:33   0   512M  0 part 
└─sdc28: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-x  ubu-root  ubu-swap
root@kubuntu:~# ls /dev/ubu
root  swap
root@kubuntu:~# lsblk
NAME  MAJ:MIN RM   SIZE RO TYPE 
MOUNTPOINT
loop0   7:00   1.8G  0 loop  /cdrom
loop1   7:10   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-xx 253:00 237.9G  0 crypt 
├─ubu-swap253:10 6G  0 lvm   
└─ubu-root253:20 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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[partitionmanager] [Bug 393397] KDE Partition Manager does not refresh all devices when executing a permanent action

[Andrius Štikonas]

https://bugs.kde.org/show_bug.cgi?id=393397

--- Comment #24 from Andrius Štikonas  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[partitionmanager] [Bug 393397] KDE Partition Manager does not refresh all devices when executing a permanent action

[Teddy]

https://bugs.kde.org/show_bug.cgi?id=393397

--- Comment #23 from Teddy  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[partitionmanager] [Bug 393397] KDE Partition Manager does not refresh all devices when executing a permanent action

[Andrius Štikonas]

https://bugs.kde.org/show_bug.cgi?id=393397

--- Comment #22 from Andrius Štikonas  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[partitionmanager] [Bug 393397] KDE Partition Manager does not refresh all devices when executing a permanent action

[Andrius Štikonas]

https://bugs.kde.org/show_bug.cgi?id=393397

--- Comment #21 from Andrius Štikonas  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[partitionmanager] [Bug 393397] KDE Partition Manager does not refresh all devices when executing a permanent action

[Teddy]

https://bugs.kde.org/show_bug.cgi?id=393397

--- Comment #20 from Teddy  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[partitionmanager] [Bug 393397] KDE Partition Manager does not refresh all devices when executing a permanent action

[Teddy]

https://bugs.kde.org/show_bug.cgi?id=393397

--- Comment #19 from Teddy  ---
(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?

-- 
You are receiving this mail because:
You are watching all bug changes.

[partitionmanager] [Bug 393397] KDE Partition Manager does not refresh all devices when executing a permanent action

[Andrius Štikonas]

https://bugs.kde.org/show_bug.cgi?id=393397

--- Comment #18 from Andrius Štikonas  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[partitionmanager] [Bug 393397] KDE Partition Manager does not refresh all devices when executing a permanent action

[Teddy]

https://bugs.kde.org/show_bug.cgi?id=393397

--- Comment #17 from Teddy  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[partitionmanager] [Bug 393397] KDE Partition Manager does not refresh all devices when executing a permanent action

[Teddy]

https://bugs.kde.org/show_bug.cgi?id=393397

--- Comment #16 from Teddy  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[partitionmanager] [Bug 393397] KDE Partition Manager does not refresh all devices when executing a permanent action

[Teddy]

https://bugs.kde.org/show_bug.cgi?id=393397

Teddy  changed:

   What|Removed |Added

Summary|KDE Partition Manager does  |KDE Partition Manager does
   |not refresh all devices |not refresh all devices
   |when unlocking luks volumes |when executing a permanent
   ||action

-- 
You are receiving this mail because:
You are watching all bug changes.