Bug 959411

Created attachment 659591 [details]
screenshot

Sure Arvin can tell us the reason. Needinfoing him :-)

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.

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?

(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

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

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

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?

(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.
A lot happened and today you can use all filesystems directly without LVM for encrypted root filesystems. The btrfs developers even recommend it.
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.

The check for btrfs is here:

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

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?

The official SLES documentation even has direct mention of BTRFS on an Encrypted Root Partition

"IMPORTANT: Btrfs on an Encrypted Root Partition

The default partitioning setup suggests the root partition as Btrfs with /boot being a directory. If you need to have the root partition encrypted in this setup, make sure to use the GPT partition table type instead of the default MSDOS type. Otherwise the GRUB2 boot loader may not have enough space for the second stage loader. "

https://www.suse.com/documentation/sles-12/book_sle_deployment/data/sec_yast2_i_y2_part_expert.html 

Section 14.1.2

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/custom_part_lib.rb#L116

(In reply to Jiri Srain from comment #11)

> Arvin, can you, please, provide some background on this check?
> 
> https://github.com/yast/yast-storage/blob/master/src/include/partitioning/
> custom_part_lib.rb#L116

Because it is not a supported setup.

(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.

(In reply to Arvin Schnell from comment #12)
> (In reply to Jiri Srain from comment #11)
> 
> > Arvin, can you, please, provide some background on this check?
> > 
> > https://github.com/yast/yast-storage/blob/master/src/include/partitioning/
> > custom_part_lib.rb#L116
> 
> Because it is not a supported setup.

I used to think the same as you (that this wasnt supported), but we clearly have Thorsten, MgE and the Documentation telling us otherwise...

(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).

(In reply to Richard Brown from comment #14)

> > Because it is not a supported setup.
> 
> I used to think the same as you (that this wasnt supported), but we clearly
> have Thorsten, MgE and the Documentation telling us otherwise...

Then show us the fate request!

(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).

(In reply to Thorsten Kukuk from comment #17)
> (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).

"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."

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.

Removing NEEDINFO - cannot identify a question directed to me. Please feel free to restate the question and readd the NEEDINFO flag if this is a mistake.