Bug 1077866 - installer uses old btrfs subvolume structure when not using the suggested partitioning scheme
installer uses old btrfs subvolume structure when not using the suggested par...
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Installation
x86-64 Other
: P5 - None : Normal (vote)
: ---
Assigned To: YaST Team
Jiri Srain
Depends on:
  Show dependency treegraph
Reported: 2018-01-28 09:49 UTC by John Janus
Modified: 2019-04-15 12:14 UTC (History)
6 users (show)

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

hopefully the installation log (401.67 KB, application/gzip)
2018-02-23 16:17 UTC, John Janus

Note You need to log in before you can comment on or make changes to this bug.
Description John Janus 2018-01-28 09:49:22 UTC
I recently reinstalled Tumbleweed, partly because i wanted the @ subvolume.
As I wanted to use my old /home partition, I tried to make a new partition scheme not using the suggestion. This led to the old subvolume structure (multiple subvolumes under /var, no @ subvolume).

I did not find any possibility to get the new structure within the installer except deleting the old / btrfs in the rescue system, reboot the installer, and change the suggested partitioning scheme.

The subvolume structure should be the same, regardless, whether the suggestion is used or changed or a new scheme is created by the installer
Comment 1 Josef Reidinger 2018-01-29 13:02:58 UTC
John - can you attach installation logs from non-working case? It will help us to see what exactly is going.
Comment 2 Peter Sütterlin 2018-02-08 19:18:44 UTC
I just faced the same issue:
I wanted a / partition larger than the default 40GB.  Unfortunately I found no way to specify this before the suggested setup is created :(

So I started a configuration from scratch, added a 80GiB / partition with btrfs, and when you there go for the subvolume management for that partition you are presented the old layout with 10+ subvolumes within /var.

I had to start with the proposal, delete everything except the root partition, change its size, and the manually create the other partitions again (HOME,SWAP,EFI) 

No installation logs, obviously, as I never accepted the 'wrong' configuration...
Comment 3 John Janus 2018-02-23 16:17:52 UTC
Created attachment 761504 [details]
hopefully the installation log

If this is not the correct log or s/th is missing, I can add it, as i created a minimal example installation in vbox.
Comment 4 John Janus 2018-02-23 16:26:28 UTC
I tested the installer a bit and it seems the wrong layout is used when using the existing partition scheme and creating a new btrfs partition for / there.
It is not relevant whether there was any partition at all.
To reproduce, just start the installer with an empty disk, choose to edit the existing scheme and create a btrfs / partition for OS. The installer shows the old layout with multiple subvolumes under /var and no @ subvolume.

The installed system reflects this.
Comment 5 John Janus 2018-02-23 16:29:40 UTC
The snapshot used for testing was 20180120. if necessary, I can try to reproduce with a current snapshot after the weekend
Comment 6 Stefan Hundhammer 2018-02-27 13:02:20 UTC
Steffen, you just worked on that part. Any input from your side?

Is it a UI problem in the expert partitioner not using the correct subvolume list? The problem descriptions might indicate that.

Or is the problem that users want to reuse their existing Btrfs filesystems, but expect the new subvolumes structure to be used regardless? In that case, can we realistically do that? Or would we have to move vast amounts of files around from one (old) subvolume to the other (fitting into the new subvolume structure)?
Comment 7 John Janus 2018-02-27 13:22:14 UTC
I noticed the Problem when reinstalling on my main workstation. I tried to use my existing partitioning scheme with a newly formatted btrfs /.
As that did not show the expected subvolume scheme, I deleted the root partition manually, let the setup suggest a scheme using the now free space and removed the unnecessary partitions and set a mountpoint for my /home and added the swap as swap, thus not getting a log to describe the problem

As Josef asked for a log, I tried a minimal example in a VM and installed the OS.
This time i got the wrong btrfs subvolume structure in the installed system. I verified that it is actually used in the installed system.

I did not try to reuse my old /.
Comment 8 Steffen Winterfeldt 2018-02-27 13:22:40 UTC
Just tested and I can confirm that the stuff from the SubvolSpecification class sneaks in if you create a btrfs filesystem from scratch (not via proposal code).

I guess the definitions from control.xml should be looked up (e.g. via matching the mount point).
Comment 9 Stefan Hundhammer 2018-02-28 13:36:12 UTC
Moved to our Trello task queue:

Comment 10 Imobach Gonzalez Sosa 2018-03-14 08:50:19 UTC
yast2-storage-ng 4.0.131 fixes this issue.

Comment 11 Christian Boltz 2018-04-02 15:27:08 UTC
Things indeed improved, but YaST doesn't prepend "@/" to the subvolumes when using a custom partitioning scheme. I just opened bug 1087763 for that.