Bug 1048338 - regression in btrfs subvolume handling during fresh install
regression in btrfs subvolume handling during fresh install
Status: NEW
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: YaST2
Current
x86-64 Linux
: P5 - None : Normal (vote)
: ---
Assigned To: YaST community YaST community
Jiri Srain
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-12 11:57 UTC by Olaf Hering
Modified: 2017-07-22 20:25 UTC (History)
4 users (show)

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


Attachments
y2log-91wTWX.tar.xz (118.96 KB, application/x-xz)
2017-07-12 11:57 UTC, Olaf Hering
Details
hwinfo.txt (977.71 KB, text/plain)
2017-07-12 11:58 UTC, Olaf Hering
Details
install.inf (788 bytes, text/plain)
2017-07-12 11:58 UTC, Olaf Hering
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Olaf Hering 2017-07-12 11:57:25 UTC
Created attachment 732093 [details]
y2log-91wTWX.tar.xz

With current Tumbleweed it is not possible anymore to install into an existing btrfs subvolume. yast tries to mount /mnt${subvolname}, which does not exist.

I'm using btrfs to share the diskspace between several root filesystems. Each one is in its own independend subvolume. This worked fine last year and a few weeks ago, but fails now.

Since yast does not need to format the filesystem, and since yast does/did not allow to select an arbitrary subvolume as entry point I had to set the desired subvolume as default to get it going.

The btrfs has subvolumes like /tw_kde,/tw_xfce,etc.. as an entry point into the filesystem. Each rootfs is booted with rootflags=subvolid=$subvolname.

See attached logs for the failure.

the install is booted with this cmdline, in case it matters:
quiet panic=9 sysrq_always_enabled start_shell netsetup=dhcp install=http://download.opensuse.org/tumbleweed/repo/oss/ ssh=0 sshpassword=root nosshkey vnc=0 vncpassword=password net.ifnames=0 netdevice=eth0
Comment 1 Olaf Hering 2017-07-12 11:58:09 UTC
Created attachment 732094 [details]
hwinfo.txt
Comment 2 Olaf Hering 2017-07-12 11:58:49 UTC
Created attachment 732095 [details]
install.inf
Comment 3 Olaf Hering 2017-07-12 12:01:29 UTC
Also, I can not just delete the unused subvolumes from the list behind the "Subvolmes" button because yast would apparently attempt to wipe them entirely from the btrfs. That might mean dataloss.
Comment 4 Olaf Hering 2017-07-13 10:58:09 UTC
It happens to work with 42.3. But in instsys I see /mnt2.3 and /mntw_xfce directories. Logs for 42.3 are in bug#1048471
Comment 5 Steffen Winterfeldt 2017-07-13 13:38:25 UTC
Arvin or HuHa, any idea?
Comment 6 Arvin Schnell 2017-07-14 09:43:54 UTC
No, I don't know what changed in the last few weeks that could cause a change.

In general I consider the use-case as invalid. Using a single btrfs for several
systems will definitely break with rollback.
Comment 7 Olaf Hering 2017-07-14 09:50:48 UTC
Who needs rollback and snapshots? Just those who do need them...
I just avoid the wasted space at the end of each individual partition.
Comment 8 Steffen Winterfeldt 2017-07-14 10:02:11 UTC
Let's get an official statement.

Jiri, is this a supported use-case (install into existing sub-volumes)?
Comment 9 Jiri Srain 2017-07-14 10:08:40 UTC
I don't think that we have ever supported sharing a root filesystem across multiple systems, it may have worked just by coincidence. We do not do that even for uEFI partition, which - to some extent - is designed to allow that.
Comment 10 Olaf Hering 2017-07-14 10:18:02 UTC
(In reply to Jiri Srain from comment #9)
> I don't think that we have ever supported sharing a root filesystem across
> multiple systems, it may have worked just by coincidence. We do not do that
> even for uEFI partition, which - to some extent - is designed to allow that.

This is not about multiple systems on a single filesystem. This can not be easily done without chroot, even then it may not work...
The difference with btrfs is that it allows many entry points into the filesystem (subvol=), while others have just a single entry point.
Comment 11 Arvin Schnell 2017-07-14 10:30:53 UTC
(In reply to Olaf Hering from comment #10)
> (In reply to Jiri Srain from comment #9)
> > I don't think that we have ever supported sharing a root filesystem across
> > multiple systems, it may have worked just by coincidence. We do not do that
> > even for uEFI partition, which - to some extent - is designed to allow that.
> 
> This is not about multiple systems on a single filesystem.

Not?

How am I supposed to understand your initial comment then?

> The btrfs has subvolumes like /tw_kde,/tw_xfce,etc.. as an entry point into the > filesystem. Each rootfs is booted with rootflags=subvolid=$subvolname.

So several rootfs does not imply several systems?
Comment 12 Olaf Hering 2017-07-14 10:35:42 UTC
(In reply to Arvin Schnell from comment #11)
> > This is not about multiple systems on a single filesystem.
> Not?

Not in the sense Jiri probably meant it. ext4|xfs:/{42.3,42.2} would be tricky. But with btrfs this works just fine because each subvol is appears as the root of the filesystem. I'm using this since more than a year now on two systems. Just the third one, which was about to be reinstalled, fails now in TW.
Comment 13 Steffen Winterfeldt 2017-07-14 11:25:04 UTC
Let's say it's not a core functionality we support but as it seemed to work in the past maybe someone comes up with a patch.