https://bugs.kde.org/show_bug.cgi?id=379205
Bug ID: 379205
Summary: luks::mapperName sometimes picks incorrectly
Product: partitionmanager
Version: 3.0
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
I believe that luks encryption is broken for all NVMe devices, as of
https://github.com/KDE/kpmcore/commit/3bfb0b4b5b6ee4504944433fe3208707f37df82e,
so affecting all versions past 2.2.0
I'm using kpmcore via Calameres 3.1. When I attempt to create a luks-encrypted
ext4 or btrfs partition, the process is consistently failing when it tries to
format the inner filesystem.
> The Installer failed to create file system on partition /dev/nvme0n1p2
> Command: cryptsetup -s 512 --batch-mode ..force-password luksFormat
> /dev/nvme0n1p2
> Command: cryptsetup open /dev/nvme0n1p2 luks-............................
> Command: mkfs.ext4 -qf /dev/mapper/nvme0n1p2
I believe I've determined root cause:
Notice that the mkfs command is trying to use the name of the original
partition, not the newly opened luks container. I believe that this is because
of the way that mapperName() parses lsblk output. The volumes associated with
the specified partition are listed, and the function assumes that the encrypted
mapper volume will be the second in the list. The default sort for lsblk is
based on device numbers, and unlike hd and sd devices, NVMes have a higher
major device number (259) than the local device number associated with the
logical volume (254). This means that when mapperName() trims the first value,
it's throwing away the name we need, and then inappropriately setting
/dev/mapper/{original_partition}, a path that doesn't even exist.
I believe that sorting the lsblk output on pkname should solve the problem for
me and others
(https://github.com/billwanjohi/kpmcore/commit/9abaa89bdd6584e9942e00bfef6f39feeb7b9e1a),
but I haven't been able to confirm due to unfamiliarity with the build process.
Even better might be to ditch mapperName() altogether, and just reuse the
suggestedMapperName() function that's used for the cryptsetup open step.
--
You are receiving this mail because:
You are watching all bug changes.
