Worktree fix luks soft reboot#2219
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces logic to detect if the system is running on ostree and updates the crypttab generation to include the 'x-initrd.attach' option when necessary. I have identified an issue where the ostree marker file is incorrectly being checked within the target sysroot instead of the host's runtime directory. Additionally, I have suggested updating the detection logic to support an environment variable override for better testability and recommended updating the test case to verify the full crypttab output.
prestist
force-pushed
the
worktree-fix-luks-soft-reboot
branch
2 times, most recently
from
7d58038 to
774a042
Compare
|
This looks OK. But why is this CoreOS specific? Isn't Image Mode / bootc in the same boat here? |
|
@travier ah im sorry, yeah my description was a little too specific sounding, I was just giving examples. The changes also would fix it for bootc / Image Mode. I will update the description. Unless you were talking more about why I was conditionality pivoting for ostree systems only? |
|
|
||
| // Detect if we're on an ostree system | ||
| // Check the host's /run directory, not the target sysroot | ||
| isOstree := isOstreeSystem("/run/ostree-booted") |
There was a problem hiding this comment.
Hum, I don't think this file will exist at the time ignition runs. We might have to look at the kernel command line and see if ostree is in it.
There was a problem hiding this comment.
Hmm, I think /run/ostree-booted should actually exist by the time the files stage runs -- ostree-prepare-root.service has Before=initrd-root-fs.target and ignition-files.service runs after that target. But yeah, checking the kernel cmdline for ostree= is probably the better approach here --since that seems to be what all the other ostree initrd services do (like ignition-ostree-mount-var.service etc) and doesn't depend on another service having already run. I'll switch to that.
|
I think my question is: What happens on Image Mode? If you take a bootc image and install it via Anaconda, does soft-reboot works? Is it anaconda that does the same workaround that we are adding here? Then adding it to Ignition makes sense as we use it instead of Anaconda. Otherwise if this does not work on Image Mode then we should probably figure out a fix that does not rely on Ignition. |
oooh that is a very fair concern, to be honest I am not sure; I can do some research but it is out of my initial knowledge scope. |
|
Alright so I did look into anaconda, its doing the same thing mostly. Its adding x-initrd.attach unconditionally for any LUKS device. @travier , In which case maybe we just drop our conditional. Makes it cleaner? |
Add x-initrd.attach option unconditionally to all LUKS crypttab entries. This prevents systemd-cryptsetup-generator from adding Conflicts=umount.target, which is necessary for soft-reboot to work correctly with LUKS.
prestist
force-pushed
the
worktree-fix-luks-soft-reboot
branch
from
774a042 to
01d9516
Compare
2 participants
Add x-initrd.attach option unconditionally to all LUKS crypttab entries.
This prevents systemd-cryptsetup-generator from adding
Conflicts=umount.target, which is necessary for soft-reboot to work
correctly with LUKS.