gpt-auto-generator: mount ESP when LoaderDevicePartUUID isn't set #164
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.
If LoaderDevicePartUUID isn't set because the boot loader doesn't support it,
assume that the ESP partition on the root disk is the booted ESP. This is a
weaker guarantee but likely the same for the vast majority of systems. Allowing
the ESP automount in this case helps break a dependency loop. Existing boot
loaders can be changed to set LoaderDevicePartUUID, but they can't be delivered
to existing systems if the ESP is not mounted.
Upstream: systemd/systemd#26430
https://phabricator.endlessm.com/T29930
This is on top of #163. I sent this upstream, but I doubt it's going to get merged. For Endless I think this makes sense to bootstrap updating EFI programs so that eventually we can have a grub that supports
LoaderDevicePartUUID.@wjt pointed out that this probably won't work right on dual boot systems. I think that should be managed separately. Possibly we can add in a custom generator for that scenario.