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

Make handling of boot= and root= kargs idempotent #2141

Closed
wants to merge 4 commits into from

Conversation

cgwalters
Copy link
Member

@cgwalters cgwalters commented Jan 2, 2023

dracut/boot-edit: Do nothing if we have a boot= karg

In this case, we shouldn't have anything to do. This is needed
for bootc install which currently sets up these kargs in advance.
containers/bootc#30


dracut/ignition-setup: Use boot= karg if it exists

This will be used with bootc which will default to injecting
a karg for boot.


ignition-uuid-root: no-op if we already have a root= karg

For bootc compatibility.


overlay: More no-ops if we have a boot= and/or root= karg

We can assume the disk image is already set up in this case.


@jlebon
Copy link
Member

jlebon commented Jan 3, 2023

Hmm, so this is to support a bootc-installed FCOS, right? I think it'd be good to discuss what the long-term goal is for bootc and FCOS.

Re. this PR specifically, the use of /dev/disk/by-label/boot is pervasive throughout this codebase. But anyway, we also now have code that ensures that only one filesystem labeled boot exists so it shouldn't be necessary, right? Or are you trying to support systems where that is no longer true?

@cgwalters cgwalters marked this pull request as draft January 3, 2023 23:17
@cgwalters
Copy link
Member Author

Hmm, so this is to support a bootc-installed FCOS, right? I think it'd be good to discuss what the long-term goal is for bootc and FCOS.

Yep, I plan to get something scheduled for this soon this month!

But anyway, we also now have code that ensures that only one filesystem labeled boot exists so it shouldn't be necessary, right?

This scenario arises when one boots one FCOS-derived system, and is using it to install to a different disk.

But this isn't critical to merge soon, so I just marked as draft.

In this case, we shouldn't have anything to do.  This is needed
for `bootc install` which currently sets up these kargs in advance.
containers/bootc#30
This will be used with bootc which will default to injecting
a karg for `boot`.
We can assume the disk image is already set up in this case.
@cgwalters cgwalters marked this pull request as ready for review January 17, 2023 20:16
@cgwalters
Copy link
Member Author

OK, lifting draft on this one.

# Copied from
# https://github.com/dracutdevs/dracut/blob/9491e599282d0d6bb12063eddbd192c0d2ce8acf/modules.d/99base/dracut-lib.sh#L586
# rather than sourcing it.
label_uuid_to_dev() {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this should move to rdcore or so?

@cgwalters cgwalters changed the title Make handling of boot= karg idempotent Make handling of boot= and root= kargs idempotent Jan 17, 2023
@cgwalters
Copy link
Member Author

[2023-01-17T21:20:18.693Z] + cosa kola testiso -S --qemu-multipath --scenarios iso-offline-install --output-dir /srv/coreos/tmp/kolaTestIso-7qsbl/kola-testiso-multipath
[2023-01-17T21:20:18.693Z] kola -p qemu-unpriv --output-dir /srv/coreos/tmp/kolaTestIso-7qsbl/kola-testiso-multipath testiso -S --qemu-multipath --scenarios iso-offline-install
[2023-01-17T21:20:18.693Z] Testing scenarios: [iso-offline-install]
[2023-01-17T21:20:18.693Z] Ignoring verification of signature on metal image
[2023-01-17T21:21:26.668Z] FAIL: iso-offline-install ( + metal + multipath) (1m1.819s)
[2023-01-17T21:21:26.668Z]     entered emergency.target in initramfs
[2023-01-17T21:21:26.668Z] Error: entered emergency.target in initramfs

Hm, not seeing the failure there in the logs.

@dustymabe
Copy link
Member

Hm, not seeing the failure there in the logs.

coreos/fedora-coreos-tracker#1373

Copy link
Member

@jlebon jlebon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like the last two commits could be merged?

@@ -9,6 +9,7 @@ After=ignition-disks.service
# If we've reprovisioned the rootfs, then there's no need to restamp
ConditionPathExists=!/run/ignition-ostree-transposefs
ConditionKernelCommandLine=!rootfs.roothash
ConditionKernelCommandLine=!root
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this would break multipath, where currently you have to put the root karg at install time but we do still want the restamping. Is this actually required for bootc? The service will run but the script should no-op if the filesystem UUID was already randomized.

Similarly for coreos-gpt-setup.service.

}

# This is copied from coreos-boot-mount-generator which we should likely run
# in the initramfs too
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think that'd be a safer path. This seems to be trying to undo the assumption that /dev/disk/by-label/boot points to our boot disk at first boot, but only for one service, whereas it's an assumption embedded all over the place. The generator could put the found device in e.g. /run/coreos/bootdev?

*) echo "Unknown boot karg '${bootkarg}'; falling back to ${bootdev}";;
esac
# This is used for the first boot only
elif [ -f /run/coreos/bootfs_uuid ]; then
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is written by coreos-boot-edit and isn't relevant here.

@cgwalters cgwalters added the bootc bootc compatibility label Mar 20, 2023
@cgwalters cgwalters added the area/container-native Work related to moving FCOS to be container-native label Sep 19, 2023
@cgwalters
Copy link
Member Author

For now, won't be targeting FCOS with bootc install.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/container-native Work related to moving FCOS to be container-native bootc bootc compatibility
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants