-
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
Evaluate the @root volume name also for btrfs #2324
Conversation
Can you add a test case for the behavior we want in Fedora so that we can verify this does what we expect? |
This is not the complete patch series we need to achieve the end result you want in Fedora. But I will add a test case that shows the volume creation without a root volume |
Once there's a test for it, I'll be happy to approve it. |
5823f33
to
0e1c71c
Compare
There is now a unit test available. I did some real test builds and stumbled over some weird things but it's late here and my brain doesn't work anymore... don't merge it :) |
0e1c71c
to
e639823
Compare
ok finished testing and worked for me. The unit test here is imho not enough, we also want an integration test. I'm going to setup an integration test build next |
e639823
to
aa8bed1
Compare
I'm not sure this is a good approach. Magic data can be unpredictable. Here's my suggestion of what we should do: #2316 (comment) |
Once we have an integration test, I'll approve and merge it. |
I added the mentioned attribute and deprecation message. I think it's a good idea to make it explicitly configured. I'm on it, but might take a bit since there are some tasks I have to complete next week first |
Integration test setup done here: Watch out for the |
7df8a3d
to
0ed2365
Compare
@Conan-Kudo @iammattcoleman I added the parent setup and build as I hope the layout that is wanted here. Keeping all this consistent and regression free with how btrfs is used in its "default" aka suse way is really not that easy. We should have had an eye on the general implementation when it was started, but as we can't turn back the time this option does not exist. One part that will stay for the moment is how to specify the root volume. You suggested <volume name="root" mountpoint="/"/> and it's a nicer read yes but I have to leave this for backward compatibility to look like: <volume name="@root=root"/> This part I will not change. The other suggestions were implemented the way we discussed them. I will now take a very close look to all the integration tests that we built for btrfs and see how the results look like |
We should put it on the list of things to evaluate for KIWI 10 then. |
b33a69f
to
1018caa
Compare
37522c0
to
2fa789b
Compare
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
Change the Virtual profile to build a btrfs based image for testing respective btrfs layouts
Make the function call more robust in terms of path separation
When using btrfs with the proposed layout for testing the delivered grub bios module for the Fedora system used to build the integration test (FC37) is not capable to find the grub config file. A manual call for configfile in the grub shell fixes this with the existing kiwi created grub early-boot script. However, it is expected that the delivered grub image works and kiwi only creates its own one if no distro delivered grub image was found. To make the integration test functional for both BIOS and EFI the simple solution is to use an extra not btrfs based boot partition. This still allows to test the desired btrfs layout in terms of volumes and sub-volumes and does not break on any of the boot methods.
Don't copy the same file. This case happens when rebuilding an image using --allow-existing-root when the fallback setup has done its job already in the first run
If the rootfs is btrfs based make sure the fstab entry for it takes the name of the root subvolume into account
4a55c5d
to
f8f1c00
Compare
@Conan-Kudo ok image are building and the one setup as the integration test for the changes introduced here is done too. From my perspective it looks good now, please double check
Thanks |
The fstab looks right, but can we make it possible so that |
Hmm, I think we shouldn't connect that implicitly. Looking into it |
5b2c135
to
8d8c14c
Compare
@Conan-Kudo ok I have added an attribute that allows you to configure if kiwi should set a default volume or not. The integration test has this switched off as you wanted. With the last commit I fixed the places in kiwi which assumed there is a default volume set. With that patch the integration test will also start to build again However, there is now another problem at boot of the test image (I did built it here locally). Not unexpected the image fails to boot and you land in a rescue shell inside of the initrd. As far as I can see the initrd simply tries to mount the root filesystem. Without any default volume configured this of course is not the correct volume. Because btrfs uses (/)
you have the Brings me to the question if you don't want any default, how can I make this Fedora37 based system to boot again ? Please advise |
Now we need to propagate For example, this is what one of my installed Fedora systems has:
|
Ah ok, that should be easy we already have a section to specify custom bootloader config settings.... I'll jump on it later as I have to do another task now stay tuned... again :) |
By default kiwi runs btrfs set-default on the volume that is considered the default volume according to the btrfs settings and defaults. btrfs_set_default_volume="false" allows to deactivate this action. Along with the change also the misleading name of the btrfs_create_toplevel_subvolume has been changed to root_is_subvolume
The setting of a default volume is unwanted here
With the possibility to switch off setting the default volume an issue at other parts in the kiwi code which mounted the btrfs based system were uncovered. Without any default volume set it's required to transport the root volume if different from / and pass the respective subvol= option to the mount. This commit fixes it at the places where kiwi trusted btrfs to have a correct default volume set
2e88686
to
dd110f6
Compare
ok works, we are getting closer :) |
Are we in a reviewable/testable state now? |
yes we are, the integration test is currently building. We should be good now. All other builds still succeed and we are backward compatible |
In case of btrfs and if btrfs_set_default_volume is explicitly switched off, we create the correct rootflags= kernel cmdline entry to tell the system about the root volume for booting
@Conan-Kudo waiting for all tests to pass... |
looks good |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're finally in a good place!
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:Name the root volume '@'. If not specified this stays as the default to stay compatible
Indicate no root volume is wanted. All subvolumes resides below root (/)
Name the root volume 'foo'
This is related to Issue #2316 and a first patch to address the requested changes