Fix bug in path to UUID code with multi-device btrfs#28
Open
andykitchen wants to merge 18 commits intoisantop:masterfrom
Open
Fix bug in path to UUID code with multi-device btrfs#28andykitchen wants to merge 18 commits intoisantop:masterfrom
andykitchen wants to merge 18 commits intoisantop:masterfrom
Conversation
This option wasn't really useful because kernelstub still did things when it was used. It's been official deprecated since version 2.0 and has been removed from the online and other documentation already, so this finally removes it from the program.
We don't want to flat-out remove the command line parameter without potentially informing scripts. For now, we will print a warning message and silently exit successfully without taking action. In the future, we will exit with non-zero status. Following that, we'll remove the option entirely.
This ensures that each entry applies strictly to the installation that created it. Before, if two OSs (possibly of different versions) used kernelstub, whichever one last had kernelstub run would be the one whose entry was written. This change cleans that up a bit by writing the hostname and the UUID into the filename of the entry. This ensures that the entry files are unique to that installation, and provides a human-readable way to select which installation to boot (if the hostname was changed).
Kernelstub 3.2 The PR releases Kernelstub 3.2 into the stable branch. This new version includes a number of fixes and new features: * Systemd-boot entry files are now named (nearly) uniquely for each OS, ensuring that parallel installs of the same OS don't conflict with loader entry files. (fixes isantop#23 ) * Adds new, more reliable UUID detection. Thanks @andykitchen (closes isantop#22 ) * Adds new online documentation (manpage)
This also makes the UUID matching code more robust at the expense of using the external tool `findmnt' This bug is caused by the assumtion that there is a 1-1 correspondence between device files and UUIDs (which is almost always true). Unfortunately BTRFS multi-device filesystems may have multiple devices associated with a single UUID. The old link reading code does not handle this case and fails to work. Ultimately it's probably better to use a upstream maintained tool for computing path -> UUID as it is subtle and not a core problem this tool is trying to solve. Also, `findmnt' is already provided by the `util-linux' package so another package dependency is not added.
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
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.
This is a rebase of the same patch from #22
This also makes the UUID matching code more robust
at the expense of using the external tool `findmnt'
This bug is caused by the assumtion that there is a
1-1 correspondence between device files and UUIDs
(which is almost always true). Unfortunately BTRFS
multi-device filesystems may have multiple devices
associated with a single UUID. The old link reading
code does not handle this case and fails to work.
Ultimately it's probably better to use a upstream
maintained tool for computing path -> UUID as it
is subtle and not a core problem this tool is trying
to solve. Also,
findmnt' is already provided by theutil-linux' package so another package dependencyis not added.