* containerd to semver v2.0.3
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* containerd v2.0.3 plus commits to fix blkdiscard
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* update containerd-dev dependencies
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* updated pkg/init and pkg/containerd deps
Signed-off-by: Avi Deitcher <avi@deitcher.net>
---------
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* bump containerd-dev to 2.0.2
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* update pkg/init libs to containerd-20
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* bump linuxkit CLI containerd deps to 20
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* update test/pkg/containerd to work with containerd v2.x tests
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* update containerd-dev deps
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* update pkg/init and pkg/containerd dependencies
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* update test/pkg/containerd deps
Signed-off-by: Avi Deitcher <avi@deitcher.net>
---------
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* add riscv64 kernels to kernel/Makefile and kernel/Dockerfile.*, riscv64 kernel config, bump alpine version for kernel builds
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* update bcc to v0.32.0 to include needed fixes
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* bump kernel builder alpine base to version including llvm19
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* in kernel-bcc, automatically determine python path
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* in kernel-perf, suppress newer gcc errors
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* riscv path in kernel build was incorrect
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* remove bcc compilation from kernel
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* update usages of kernel/6.6.13 to kernel/6.6.71
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* next run of updating kernel config
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* update test dependencies on kernel hash version
Signed-off-by: Avi Deitcher <avi@deitcher.net>
---------
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* Update linuxkit/alpine
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* tools/alpine: Update to latest
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* tools: Update to the latest linuxkit/alpine
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* Update use of tools to latest
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* tests: Update packages to the latest linuxkit/alpine
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* Update use of test packages to latest
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* pkgs: Update packages to the latest linuxkit/alpine
Signed-off-by: Avi Deitcher <avi@deitcher.net>
* Update package tags
Signed-off-by: Avi Deitcher <avi@deitcher.net>
---------
Signed-off-by: Avi Deitcher <avi@deitcher.net>
This option was previously not available and required postprocessing of a `tar-kernel-initrd` output.
Comparison with `iso-efi`:
`iso-efi` only loads the kernel at boot, and the root filesystem is mounted from the actual boot media (eg, a CD-ROM - physical or emulated). This can often cause trouble (it has for us) for multiple reasons:
- the linuxkit kernel might not have the correct drivers built-in for the hardware (see #3154)
- especially with virtual or emulated CD-ROMs, performance can be abysmal: we saw the case where the server IPMI allowed using a ISO stored in AWS S3 over HTTP...you can imagine what happens when you start doing random I/O on the root fs in that case.
- The ISO image has the root device name baked in (ie, `/dev/sr0`) which fails if for some reason the CD-ROM we're running from doesn't end up using that device, so manual tweaking is required (see #2375)
`iso-efi-initrd`, on the other hand, packs the root filesystem as an initramfs (ie similar to what the raw output does, except that in this case we're preparing an ISO image), so both the kernel and the initramfs are loaded in memory by the boot loader and, once running, we don't need to worry about root devices or kernel drivers (and the speed is good, as everything runs in RAM).
Also, the generated ISO can be copied verbatim (eg with `dd`) onto a USB media and it still works.
Finally, the image size is much smaller compared to `iso-efi`.
IMHO, `iso-efi-initrd` could be used almost anywhere `iso-efi` would be used, or might even supersede it. I can't think of a scenario where one might explicitly want to use `iso-efi`.
Points to consider:
- Not tested under aarch64 as I don't have access to that arch. If the automated CI tests also test that, then it should be fine.
- I'm not sure what to put inside `images.yaml` for the `iso-efi-initrd` image. As it is it works of course (my personal image on docker hub), but I guess it'll have to be some more "official" image. However, that cannot be until this PR is merged, so it's kind of a chicken and egg situation. Please advise.
- I can look into adding the corresponding `iso-bios-initrd` builder if there is interest.
Signed-off-by: Davide Brini <waldner@katamail.com>
./scripts/update-component-sha.sh linuxkit/runc:21dbbda709ae138de0af6b0c7e4ae49525db5e88 linuxkit/runc:9f7aad4eb5e4360cc9ed8778a5c501cce6e21601
Signed-off-by: David Scott <dave@recoil.org>
With 561ce6f4be ("Remove Notary and Content Trust") we
removed support for content trust. No need to have it
in the YAMLs either.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
