Bug 1084213 - [storage-ng][*15 & TW affected] /home subvolume not created if user opts to not have a /home partition
[storage-ng][*15 & TW affected] /home subvolume not created if user opts to n...
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: YaST2
Current
Other Other
: P1 - Urgent : Critical (vote)
: ---
Assigned To: YaST Team
Jiri Srain
https://trello.com/c/MSBg5L2S
:
Depends on:
Blocks: 1084261
  Show dependency treegraph
 
Reported: 2018-03-06 21:19 UTC by Richard Brown
Modified: 2019-04-15 12:17 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
y2logs (60.70 KB, application/x-xz)
2018-03-06 21:19 UTC, Richard Brown
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Brown 2018-03-06 21:19:28 UTC
Created attachment 762888 [details]
y2logs

Steps to reproduce:

- Install any libstorage-ng OS on a blank disk
- Choose guided setup during partitioning
- Select Disk
- Leave LVM and Disk Encryption unticked (as default)
- On the settings for the Root Partition Screen - configure the following:
- UNTICK Propose Separate Home Partition
- Leave all the other boxes as default (File System type BTRFS, Snapshots enabled, Separate Swap enabled, Enlarge RAM for Suspend)

The resulting proposal has only 8 subvolume actions creating the following subvolumes

@
@/var
@/usr/local
@/tmp
@/srv
@/opt
@/boot/grub2/x86_64
@/boot/grub2/i386-pc

@/home is missing, this is unexpected and crates a system with a critical flaw.

There is the potential for serious data loss for any user who installs their system showing this behaviour.

That includes any fresh Tumbleweed installation from current snapshots, and potentially SLE-15 and Leap-15 assuming they are showing the same behaviour.

Any user using rollbacks on these systems will loose all data in /home written since their last snapshot

As we have no way of repairing subvolumes retroactively, any user who has installed any *SUSE OS that exhibits this behaviour will need to *RE-INSTALL* to recover from this bug.

It's essential that when using btrfs as the rootfs without /home as a separate partition, the @/home subvolume is created.

This is the purpose of the associated lines in the control.xml, which seem to be ignored at the moment:

https://github.com/yast/skelcd-control-openSUSE/blob/master/control/control.openSUSE.xml#L317-L319

y2logs attached

These logs are from an installation in topped immediately after proposal is presented; my other system struck by this bug is currently inaccessible, on account of it bring remote, only allowing ssh key authentication, and as it's ssh keys were held in /home, they were lost during a rollback.

(okurz, ccing you to this bug because I am concerned about the SLE-15 impact, can you or someone from QA take a look?)
Comment 1 Richard Brown 2018-03-07 08:40:52 UTC
Confirmed present on SLE 15 and Leap 15

SLE 15 bug filed - https://bugzilla.suse.com/show_bug.cgi?id=1084261
Comment 2 Richard Brown 2018-03-07 09:29:00 UTC
Confirmed alternative way of reproducing bug

- install any libstorage-ng OS on a disk too small for a seperate /home partition (eg. 8GB)
- the automatic default proposal will not propose a /home subvolume, when it absolutely must in this case
Comment 3 Steffen Winterfeldt 2018-03-07 09:41:28 UTC
Tracking in YaST scrum board
Comment 4 Lukas Ocilka 2018-03-07 12:51:52 UTC
*** Bug 1084261 has been marked as a duplicate of this bug. ***
Comment 7 Ancor Gonzalez Sosa 2018-03-08 17:35:27 UTC
I created this unit test that showcases the problem
https://github.com/yast/yast-storage-ng/pull/567

The dark side is that there is indeed a bug. The bright side is that having a testcase should make the fix relatively easy and should prevent it from reappearing.
Comment 8 Ancor Gonzalez Sosa 2018-03-08 17:53:11 UTC
(In reply to Ancor Gonzalez Sosa from comment #7)
> I created this unit test that showcases the problem
> https://github.com/yast/yast-storage-ng/pull/567

That pull request also contains the fix now, not only the testcase. I will verify the fix manually on top of a SLE15 RC1.
Comment 9 Ancor Gonzalez Sosa 2018-03-09 11:19:44 UTC
Fixed in yast2-storage-ng >= 4.0.129

See submit request https://build.suse.de/request/show/157585
Comment 10 Ancor Gonzalez Sosa 2018-03-09 11:21:06 UTC
(In reply to Ancor Gonzalez Sosa from comment #9)
> Fixed in yast2-storage-ng >= 4.0.129
> 
> See submit request https://build.suse.de/request/show/157585

Sorry, I meant submit request https://build.opensuse.org/request/show/584810