Bugzilla – Bug 1077866
installer uses old btrfs subvolume structure when not using the suggested partitioning scheme
Last modified: 2019-04-15 12:14:11 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
John - can you attach installation logs from non-working case? It will help us to see what exactly is going.
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...
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.
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.
The snapshot used for testing was 20180120. if necessary, I can try to reproduce with a current snapshot after the weekend
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)?
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 /.
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).
Moved to our Trello task queue:
yast2-storage-ng 4.0.131 fixes this issue.
Things indeed improved, but YaST doesn't prepend "@/" to the subvolumes when using a custom partitioning scheme. I just opened bug 1087763 for that.