-
Notifications
You must be signed in to change notification settings - Fork 152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
btrfs subvolume handling inconsistency #2316
Comments
We should not assume SUSE-style btrfs hierarchies. Does adding |
Hmm, I think you are right. Looking at def setup(self, name=None):
"""
Setup btrfs volume management
In case of btrfs a toplevel(@) subvolume is created and marked
as default volume. ...
"""
...
root_volume = self.mountpoint + '/@' So far there is no config option to influence this. I think I remember at the time of the implementation for the volume layout that this was a recommendation from the btrfs people and not so much a SUSE style hierarchy. In any case to fix this without regressions we would need a new attribute |
It doesn't:
|
per conversation on matrix let's add a new attribute saying <type ... btrfs_create_toplevel_subvolume="true|false" .../> with the default set to |
I'm going to work on this once I find the time. I was thinking about the suggestion from @iammattcoleman to define the toplevel volume explicitly. As we are using <systemdisk name="@">
<volume name="home"/>
</systemdisk> leading to @/home or <systemdisk name="/">
<volume name="home"/>
</systemdisk> leading to /home if not specified we have to keep the default to avoid regressions though @Conan-Kudo @iammattcoleman Thoughts ? |
Isn't |
I'm not a btrfs user, actually, so I'm approaching this strictly from the perspective of wanting approachable and versatile XML and being a little concerned about having the What about adding an optional Then, @davide125's example in this issue's problem description could remain as:
...and produce the two top-level volumes that they want. Adding a top-level volume named
This would allow us to represent any nested hierarchy without altering the schema to allow the |
That would work, and would allow representing the infinite hierarchy potential in Btrfs properly. |
no, the label of the volume is set by <type ... rootfs_label="value"/> The |
However, I like @iammattcoleman suggestion with the new |
In addition for naming the root volume we have added support for that to LVM in a124d82 The information used here is only used in LVM. I suggest in a first simple change we get rid of the fixed <volume name="@root=@"/> |
As specifying a toplevel volume usually means the volumes are below that volume I suggest to reverse the <systemdisk>
<volume name="@root=@"/>
<volume name="home" reparent="/"/>
<volume name="root"/>
<volume name="usr/local"/>
</systemdisk> resulting in:
How about that ? |
When bcachefs gets merged, then the design @iammattcoleman proposed will work for that too. So it'll be generic to all but LVM, really. |
The problem with reversing the logic is that it doesn't logically make sense when you have no singular top-level subvolume. Basically the design that we want in Fedora is that we have two separate hierarchies: one for system data ( The resulting fstab in Fedora looks something like this:
|
I'm fine with the design from @iammattcoleman I just think you have to repeat yourself a hundred times with |
ok got it |
We could just as easily also include a flag to create a top level, so that |
In a volume setup the special volume declaration <volume name="@root=identifier"/> was only evaluated for the LVM volume manager. In case of btrfs a hardcoded root volume name '@' was used. This commit allows to specify a custom name for the root volume for btrfs as well and also allows to specify that there should be no such root volume. Example: <volume name="@root=@"/> Name the root volume '@'. If not specified this stays as the default to stay compatible <volume name="@root=/"/> Indicate no root volume is wanted. All subvolumes resides below root (/) <volume name="@root=foo"/> Name the root volume 'foo' This is related to Issue #2316 and a first patch to address the requested changes
In a volume setup the special volume declaration <volume name="@root=identifier"/> was only evaluated for the LVM volume manager. In case of btrfs a hardcoded root volume name '@' was used. This commit allows to specify a custom name for the root volume for btrfs as well and also allows to specify that there should be no such root volume. Example: <volume name="@root=@"/> Name the root volume '@'. If not specified this stays as the default to stay compatible <volume name="@root=/"/> Indicate no root volume is wanted. All subvolumes resides below root (/) <volume name="@root=foo"/> Name the root volume 'foo' This is related to Issue #2316 and a first patch to address the requested changes
@Conan-Kudo Can you give me the btrfs commands that produced you this ? Thanks |
Here's an example implementation: https://pagure.io/appliance-tools/blob/main/f/appcreate/partitionedfs.py#_316-324 |
Basically, it's:
|
In a volume setup the special volume declaration <volume name="@root=identifier"/> was only evaluated for the LVM volume manager. In case of btrfs a hardcoded root volume name '@' was used. This commit allows to specify a custom name for the root volume for btrfs as well and also allows to specify that there should be no such root volume. Example: <volume name="@root=@"/> Name the root volume '@'. If not specified this stays as the default to stay compatible <volume name="@root=/"/> Indicate no root volume is wanted. All subvolumes resides below root (/) <volume name="@root=foo"/> Name the root volume 'foo' This is related to Issue #2316 and a first patch to address the requested changes
In a volume setup the special volume declaration <volume name="@root=identifier"/> was only evaluated for the LVM volume manager. In case of btrfs a hardcoded root volume name '@' was used. This commit allows to specify a custom name for the root volume for btrfs as well and also allows to specify that there should be no such root volume. Example: <volume name="@root=@"/> Name the root volume '@'. If not specified this stays as the default to stay compatible <volume name="@root=/"/> Indicate no root volume is wanted. All subvolumes resides below root (/) <volume name="@root=foo"/> Name the root volume 'foo' This is related to Issue #2316 and a first patch to address the requested changes
I just had a chance to really take a look at #2324. Since I'm not a btrfs user and haven't yet used LVM with Kiwi, I had to refamiliarize myself with that part of the image description syntax. My main objection is that the syntax is confusing and involves magic values (and a packed variant involving the magic value and some extra metadata) that alter Kiwi's behavior in ways that aren't made clear in the XML description. However, I hadn't remembered that the I'd prefer to see that special handling of
...could be slightly more verbosely written without a packed, magic
Taking this approach would result in XML that clearly describes the end result and doesn't require any special understanding of Kiwi's internals. @davide125's example in this issue's problem description would become...
|
The current problem is maintaining backwards compatibility with existing descriptions. We should be able to handle this by doing the following:
We do not need any special magic names to process, and we don't need to make assumptions about how volume structures will work. This will also allow us to be prepared for bcachefs once that lands, too. |
Allow to explicitly select if a toplevel subvolume should be created or not. To avoid a behavior change, kiwi will create a toplevel based btrfs structure if this attribute is not specified. However, a deprecation message to inform about future behavior change will be printed. This is related to Issue #2316
yes
done as commit to the open PR, now
we will do this in a new PR
done, I hope the text makes sense. I don't think that we will be removing the new attribute in the future as it can stay without conflicts to the |
It's true it could be expressed better that way but it would again be a backward compatibility issue. The special |
For the btrfs volume management, allow to put a volume into a specific parent volume. If not specified the volume is below the default volume This Fixes #2316
For the btrfs volume management, allow to put a volume into a specific parent volume. If not specified the volume is below the default volume This Fixes #2316
For the btrfs volume management, allow to put a volume into a specific parent volume. If not specified the volume is below the default volume This Fixes #2316
For the btrfs volume management, allow to put a volume into a specific parent volume. If not specified the volume is below the default volume This Fixes #2316
For the btrfs volume management, allow to put a volume into a specific parent volume. If not specified the volume is below the default volume This Fixes #2316
For the btrfs volume management, allow to put a volume into a specific parent volume. If not specified the volume is below the default volume This Fixes #2316
In a volume setup the special volume declaration <volume name="@root=identifier"/> was only evaluated for the LVM volume manager. In case of btrfs a hardcoded root volume name '@' was used. This commit allows to specify a custom name for the root volume for btrfs as well and also allows to specify that there should be no such root volume. Example: <volume name="@root=@"/> Name the root volume '@'. If not specified this stays as the default to stay compatible <volume name="@root=/"/> Indicate no root volume is wanted. All subvolumes resides below root (/) <volume name="@root=foo"/> Name the root volume 'foo' This is related to Issue #2316 and a first patch to address the requested changes
Allow to explicitly select if a toplevel subvolume should be created or not. To avoid a behavior change, kiwi will create a toplevel based btrfs structure if this attribute is not specified. However, a deprecation message to inform about future behavior change will be printed. This is related to Issue #2316
For the btrfs volume management, allow to put a volume into a specific parent volume. If not specified the volume is below the default volume This Fixes #2316
In a volume setup the special volume declaration <volume name="@root=identifier"/> was only evaluated for the LVM volume manager. In case of btrfs a hardcoded root volume name '@' was used. This commit allows to specify a custom name for the root volume for btrfs as well and also allows to specify that there should be no such root volume. Example: <volume name="@root=@"/> Name the root volume '@'. If not specified this stays as the default to stay compatible <volume name="@root=/"/> Indicate no root volume is wanted. All subvolumes resides below root (/) <volume name="@root=foo"/> Name the root volume 'foo' This is related to Issue #2316 and a first patch to address the requested changes
Allow to explicitly select if a toplevel subvolume should be created or not. To avoid a behavior change, kiwi will create a toplevel based btrfs structure if this attribute is not specified. However, a deprecation message to inform about future behavior change will be printed. This is related to Issue #2316
For the btrfs volume management, allow to put a volume into a specific parent volume. If not specified the volume is below the default volume This Fixes #2316
In a volume setup the special volume declaration <volume name="@root=identifier"/> was only evaluated for the LVM volume manager. In case of btrfs a hardcoded root volume name '@' was used. This commit allows to specify a custom name for the root volume for btrfs as well and also allows to specify that there should be no such root volume. Example: <volume name="@root=@"/> Name the root volume '@'. If not specified this stays as the default to stay compatible <volume name="@root=/"/> Indicate no root volume is wanted. All subvolumes resides below root (/) <volume name="@root=foo"/> Name the root volume 'foo' This is related to Issue #2316 and a first patch to address the requested changes
Allow to explicitly select if a toplevel subvolume should be created or not. To avoid a behavior change, kiwi will create a toplevel based btrfs structure if this attribute is not specified. However, a deprecation message to inform about future behavior change will be printed. This is related to Issue #2316
Problem description
In the Fedora Asahi Remix we use
expecting to get two top-level subvolumes,
root
andhome
. Instead, kiwi creates a@
root subvolume and nestsroot
andhome
under it. Compare the layout we get:with the one on a stock Anaconda-installed Fedora system
Expected behaviour
home
androot
are created as top-level subvolumesSteps to reproduce the behaviour
https://pagure.io/fedora-asahi/kiwi-descriptions/blob/rawhide/f/platforms/workstation.xml is the full config snippet we're using
OS and Software information
The text was updated successfully, but these errors were encountered: