Add support for the kernel being within a btrfs subvolume #226
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Owner
|
Thanks for the PR! |
N-Parsons
force-pushed
the
btrfs-boot
branch
2 times, most recently
from
9033ab5 to
e2748c6
Compare
- /boot may be within a named root subvolume (eg. "/@/boot") - /boot may be in its own subvolume (eg. "/@boot")
Contributor
Author
|
Sorry about that, @speed47 - the issues should now be resolved. |
Owner
|
Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current release fails to find my kernel due to my use of btrfs.
On my system, "/boot" is within a subvolume named "@" (a fairly standard approach to btrfs filesystem layout) and GRUB mounts the btrfs partition at the top level, meaning that it sees the boot directory at "/@/boot"; the result is that
grep -Eo 'BOOT_IMAGE=[^ ]+returns "/@/boot/vmlinuz...". Once the system has booted however, the boot directory is found simply at "/boot", rather than "/@/boot", so the script currently reports that the kernel can't be found when running in live mode. This PR resolves this issue.While not the case on my system (and usually advised against as being unnecessary) some users may use a separate btrfs subvolume for their "/boot" directory (eg. "@boot"), so I've written my patch to also be able to handle these, relying on the existing code used to prepend "/boot".
Some other btrfs configurations are possible (eg. putting the root filesystem directly at the top level), but these should already be catered for by the existing code.