Skip to content
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

35coreos-ignition: randomize partition GUIDs on first boot #1207

Closed
wants to merge 1 commit into from
Closed

35coreos-ignition: randomize partition GUIDs on first boot #1207

wants to merge 1 commit into from

Conversation

bgilbert
Copy link
Contributor

@bgilbert bgilbert commented Sep 8, 2021

We've been randomizing the disk GUID but not the partition GUIDs, contrary to the GPT spec. Partition GUIDs are already not stable identifiers, since new ones are generated by create_disk.sh on every image build, so ensure they're globally unique as well.

Randomizing the ESP GUID will break any existing UEFI boot variable created by fallback.efi, so it's important that we only do this on the first boot (to not break existing systems) and only after our bootloader setup has been taught not to create boot variables (to not break new systems).

Requires coreos/coreos-assembler#2421 or equivalent.

@cgwalters
Copy link
Member

This will make the hack "touch /boot/ignition.firstboot" for coreos/fedora-coreos-tracker#399 more likely to break booting right?

I think I'd say we should do something like hardcode "unconfigured" GUIDs in cosa, and then have this service be idempotent by only randomizing if it sees the unconfigured GUIDs? Or alternatively, is there a place in the GPT that we can store a bit of state?

Anyways, code seems fine as is.

@bgilbert
Copy link
Contributor Author

I think I'd say we should do something like hardcode "unconfigured" GUIDs in cosa, and then have this service be idempotent by only randomizing if it sees the unconfigured GUIDs?

We're already doing that; see line 35.

We've been randomizing the disk GUID but not the partition GUIDs, contrary
to the GPT spec.  Partition GUIDs are already not stable identifiers,
since new ones are generated by create_disk.sh on every image build, so
ensure they're globally unique as well.

Randomizing the ESP GUID will break any existing UEFI boot variable
created by fallback.efi, so it's important that we only do this on the
first boot (to not break existing systems) and only after our bootloader
setup has been taught not to create boot variables (to not break new
systems).
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