|
Bugzilla – Full Text Bug Listing |
| Summary: | Creation of encrypted LVM during installation is impossible when Btrfs is selected | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Vojtech Zeisek <Vojtech.Zeisek> |
| Component: | Installation | Assignee: | YaST Team <yast-internal> |
| Status: | RESOLVED WONTFIX | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | aschnell, bwiedemann, fcrozat, forgotten_03jo5VnZBO, hannsj_uhl, lpechacek, shundhammer |
| Version: | 13.2 | ||
| Target Milestone: | --- | ||
| Hardware: | 64bit | ||
| OS: | openSUSE 13.2 | ||
| URL: | https://trello.com/c/uhgBhZ6v/ | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Bug Depends on: | |||
| Bug Blocks: | 1026078 | ||
| Attachments: |
Screenshot documenting the bug
y2log from "cryptsetup error" |
||
Indeed, the en- and disabling of the checkbox is broken. The same is true for the "Subvolumes" button. I added a card to the YaST trello task board so that the issue is prioritised with the other tasks. The patch was indeed trivial: https://github.com/shundhammer/yast-storage/tree/huha-allow-crypted-btrfs But since Btrfs was explicitly excluded, I fear there might be a reason. I couldn't think of any, though. I will test a few common scenarios. I enabled that checkbox so you can now select "[ ] encrypt" for Btrfs filesystems, too; Btrfs was explicitly excluded.
Now when I try to select that for a root filesystem (no matter if it's Btrfs, XFS, ext2/3/4), I get an error popup (in the expert partitioner, before any changes are applied) that certain mount points cannot be encrypted (on that level - encryption on the LVM level works): "/", "/usr", "/var".
When I try to encrypt a Btrfs /home partition (on top of LVM), I get an error popup when I start the installation:
VOLUME_CRYPTSETUP_FAILED
System error code was: -3034
So maybe there really was a good reason not to allow encryption of a Btrfs partition.
Will continue to investigate.
Created attachment 648853 [details]
y2log from "cryptsetup error"
y2log from failed attempt to create an encrypted Btrfs /home on top of encrypted LVM
The failing call is this: SystemCmd.cc(doExecute):336 stopwatch 0.101613s for "/sbin/cryptsetup -q --key-file /tmp/libstorage-RHgtku/pwdf luksOpen '/dev/lvm_sys/lvm_home' 'cr_lvm_home'" SystemCmd.cc(doExecute):356 system() Returns:1 SystemCmd.cc(logOutput):674 stderr:Oops, secure memory pool already initialized SystemCmd.cc(logOutput):674 stderr:Device /dev/lvm_sys/lvm_home is not a valid LUKS device. That "Oops, secure memory pool already initialized" message seems to be harmless; it appears in previous cryptsetup calls, too, that succeeded. According to the logs the luksFormat command before luksOpen is missing. (In reply to Stefan Hundhammer from comment #2) > But since Btrfs was explicitly excluded, I fear there might be a reason. I > couldn't think of any, though. I will test a few common scenarios. But if You select "Do not format partition" as on the screenshot, it shouldn't matter which FS You selected in inactive drop-down menu above (this menu has no effect now) - the partition will be only LVM container, not formatted partition. If the inactive menu is influencing creation of LVM, I'd be very aware of some deeper and more serious bug... The missing "cryptsetup luksFormat" command should be called from Volume::getCryptsetupCmd() in libstorage/Volume.cc. But it looks like it's called with the wrong arguments in this case: 'format' is set to 'false'. 2015-09-24 10:33:02 <1> 192.168.100.234(6955) [libstorage] Volume.cc(doCryptsetup):2505 format:false tmpc:false pwempty:false ro:true enc!=NONE:true ... ... 2015-09-24 10:33:02 <1> 192.168.100.234(6955) [libstorage] Volume.cc(getCryptsetupCmd):2012 enctype:luks dmdev:/dev/mapper/cr_lvm_home mount: format:false pwempty:false 2015-09-24 10:33:02 <1> 192.168.100.234(6955) [libstorage] Volume.cc(getCryptsetupCmd):2098 cmd:/sbin/cryptsetup -q --key-file /tmp/libstorage-RHgtku/pwdf luksOpen '/dev/lvm_sys/lvm_home' 'cr_lvm_home' Before that doCryptsetup() call, we have this: 2015-09-23 11:51:38 <1> 192.168.100.234(6955) [libstorage] Storage.cc(setBtrfsUsedBy):545 devs:</dev/sda2> to uuid:44633d6e-f583-418a-87f3-037f7ceeb56e 2015-09-23 11:51:38 <1> 192.168.100.234(6955) [libstorage] Volume.cc(setUsedByUuid):1270 device:/dev/sda2 to uuid:44633d6e-f583-418a-87f3-037f7ceeb56e Don't get confused with the time stamp - the clock is set later; this is actually BEFORE this: 2015-09-24 10:33:02 <1> 192.168.100.234(6955) [libstorage] Volume.cc(doCryptsetup):2505 format:false tmpc:false pwempty:false ro:true enc!=NONE:true Volume::setUsedByUuid() sets the 'format' member variable to 'false'. The current conclusion is that this is not easily possible with the current architecture of libstorage: This would be considerable work while introducing great risk of regression for other scenarios. So it turns out that yes, there was a good reason to disable this for Btrfs; it doesn't work in the back-end. On the bright side, we are pushing hard to convince the relevant stakeholders that we need to refactor libstorage; there is even an early prototype. But it will take quite some time until it can completely replace the current one. So it looks like we'll have to wait for that new libstorage to get this bug fixed. (In reply to Stefan Hundhammer from comment #10) > The current conclusion is that this is not easily possible with the current > architecture of libstorage: This would be considerable work while > introducing great risk of regression for other scenarios. > > So it turns out that yes, there was a good reason to disable this for Btrfs; > it doesn't work in the back-end. > > On the bright side, we are pushing hard to convince the relevant > stakeholders that we need to refactor libstorage; there is even an early > prototype. But it will take quite some time until it can completely replace > the current one. > > So it looks like we'll have to wait for that new libstorage to get this bug > fixed. Would it be possible to enable encryption on top of btrfs but only if lvm is not enabled ? (In reply to Frederic Crozat from comment #13) > Would it be possible to enable encryption on top of btrfs but only if lvm is > not enabled ? AFAICS this would take the same code path here, triggering the same problem. But I admit I didn't explicitly test it. This version of openSUSE changed to end-of-life (EOL [1]) status. As such it is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of openSUSE, or consider the bug still valid, please feel free to reopen this bug against that version, or open a new ticket. Thank you for reporting this bug and we are sorry it could not be fixed during the lifetime of the release. [1] https://en.opensuse.org/Lifetime |
Created attachment 615682 [details] Screenshot documenting the bug I use to use disk partitions as follows: 1) boot (+ efi partition if needed) 2) encrypted LVM containing a) root b) swap When installing, I click to expert partitioning and create those partitions manually. No problem. But 13.2 has a small bug. I create boot partition. Then I wish to make encrypted LVM. I add new Raw volume (unformatted). From Formatting Options the second possibility (Do not format...) is checked and LVM selected from drop-down menu. But check-box to encrypt the device is inactive. So the encryption is impossible. I have to click on "Format partition", select Ext4 instead of Btrfs (preselected default) and then again "Do not format...". By this magic operation the encryption check-box is activated, I can check it and continue as I'm used to. Other steps are OK. In all other steps one can choose default value or whatever is wished. The screenshot is from VirtualBox, but it, of course, happens in same way on real HW.