Skip to content

zfsbootmenu: extend zbm.prefer to set bootfs #741

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

zdykstra
Copy link
Member

Other bootloaders, such as rEFInd, can now be used to drive the boot process by specifying a dataset from which to boot. zbm.bootfs expects the fully qualified path to a filesystem; e.g. zroot/ROOT/void. If zbm.prefer is set to exclusively import a pool and the value of zbm.bootfs isn't on that pool, the bootfs value specified on the ZBM KCL is ignored.

If the overall design here is what people expect, I'll document zbm.bootfs as it's implemented now.

This closes #738

Copy link
Member

@ahesford ahesford left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if it makes sense to extend the zbm.prefer syntax to accommodate this capability without an additional option. The argument to zbm.prefer could be the desired filesystem, with the pool and bootfs extracted directly. The only drawback is ambiguity when the user might wish to specify a bootfs pointing to the top-level filesystem. I think this would be an unlikely edge case; most sources don't recommend putting any content on the root-level filesystem. A trailing slash on a top-level filesystem could be used to disambiguate in this corner case (e.g., zbm.prefer=pool/.

@zdykstra
Copy link
Member Author

I wonder if it makes sense to extend the zbm.prefer syntax to accommodate this capability without an additional option. The argument to zbm.prefer could be the desired filesystem, with the pool and bootfs extracted directly. The only drawback is ambiguity when the user might wish to specify a bootfs pointing to the top-level filesystem. I think this would be an unlikely edge case; most sources don't recommend putting any content on the root-level filesystem. A trailing slash on a top-level filesystem could be used to disambiguate in this corner case (e.g., zbm.prefer=pool/.

Extending zbm.prefer to also accept a dataset is an interesting idea.

  • zbm.prefer=zroot - look to this pool for the bootfs value

  • zbm.prefer=zroot/ROOT/void - explicitly use that as the bootfs value

  • zbm.prefer=zroot! - make sure this pool is imported before proceeding, use the bootfs value set on the pool

  • zbm.prefer=zroot/ROOT/void! - make sure this pool is imported before proceeding, explicitly use that as the bootfs value

  • zbm.prefer=zroot!! - import only that pool, use the bootfs value set on the pool

  • zbm.prefer=zroot/ROOT/void!! - import only that pool, explicitly use that value as the bootfs value

That seems like it could work, and wouldn't change any existing behavior of the zbm.prefer KCL option.

@zdykstra zdykstra force-pushed the kcl-before-you-go-go branch from 4a76085 to f817f11 Compare April 16, 2025 19:18
@zdykstra zdykstra changed the title zfsbootmenu: add zbm.bootfs parameter zfsbootmenu: extend zbm.prefer to set bootfs Apr 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants