Bugzilla – Bug 1048338
regression in btrfs subvolume handling during fresh install
Last modified: 2017-07-22 20:25: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
Created attachment 732094 [details] hwinfo.txt
Created attachment 732095 [details] install.inf
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.
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
Arvin or HuHa, any idea?
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.
Who needs rollback and snapshots? Just those who do need them... I just avoid the wasted space at the end of each individual partition.
Let's get an official statement. Jiri, is this a supported use-case (install into existing sub-volumes)?
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.
(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.
(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?
(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.
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.