docs: Add bootloaders.md #1354
docs: Add bootloaders.md #1354
Conversation
This one is important. Signed-off-by: Colin Walters <[email protected]>
github-actions
bot
added
documentation
control/skip-ci
![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
The pull request adds a new documentation file for bootloaders and updates the summary. The content seems informative and well-structured. Here are a few suggestions for improvement.
Merge Readiness
The pull request introduces a valuable documentation file and updates the summary. The suggestions provided aim to enhance clarity and provide additional context for users. I am unable to approve this pull request, and recommend that others review and approve this code before merging. If the author addresses the suggestions, the pull request will be in good shape to be merged.
|
|
||
| When you run `bootc install`, it invokes `bootupctl backend install` to install the bootloader to the target disk or filesystem. The specific bootloader configuration is determined by the container image and the target system's hardware. | ||
|
|
||
| Currently, `bootc` only runs `bootupd` during the installation process. It does **not** automatically run `bootupctl update` to update the bootloader after installation. This means that bootloader updates must be handled separately, typically by the user or an automated system update process. |
There was a problem hiding this comment.
Consider adding a brief explanation of why bootc doesn't automatically run bootupctl update. This could help users understand the design decision and potential implications.
For example, you could add something like: "This is to provide more control to the user and avoid unexpected updates during system operation."
| Currently, `bootc` only runs `bootupd` during the installation process. It does **not** automatically run `bootupctl update` to update the bootloader after installation. This means that bootloader updates must be handled separately, typically by the user or an automated system update process. | |
| Currently, `bootc` only runs `bootupd` during the installation process. It does **not** automatically run `bootupctl update` to update the bootloader after installation. This is to provide more control to the user and avoid unexpected updates during system operation. This means that bootloader updates must be handled separately, typically by the user or an automated system update process. |
|
|
||
| Currently, `bootc` only runs `bootupd` during the installation process. It does **not** automatically run `bootupctl update` to update the bootloader after installation. This means that bootloader updates must be handled separately, typically by the user or an automated system update process. | ||
|
|
||
| For s390x, bootc uses `zipl` instead of `bootupd`. No newline at end of file |
There was a problem hiding this comment.
It might be helpful to briefly mention why zipl is used for s390x instead of bootupd. Is it due to architectural differences or limitations?
| For s390x, bootc uses `zipl` instead of `bootupd`. | |
| For s390x, bootc uses `zipl` instead of `bootupd` due to architectural differences in how bootloaders are handled on this platform. |
3 participants
This one is important.