lvm

KDE Partition Manager 3.3 and future work

Posted on by Andrius Štikonas

KDE Partition Manager 3.3 is now ready. It includes some improvements for Btrfs, F2FS, NTFS file systems. I even landed the first bits of new LUKS2 on-disk format support, now KDE Partition Manager can display LUKS2 labels. More LUKS2 work will follow in KPM 3.4. There were changes in how LVM devices are detected. So now Calamares installer should be able to see LVM logical volumes. Once my pull request lands, Calamares should also support partitioning operations on LVM logical volumes (although Calamares would need more work before installation and booting from root file system on LVM works. I tested Calamares with KPMcore 3.3 and it successfully installed rootfs in LVM volume and successfully booted). KPMcore library now only depends on Tier 1 Frameworks instead of Tier 3 (although, we will later require Tier 2).

Most of the work is now done in sfdisk branch.  Currently, the only functional KDE Partition Manager backend uses libparted but sfdisk backend is now fully working (I would say RC quality). I would have merged in already but it requires util-linux 2.32 which is not yet released.

Yet another branch on top of sfdisk is KAuth branch which allows KPM to run as unprivileged user and uses Polkit when necessary to gain root rights. Everything except SMART support is working. To get SMART working too we would have to port away from (unmaintained) libatasmart to calling smartctl. Feel free to help! It should be fairly easy task but somebody has to do the work. Other than that you can already perform all partitioning operations using KAuth with one caveat. Right now KPM calls KAuth helper many times while performing partitioning operations. It can happen that KAuth authorization will expire in the meantime (KAuth remembers it for about 5 minutes) and KAuth will request a user to enter root password. If the user enters correct password, operation would finish. However, if authorization is not granted we may end up with half completed operation. And of course we don’t want to leave partition half moved, the data will almost surely be lost (half-resized partition is probably okay…). I suppose we can fix this by refactoring KPM operation runner, so that it calls KAuth helper just once with a list of all commands that have to be run. Unfortunately, this KPM Operation Runner refactoring might be bigger than what I would like, as significant changes would be necessary in partition data copying code. Maybe GSoC project then… Or ar there any better ideas on how to prevent KAuth authorization dialog in the middle of partitioning operations?

You can grab tarballs from standard locations on download.kde.org server.

KDE Partition Manager 3.0

Posted on by Andrius Štikonas

KDE Partition Manager and KPMcore 3.0.0 have been released. Here are some of the new features:

  • Both LVM on LUKS and LUKS on LVM configurations are now supported.
  • Creating new LVM Volume Groups, adding or removing LVM Physical Volumes from LVM VG.
  • Resizing LVM Logical Volumes.
  • Resizing LVM Physical Volumes even if they belong to LVM Volume Group (used extents will be moved out somewhere else)
  • Added support for online resize. Not all filesystems support this, e.g. ext4 can only be grown online while btrfs supports both growing and shrinking.
  • Fixed some crashes, Qt 5.7.1 is also recommended to fix crash (in Qt) on exit.
  • Better support for sudo. Now KDE Partition Manager declares required environmental variables when kdesu uses sudo (e.g. in Kubuntu or Neon), so the theming is no longer broken. Environmental variables for Wayland are also fixed.

Here is a video demonstrating some of these new LVM capabilities. Note this is done directly from my main system, I’m resizing my encrypted rootfs without using any Live CD.

 

 

LVM support in KDE Partition Manager (feedback needed)

Posted on by Andrius Štikonas

Basic Logical Volume Management (LVM) support was added to KDE Partition Manager this summer. So LVM consists of 3 ingredients:

  1. LVM Physical Volumes. These are partitions on disk devices that are allocated for LVM. The union of LVM PVs is LVM Volume Group.
  2. LVM Volume Groups. These are more or less equivalent to devices that can be partitioned into LVM Logical Volumes.
  3. LVM Logical Volumes. These are similar to like your normal partitions but stored in LVM Volume Group instead of normal disk.

We can have a few different operations on a given LVM Volume Group, e.g. resize (add or remove LVM PVs), deactivate or remove that LVM VG:

LVM Device Menu

These 3 LVM VG operations are hidden in the menu of normal disk devices.

However, there is one more operation: creating LVM VG. At the moment it is listed with the other 3 operations but it is slightly different. It does not act on selected device. So we also can’t hide it for normal devices. So we have two choices:

  1. Keep “New Volume” in the Device menu and show it for all devices.
  2. Move “New Volume” operation into the context menu of LVM PV partition (e.g. where operations like mount, unmount, resize partitions are located) and only make it visible for LVM PV file systems but not other types.

Option 2 will have LVM VG operations split over 2 places, but on the other hand it seems to me that option 2 might make more sense logically. Also, I’m a bit scared that creation of new LVM VG group might be a bit hidden.

I would be very grateful for any feedback (especially from Visual Design Group). E.g. which option would you prefer.

Also, do you think we need another icon for LVM devices? At the moment we are using drive-harddisk but having some other icon for virtual devices might be nice.