Bug 1077866

Summary:	installer uses old btrfs subvolume structure when not using the suggested partitioning scheme
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	John Janus <suseacc>
Component:	Installation	Assignee:	YaST Team <yast-internal>
Status:	RESOLVED FIXED	QA Contact:	Jiri Srain <jsrain>
Severity:	Normal
Priority:	P5 - None	CC:	igonzalezsosa, jreidinger, P.Suetterlin, snwint, suse-beta, suseacc
Version:	Current
Target Milestone:	---
Hardware:	x86-64
OS:	Other
URL:	https://trello.com/c/GKJYYDQd/
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	hopefully the installation log

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:

  https://trello.com/c/GKJYYDQd/

Comment 10 Imobach Gonzalez Sosa 2018-03-14 08:50:19 UTC

yast2-storage-ng 4.0.131 fixes this issue.

Thanks!

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.