reference: development: the-kernel-snap: extend information#281
reference: development: the-kernel-snap: extend information#281dilyn-corner wants to merge 3 commits into
Conversation
Update to reflect the current state of the kernel snap and include information on the kernel.yaml. Signed-off-by: Dilyn Corner <dilyn.corner@canonical.com>
Compactify things. Signed-off-by: Dilyn Corner <dilyn.corner@canonical.com>
dilyn-corner
force-pushed
the
kernel-update
branch
from
de62f8d to
9859026
Compare
| # The kernel snap | ||
|
|
||
| As the name implies, the _kernel_ snap is responsible for defining the Linux kernel that will run in a snap-based system. The correct kernel snap for a given system is selected via the model assertion, produced and signed by the device's brand account before the image is built. Once the image is built, the kernel snap may be updated, but it cannot be replaced by a completely different kernel snap. | ||
| As the name implies, the _kernel_ snap is responsible for defining the Linux |
There was a problem hiding this comment.
As a French reader, "defining" might not be the perfect wording here to understand.
It is clearer to me to say the kernel snap is providing the Linux kernel image. (and the model assertion defines which kernel snap to use). But again, it may be my bad english skills confusing me here.
There was a problem hiding this comment.
I agree with you - notably I opted not to change much of the original language of the doc. I suppose I can do that.
| As the name implies, the _kernel_ snap is responsible for defining the Linux | ||
| kernel that will run in a snap-based system. The correct kernel snap for a given | ||
| system is selected via the model assertion, produced and signed by the device's | ||
| brand account before the image is built. Once the image is built, the kernel |
There was a problem hiding this comment.
When I first read, I asked myself: who is "produced and signed by the device's
brand account before the image is built": the "kernel snap" or the "model assertion".
I would fix it with: "which is produced and signed"
| system is selected via the model assertion, produced and signed by the device's | ||
| brand account before the image is built. Once the image is built, the kernel | ||
| snap may be updated, but it cannot be replaced by a completely different kernel | ||
| snap. |
There was a problem hiding this comment.
Unless remodelling is used, no ?
There was a problem hiding this comment.
You know I was going to say "no" as I thought I had remembered something about this, but this page (point 1) says otherwise. Interesting.
| ### initrd | ||
|
|
||
| The initrd component of the kernel snap plays a fundamental role in the booting | ||
| of an Ubuntu Core system. |
There was a problem hiding this comment.
What does it bring? It is like we miss further explanation when reading this.
There was a problem hiding this comment.
I believe I intended to flesh this section out more; the initrd needs some actual explaining as it plays a pretty pivotal (haha) role.
I did an investigation but thought we'd be better served by a separate doc. I'm not certain. I'd rather see the Core/SnapD teams take a stab at this.
Perhaps it would be more correct to drop the section.
| of an Ubuntu Core system. | ||
|
|
||
| Sample configuration files may be found in the reference gadget snaps. For further details, see [Build a kernel snap](https://documentation.ubuntu.com/core/how-to-guides/image-creation/build-a-kernel-snap/) in the Ubuntu Core documentation. | ||
| The initrd is usually built using the ubuntu-core-initramfs tool. |
There was a problem hiding this comment.
If we keep this, should we put a link to a documentation about how to build initrd for a Ubuntu Core system ? If the kernel plugin build initrd, then what does it bring to this doc ?
I am really missing what this section (initrd) brings.
There was a problem hiding this comment.
There isn't much in the way of documentation on the initrd for Core (or initrds in general...) - the initrd plugin provides an explanation for how to use the plugin, but doesn't in itself really explain what an initrd is for or why one is required.
So yeah, maybe we drop the section for now and have a TODO for documenting the initrd as a separate, multi-pulse ideal.
canonical-nicoharnois
left a comment
canonical-nicoharnois
left a comment
There was a problem hiding this comment.
Globally OK with the changes, new kernel.yaml section is valuable, thanks. Some comments however, mainly about the initrd section
|
|
||
| The kernel and initrd may be discrete objects, usually named `kernel.img` and | ||
| `initrd.img`, respectively. However, they could also be distributed as a single [Unified Kernel Image](https://uapi-group.org/specifications/specs/unified_kernel_image/) | ||
| (UKI) or as a [Flatted Image Tree](https://docs.u-boot.org/en/v2024.07/usage/fit/source_file_format.html) |
There was a problem hiding this comment.
Flattened Image Tree
This is the new spec for FIT image: https://fitspec.osfw.foundation/
There was a problem hiding this comment.
Good to know, thank you!
Small formatting and language fixups. Signed-off-by: Dilyn Corner <dilyn.corner@canonical.com>
3 participants
Update to reflect the current state of the kernel snap and include information on the kernel.yaml.