http://bugzilla.suse.com/show_bug.cgi?id=959411 http://bugzilla.suse.com/show_bug.cgi?id=959411#c1 --- Comment #1 from Richard Brown --- Created attachment 659591 --> http://bugzilla.suse.com/attachment.cgi?id=659591&action=edit screenshot -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=959411 http://bugzilla.suse.com/show_bug.cgi?id=959411#c3 Arvin Schnell changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FEATURE Flags|needinfo?(aschnell@suse.com | |) | --- Comment #3 from Arvin Schnell --- openSUSE does not support an encrypted root filesystem (unless the root filesystem is in a encrypted LVM volume group). Feel free to make a feature request. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=959411 http://bugzilla.suse.com/show_bug.cgi?id=959411#c5 Matthias Eckermann changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mge@suse.com) | --- Comment #5 from Matthias Eckermann --- (In reply to Richard Brown from comment #4)

Based on comversations with MgE and Thorsten I was under the distinct impression that thia feature was already implemented in openSUSE

So reopening and NEEDINFOing them in the hope they can clear this up

Gentleman, is there a reason this is missing from openSUSE - its obviously a technology of great importance to SLE, shouldn't the distributions have parity in this area?

There is neither reason nor intent to not have this implemented in openSUSE and be used by the community. Rather I think that we may just have a timing issue in implementing this also in the openSUSE codebase. We should do this ASAP. TIA - MgE -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=959411 http://bugzilla.suse.com/show_bug.cgi?id=959411#c7 --- Comment #7 from Jiri Srain --- I can remember the discussion years ago; when we implemented encryption via YaST, we clrealy limited it to LVM volumes, since at that point of time it met the requirements (and there was just one request from the openSUSE community, which sounded rather arrogant to me, AFAIR) I'm not aware of having implemented encryption support for anything else in the YaST partitioner. Therefore, I find the approach to handle this via Fate as reasonable; it is not about finding a bug in previous implementation, but about implementing encryption for non-LVM set-up from scratch. Richard, can you add this to Fate instead of handling it in bzilla? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=959411 http://bugzilla.suse.com/show_bug.cgi?id=959411#c9 --- Comment #9 from Jiri Srain --- The check for btrfs is here: https://github.com/yast/yast-storage/blob/master/src/include/partitioning/ep... Git pointed me to this bug when setting up encrypted btrfs was failing: https://bugzilla.suse.com/show_bug.cgi?id=842783 2013-09-27 12:08:35 <1> dhcp53.suse.cz(3019) [libstorage] Storage.cc(showInfoCb):6623 INSTALL INFO info:Setting up encrypted dm device on /dev/sda6 2013-09-27 12:08:35 <1> dhcp53.suse.cz(3019) [libstorage] Storage.cc(showInfoCb):6624 quiet:false 2013-09-27 12:08:35 <1> dhcp53.suse.cz(3019) [Ruby] modules/StorageClients.rb:85 Current action: 6, total stage progress: 30 2013-09-27 12:08:35 <1> dhcp53.suse.cz(3019) [libstorage] Dm.cc(devToTable):546 dev:/dev/sda6 ret:sda6 2013-09-27 12:08:35 <1> dhcp53.suse.cz(3019) [libstorage] SystemCmd.cc(SystemCmd):46 constructor SystemCmd:"/sbin/dmsetup table 'sda6'" 2013-09-27 12:08:35 <1> dhcp53.suse.cz(3019) [libstorage] SystemCmd.cc(execute):90 SystemCmd Executing:"/sbin/dmsetup table 'sda6'" 2013-09-27 12:08:35 <1> dhcp53.suse.cz(3019) [libstorage] SystemCmd.cc(addLine):592 Adding Line 1 "device-mapper: table ioctl on sda6 failed: No such device or address" 2013-09-27 12:08:35 <1> dhcp53.suse.cz(3019) [libstorage] SystemCmd.cc(getUntilEOF):558 pid:4449 added lines:1 stderr:true 2013-09-27 12:08:35 <1> dhcp53.suse.cz(3019) [libstorage] SystemCmd.cc(addLine):592 Adding Line 2 "Command failed" 2013-09-27 12:08:35 <1> dhcp53.suse.cz(3019) [libstorage] SystemCmd.cc(getUntilEOF):558 pid:4449 added lines:1 stderr:true 2013-09-27 12:08:35 <1> dhcp53.suse.cz(3019) [libstorage] SystemCmd.cc(doExecute):279 stopwatch 0.023274s for "/sbin/dmsetup table 'sda6'" Arvin, is there any particular reason why this was failing for btrfs and not for other filesystems? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=959411 http://bugzilla.suse.com/show_bug.cgi?id=959411#c11 Jiri Srain changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(aschnell@suse.com | |) --- Comment #11 from Jiri Srain --- We clearly have a mismatch between the code and docu. I tried to create an ext2 (or xfs) partition set for encryption and mount it as root. The partitioner does not allow me to mount such partition as any of /, /usr, /boot and /var, recommending to use a non-loopback filesystem or change mount point. I tested this with SP1. In other words, we need quite more to allow encrypted root directly on btrfs. Arvin, can you, please, provide some background on this check? https://github.com/yast/yast-storage/blob/master/src/include/partitioning/cu... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=959411 http://bugzilla.suse.com/show_bug.cgi?id=959411#c13 Arvin Schnell changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(aschnell@suse.com | |) | --- Comment #13 from Arvin Schnell --- (In reply to Jiri Srain from comment #9)

The check for btrfs is here:

https://github.com/yast/yast-storage/blob/master/src/include/partitioning/ep... dialogs.rb#L193

Arvin, is there any particular reason why this was failing for btrfs and not for other filesystems?

See bug #908073. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=959411 http://bugzilla.suse.com/show_bug.cgi?id=959411#c15 --- Comment #15 from Arvin Schnell --- (In reply to Thorsten Kukuk from comment #8)

(In reply to Arvin Schnell from comment #6)

...

Fate #305633 is clear about the setup being *not* supported:

"[...] LVM is necessary for using encrypted root with YaST installer."

That FATE is 7 years old. btrfs didn't even exist at that point in time.

Product management decides what the YaST team has to implement so the reasoning that a technology is old and thus has to be supported is invalid from the view of the YaST team.

YaST2 storage allows it for all filesystems except btrfs, at least for SLES12, which is a bug. btrfs should be supported, too, there is no technical reasons not to do so.

No, not for the root filesystem (which this "bug report" is about). -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=959411 http://bugzilla.suse.com/show_bug.cgi?id=959411#c17 --- Comment #17 from Thorsten Kukuk --- (In reply to Arvin Schnell from comment #13)

(In reply to Jiri Srain from comment #9)

...

Arvin, is there any particular reason why this was failing for btrfs and not for other filesystems?

See bug #908073.

Beside that that bug is "encrypted home on encrypted LVM", but we speak about "encrypted root fs without LVM", there was never done an analysis in this bug why it does not work and what needs to be done to get it working (if it was done, the outcome was not written there). -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=959411 http://bugzilla.suse.com/show_bug.cgi?id=959411#c19 Arvin Schnell changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FEATURE --- Comment #19 from Arvin Schnell --- Thorsten has created fate #320182 so I suppose we can close this bug as a feature request. Please for the future do research before reporting and esp. reopening bugs. -- You are receiving this mail because: You are on the CC list for the bug.