-
Notifications
You must be signed in to change notification settings - Fork 305
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
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
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 23, 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 23, 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: