ostree admin prepare-kexec #435
Labels
Comments
|
Also i want to note, that if kernel version does not changed (does it possible to detect this), to switch root and restart services (this saves time to reinit devices...) |
|
Looks like Anaconda supports this since rhinstaller/anaconda@1eeae68#diff-db454be2c18df8e93b2dc5c3526806cb |
Mstrodl
added a commit
to Mstrodl/ostree
that referenced
this issue
Dec 19, 2024
Adds a new `--kexec` flag to `ostree admin upgrade` which will cause the deployment to be loaded into kexec after the upgrade completes. It is particularly useful in conjunction with the `--reboot` flag to perform a reboot into the new deployment without waiting for the (often slow) firmware initialization to take place. (And in my case, allows me to avoid a normal reboot, which can be unreliable on my hardware). After an image has been loaded (using the `kexec_file_load` syscall), the `systemctl-reboot` command (which is called when the existing `-r` flag is included) will trigger a kexec on the loaded image rather than a normal reboot. From `systemctl(1)`: If a new kernel has been loaded via kexec --load, a kexec will be performed instead of a reboot, unless "SYSTEMCTL_SKIP_AUTO_KEXEC=1" has been set. If a new root file system has been set up on "/run/nextroot/", a soft-reboot will be performed instead of a reboot, unless "SYSTEMCTL_SKIP_AUTO_SOFT_REBOOT=1" has been set. A good in-depth technical explanation of kexec can be found here: https://web.archive.org/web/20090505132901/http://www.ibm.com/developerworks/linux/library/l-kexec.html My implementation uses the `kexec_file_load` syscall rather than the older `kexec_load` syscall, which allows the kernel to verify the signatures of the new kernel. It is supported on Linux 3.17 and newer. I assume this probably won't be an issue, but if it is, it's not that hard to put a preprocessor directive around the kexec stuff to disable it for older kernels. Even RHEL is new enough now to not be an issue :) Closes: ostreedev#435
Mstrodl
added a commit
to Mstrodl/ostree
that referenced
this issue
Dec 19, 2024
Adds a new `--kexec` flag to `ostree admin upgrade` which will cause the deployment to be loaded into kexec after the upgrade completes. It is particularly useful in conjunction with the `--reboot` flag to perform a reboot into the new deployment without waiting for the (often slow) firmware initialization to take place. (And in my case, allows me to avoid a normal reboot, which can be unreliable on my hardware). After an image has been loaded (using the `kexec_file_load` syscall), the `systemctl-reboot` command (which is called when the existing `-r` flag is included) will trigger a kexec on the loaded image rather than a normal reboot. From `systemctl(1)`: If a new kernel has been loaded via kexec --load, a kexec will be performed instead of a reboot, unless "SYSTEMCTL_SKIP_AUTO_KEXEC=1" has been set. If a new root file system has been set up on "/run/nextroot/", a soft-reboot will be performed instead of a reboot, unless "SYSTEMCTL_SKIP_AUTO_SOFT_REBOOT=1" has been set. A good in-depth technical explanation of kexec can be found here: https://web.archive.org/web/20090505132901/http://www.ibm.com/developerworks/linux/library/l-kexec.html My implementation uses the `kexec_file_load` syscall rather than the older `kexec_load` syscall, which allows the kernel to verify the signatures of the new kernel. It is supported on Linux 3.17 and newer. I assume this probably won't be an issue, but if it is, it's not that hard to put a preprocessor directive around the kexec stuff to disable it for older kernels. Even RHEL is new enough now to not be an issue :) Closes: ostreedev#435
Mstrodl
added a commit
to Mstrodl/ostree
that referenced
this issue
Dec 19, 2024
Adds a new `--kexec` flag to `ostree admin upgrade` which will cause the deployment to be loaded into kexec after the upgrade completes. It is particularly useful in conjunction with the `--reboot` flag to perform a reboot into the new deployment without waiting for the (often slow) firmware initialization to take place. (And in my case, allows me to avoid a normal reboot, which can be unreliable on my hardware). After an image has been loaded (using the `kexec_file_load` syscall), the `systemctl-reboot` command (which is called when the existing `-r` flag is included) will trigger a kexec on the loaded image rather than a normal reboot. From `systemctl(1)`: If a new kernel has been loaded via kexec --load, a kexec will be performed instead of a reboot, unless "SYSTEMCTL_SKIP_AUTO_KEXEC=1" has been set. If a new root file system has been set up on "/run/nextroot/", a soft-reboot will be performed instead of a reboot, unless "SYSTEMCTL_SKIP_AUTO_SOFT_REBOOT=1" has been set. A good in-depth technical explanation of kexec can be found here: https://web.archive.org/web/20090505132901/http://www.ibm.com/developerworks/linux/library/l-kexec.html My implementation uses the `kexec_file_load` syscall rather than the older `kexec_load` syscall, which allows the kernel to verify the signatures of the new kernel. It is supported on Linux 3.17 and newer. I assume this probably won't be an issue, but if it is, it's not that hard to put a preprocessor directive around the kexec stuff to disable it for older kernels. Even RHEL is new enough now to not be an issue :) Closes: ostreedev#435
Mstrodl
added a commit
to Mstrodl/ostree
that referenced
this issue
Dec 19, 2024
Adds a new `--kexec` flag to `ostree admin upgrade` which will cause the deployment to be loaded into kexec after the upgrade completes. It is particularly useful in conjunction with the `--reboot` flag to perform a reboot into the new deployment without waiting for the (often slow) firmware initialization to take place. (And in my case, allows me to avoid a normal reboot, which can be unreliable on my hardware). After an image has been loaded (using the `kexec_file_load` syscall), the `systemctl-reboot` command (which is called when the existing `-r` flag is included) will trigger a kexec on the loaded image rather than a normal reboot. From `systemctl(1)`: If a new kernel has been loaded via kexec --load, a kexec will be performed instead of a reboot, unless "SYSTEMCTL_SKIP_AUTO_KEXEC=1" has been set. If a new root file system has been set up on "/run/nextroot/", a soft-reboot will be performed instead of a reboot, unless "SYSTEMCTL_SKIP_AUTO_SOFT_REBOOT=1" has been set. A good in-depth technical explanation of kexec can be found here: https://web.archive.org/web/20090505132901/http://www.ibm.com/developerworks/linux/library/l-kexec.html My implementation uses the `kexec_file_load` syscall rather than the older `kexec_load` syscall, which allows the kernel to verify the signatures of the new kernel. It is supported on Linux 3.17 and newer. I assume this probably won't be an issue, but if it is, it's not that hard to put a preprocessor directive around the kexec stuff to disable it for older kernels. Even RHEL is new enough now to not be an issue :) Closes: ostreedev#435
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We should optionally support kexec. See https://nicst.de/spinning-reboot.html and
https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2016-August/msg00005.html
The text was updated successfully, but these errors were encountered: