-
Notifications
You must be signed in to change notification settings - Fork 157
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
fix failure at second boot #2697
base: testing-devel
Are you sure you want to change the base?
Conversation
The issue occurs at unexpected shutdown (such as power-off, or ctrl + a +x to exit qemu) after first boot, data was not completely saved to disk. ------ Ignition has failed. Please ensure your config is valid. Note that only Ignition spec v3.0.0+ configs are accepted. A CLI validation tool to check this called ignition-validate can be downloaded from GitHub: https://github.com/coreos/ignition/releases ------ CoreOS uses boot args `ignition.firstboot' as flag for the first boot, during first boot, ignition parse and apply user define config (add user/passwd/ssh key), and remove the config file; then call script /usr/libexec/coreos-ignition-firstboot-complete. In script /usr/libexec/coreos-ignition-firstboot-complete, it remove /boot/ignition.firstboot, the GRUB detect it and remove boot args `ignition.firstboot' if /boot/ignition.firstboot does not exists at second boot If shundown at the time after ignition removes ignition user define config, before script /usr/libexec/coreos-ignition-firstboot-complete removes /boot/ignition.firstboot, the coming boot will be recognized as first boot, but the ignition user define config is lost Call sync to assure the remove operation on disk Signed-off-by: Hongxu Jia <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I think this makes sense overall. But actually, I think previously we wanted to move that logic to the initramfs. I still think that makes sense so that we greatly reduce the race window. It could pretty easily live in coreos-boot-edit.service
nowadays.
I'm not suggesting you do that in this PR though. The code move is trivial, but it needs to be fully thought through first.
@@ -17,3 +17,5 @@ rm /boot/ignition.firstboot | |||
if [[ $(uname -m) = s390x ]]; then | |||
/usr/lib/dracut/modules.d/50rdcore/rdcore zipl --boot-mount=/boot | |||
fi | |||
|
|||
sync |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sync | |
sync /boot |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we also move this to right after the rm
?
The issue occurs at unexpected shutdown (such as power-off, or ctrl + a +x to exit qemu) after first boot, data was not completely saved to disk.
Ignition has failed. Please ensure your config is valid. Note that only Ignition spec v3.0.0+ configs are accepted.
A CLI validation tool to check this called ignition-validate can be downloaded from GitHub:
https://github.com/coreos/ignition/releases
CoreOS uses boot args `ignition.firstboot' as flag for the first boot, during first boot, ignition parse and apply user define config (add user/passwd/ssh key), and remove the config file; then call script /usr/libexec/coreos-ignition-firstboot-complete.
In script /usr/libexec/coreos-ignition-firstboot-complete, it remove /boot/ignition.firstboot, the GRUB detect it and remove boot args `ignition.firstboot' if /boot/ignition.firstboot does not exists at second boot
If shundown at the time after ignition removes ignition user define config, before script /usr/libexec/coreos-ignition-firstboot-complete removes /boot/ignition.firstboot, the coming boot will be recognized as first boot, but the ignition user define config is lost
Call sync to assure the remove operation on disk