Summary: | luks::mapperName sometimes picks incorrectly | ||
---|---|---|---|
Product: | [Applications] partitionmanager | Reporter: | kaguru |
Component: | general | Assignee: | Andrius Štikonas <andrius> |
Status: | RESOLVED FIXED | ||
Severity: | crash | ||
Priority: | NOR | ||
Version: | 3.0 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | https://commits.kde.org/kpmcore/b10577e1c7ba0c856c96c96a80187b977f88ef34 | Version Fixed In: | 3.1.0 |
Description
kaguru
2017-04-25 15:33:53 UTC
suggestedMapperName can't be used. If luks volume was opened during the boot or manually with some other name then it wouldn't work. We need to fix lsblk parsing then. I think I see from your comments what is happening but can you paste your lsblk output. And also lsblk --raw --noheadings --output name /dev/nvme0n1p2 This is the output of these commands after a failed luks partition creation via Calamares: $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 50.3M 1 loop /run/miso/sfs/livefs loop1 7:1 0 225.3M 1 loop /run/miso/sfs/mhwdfs loop2 7:2 0 541.9M 1 loop /run/miso/sfs/desktopfs loop3 7:3 0 373.4M 1 loop /run/miso/sfs/rootfs sda 8:0 1 29.3G 0 disk ├─sda1 8:1 1 1.3G 0 part /run/miso/bootmnt └─sda2 8:2 1 46M 0 part nvme0n1 259:0 0 238.5G 0 disk ├─nvme0n1p6 259:1 0 81.9G 0 part │ └─luks-4953c5dd-99b6-4b9f-9ef4-75a16ed6207d 254:0 0 81.9G 0 crypt ├─nvme0n1p1 259:7 0 500M 0 part ├─nvme0n1p2 259:8 0 128M 0 part ├─nvme0n1p3 259:10 0 47.4G 0 part ├─nvme0n1p4 259:11 0 48G 0 part ├─nvme0n1p5 259:12 0 48G 0 part ├─nvme0n1p7 259:16 0 450M 0 part ├─nvme0n1p8 259:17 0 11.1G 0 part └─nvme0n1p9 259:18 0 1G 0 part $ lsblk --raw --noheadings --output name /dev/nvme0n1p6 luks-4953c5dd-99b6-4b9f-9ef4-75a16ed6207d nvme0n1p6 $ lsblk --sort pkname --noheadings --output name /dev/nvme0n1p6 nvme0n1p6 luks-4953c5dd-99b6-4b9f-9ef4-75a16ed6207d Hmm, sorting by pkname doesn't seem to work on my system :(. LVM devices that have pkname dm-# jump in front... Need some other solution. We could output more details (lsblk -O) and awk for the parent… (In reply to kaguru from comment #4) > We could output more details (lsblk -O) and awk for the parent… Looks like somebody already found a solution here: https://github.com/cmorlok/kpmcore/commit/2bebc0d523069a9d1e110dd43a24243f38c41754 Can you test with it? Oh wow, I missed that completely. I can try, but I might need some assistance. My efforts so far to fix did not go very well. I tried a number of things (individually, not all at once): - I overrode lsblk with a function defined in rc.local, but it was ignored - I made a new lsblk bash executable further up in the $PATH (/usr/bin/local) - I renamed /usr/bin/lsblk and pointed my /usr/bin/local executable back at it - I installed kpmcore-git via yaourt based on my branch, and compiled manjaro/calamares with defaults - I compiled manjaro/calamares with a local checkout of kpmcore in the same git directory Through it all, I wasn't able to change the behavior of the installer. Are you at all familiar with AUR? If I installed kpmcore-git, and then partitionmanager-git (accepting all dependencies), would that take advantage of that new fix and be enough for me to attempt creation of a new luks-encrypted volume? Ah, and I didn't see it because it's on a fork. So I'll have to change the remote that kpmcore-git is cloning from too (which I had already done in an attempt to test my patch). (In reply to kaguru from comment #7) > Ah, and I didn't see it because it's on a fork. So I'll have to change the > remote that kpmcore-git is cloning from too (which I had already done in an > attempt to test my patch). Well, I guess that patch looks fine. I'll just pull into main repo. Yeah, I also didn't know about that fork. It is not nice when fixes are not sent upstream :(. I'm not really familiar with AUR but if you replace your libkpmcore.so file in /usr (which kpmcore-git from AUR should do) then the fix will be in. But recent kpmcore has some ABI incompatibilities compared to 3.0.3, so partitionmanager/calamares also need to be recompiled. Git commit b10577e1c7ba0c856c96c96a80187b977f88ef34 by Andrius Štikonas, on behalf of Christian Morlok. Committed on 25/04/2017 at 18:08. Pushed by stikonas into branch 'master'. Fix creation of encrypted volumes We can't rely on the order of lsblk. Check for the type=crypt instead. M +4 -5 src/fs/luks.cpp https://commits.kde.org/kpmcore/b10577e1c7ba0c856c96c96a80187b977f88ef34 I and others can confirm that this patch fixed the problem: https://github.com/calamares/calamares/issues/697 I could see a potential edge case where someone's creating a luks volume in a luks volume, in which case checking for the expected parent volume would be better, but for the non-hypothetical, things are in good shape. Any chance we could get a patch version bump, in hopes that we can get it into package managers sooner? (In reply to kaguru from comment #10) > I and others can confirm that this patch fixed the problem: > https://github.com/calamares/calamares/issues/697 > > I could see a potential edge case where someone's creating a luks volume in > a luks volume, in which case checking for the expected parent volume would > be better, but for the non-hypothetical, things are in good shape. > > Any chance we could get a patch version bump, in hopes that we can get it > into package managers sooner? Unlikely before June. I can try to do it then... luks inside luks is not supported even now. A lot of other luks code was not designed with this in mind. In any case luks inside luks doesn't make sense. Well, luks->lvm->luks is supported though, so will have to test it later. Well, that's why I said I wouldn't have time for release soon. Well, we still check expected parent. After all we supply deviceNode to lsblk. So I think it would work. |