dracut/ignition-ostree: Regenerate UUIDs for /boot and / #354
Conversation
This file contains 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
cgwalters
commented
Apr 17, 2020
| ConditionKernelCommandLine=ostree | ||
| ConditionPathExists=!/run/ostree-live | ||
| # We run pretty early | ||
| Before=coreos-copy-firstboot-network.service |
There was a problem hiding this comment.
If we switch to having a boot.mount in the initramfs then this would just be:
Before=boot.mount.
Yeah I'm in favor of a |
jlebon
approved these changes
Apr 20, 2020
There was a problem hiding this comment.
Independent of coreos/fedora-coreos-tracker#465, I think this is a good idea. LGTM overall, just one nit!
| ConditionPathExists=!/run/ostree-live | ||
| # We run pretty early | ||
| Before=coreos-copy-firstboot-network.service | ||
| Before=ignition-fetch.service |
There was a problem hiding this comment.
Minor: we don't need this ordering here. It's already implied by being ordered Before=ignition-setup-{base,user}.service below. (This is harmless of course, but it's a pet peeve of mine to have ordering requirements like this which seem to imply the order of all the Ignition stages aren't in fact strictly ordered.)
darkmuggle
approved these changes
Apr 22, 2020
cgwalters
added a commit
to cgwalters/coreos-assembler
that referenced
this pull request
May 13, 2020
For reasons I don't fully understand, trying to use `tune2fs -U random /dev/disk/by-label/boot` fails without this explicit fsck step, even though the filesystem appears cleanly unmounted. This is for coreos/fedora-coreos-config#354 to regenerate the UUID of `/boot` on firstboot. Anyways, explicitly unmounting things seems better than relying on `umount -R` to sort it, and having a `fsck` on `/boot` is cheap.
cgwalters
added a commit
to cgwalters/coreos-assembler
that referenced
this pull request
May 13, 2020
For reasons I don't fully understand, trying to use `tune2fs -U random /dev/disk/by-label/boot` fails without this explicit fsck step, even though the filesystem appears cleanly unmounted. This is for coreos/fedora-coreos-config#354 to regenerate the UUID of `/boot` on firstboot. Anyways, explicitly unmounting things seems better than relying on `umount -R` to sort it, and having a `fsck` on `/boot` is cheap.
|
Whee, some sort of race in an unrelated test: |
jlebon
reviewed
May 15, 2020
There was a problem hiding this comment.
Looks sane to me! Just one minor comment (there was also #354 (comment) from a previous review).
Comment on lines
17
to
23
| regenerate_uuid_if() { | ||
| local path=$1 | ||
| shift | ||
|
|
||
|
|
||
| } | ||
|
|
This is a general best practice; the intention of filesystem UUIDs is that they're unique. It helps backup systems and the like if we change this. This builds on coreos/coreos-assembler@e3905fd In the future, we may also switch to using these UUIDs for subsequent boots; see: coreos/fedora-coreos-tracker#465
|
This is now part of #503. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 general best practice; the intention of filesystem
UUIDs is that they're unique. It helps backup systems and the like
if we change this.
But in the future, we may also switch to using these UUIDs for subsequent
boots; see: coreos/fedora-coreos-tracker#465