* Fix return code of rungetty.sh
In case of INITGETTY defined we will return exit code 1 which is not
expected
Signed-off-by: Petr Fedchenkov <giggsoff@gmail.com>
* Update getty sha
Signed-off-by: Petr Fedchenkov <giggsoff@gmail.com>
* restore package cache in LinuxKit Build Tests
Signed-off-by: Petr Fedchenkov <giggsoff@gmail.com>
Signed-off-by: Petr Fedchenkov <giggsoff@gmail.com>
* Update of buildkit to the last version
Commit contains the version of buildkit from output of
`go list -m -json github.com/moby/buildkit@c0ac5e8b9b51603c5a93795fcf1373d6d44d3a85`:
go get -u github.com/moby/buildkit@v0.11.0-rc1.0.20221213132957-c0ac5e8b9b51
go mod tidy
go mod vendor
Signed-off-by: Petr Fedchenkov <giggsoff@gmail.com>
* Fix handling of platform flag
In case of 'FROM --platform' defined I can see 'ERROR: no match for
platform in manifest: not found'. The problem was fixed on buildkit side
Signed-off-by: Petr Fedchenkov <giggsoff@gmail.com>
Signed-off-by: Petr Fedchenkov <giggsoff@gmail.com>
We noticed that we use host arch when we want to use previously build
image in oci-layout. Let's use fix on buildkit side and improve test.
Signed-off-by: Petr Fedchenkov <giggsoff@gmail.com>
We should check if we have args in "FROM" and replace them:
ARG IMAGE=linuxkit/img
FROM ${IMAGE} as src
will be parsed as
FROM linuxkit/img as src
Signed-off-by: Petr Fedchenkov <giggsoff@gmail.com>
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>
This allows multiple build flavors for a single codebase, without
sacrificing reproducible builds. The build-args are set in build.yml,
which is typically under the source control (if it is not, then no
reproducible builds are possible anyways). Meaning that mutating
build-args would result in setting "dirty" flag.
Intended use of this commit is to switch between build flavors by
specifying a different yaml file (presumably also under the version
control) by `-build-yml` option.
Because it is impossible to build a final image from packages in
cache, the test for this feature relies on the `RUN echo $build-arg`
output during the `pkg build` process.
Signed-off-by: Yuri Volchkov <yuri@zededa.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>
oprofile kernel support was dropped with 5.12.x with:
f8408264c77a ("drivers: Remove CONFIG_OPROFILE support")
However the commit stated that the userspace oprofile tools
had stopped using the kernel interface for a log time. So
drop the check.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
Some kernels are only build for some architectures. The
test assumed that all kernels were build for all architectures.
Now, get a list of architectures for which we have a given
kernel image and then make sure the builder images pointed
to by the label and the builder image tagged by convention
exist and point to the same thing.
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
This commit removes Notary and Content Trust.
Notary v1 is due to be replaced with Notary v2 soon.
There is no clean migration path from one to the other.
For now, this removes all signing from LinuxKit.
We will look to add this back once a new Notary alternative
becomes available.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
NOTE: This will be a shared mount, due to root being turned into a
shared with `MC_REC` set: `mount("", "/", "", rec|shared, "")`.
For some reason setting `shared` when mounting `/sys/fs/bpf` doesn't
work at all, perhaps that's just a kernel feature.
Signed-off-by: Ilya Dmitrichenko <errordeveloper@gmail.com>
This commit adds the GCP test that formerly ran in LinuxKitCI to run
under rtf.
As GitHub Actions doesn't currently support adding secret files, I've
skipped this test for now. Credentials can be passed via environment
variable but as RTF runs with `-x` the contents is viewable in the logs.
I will create an issue to follow up and find either a way of writing the
variable to file that doesn't compromise it. Or perhaps another approach
that is more compatible with GH actions
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
The rootfs fs was removed in 5.3.x but was mostly a
irrelevant entry in the filesystems list anyway.
Here is the upstream commit:
commit fd3e007f6c6a0f677e4ee8aca4b9bab8ad6cab9a
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Thu May 30 17:48:35 2019 -0400
don't bother with registering rootfs
init_mount_tree() can get to rootfs_fs_type directly and that simplifies
a lot of things. We don't need to register it, we don't need to look
it up *and* we don't need to bother with preventing subsequent userland
mounts. That's the way we should've done that from the very beginning.
There is a user-visible change, namely the disappearance of "rootfs"
from /proc/filesystems. Note that it's been unmountable all along
and it didn't show up in /proc/mounts; however, it *is* a user-visible
change and theoretically some script might've been using its presence
in /proc/filesystems to tell 2.4.11+ from earlier kernels.
*IF* any complaints about behaviour change do show up, we could fake
it in /proc/filesystems. I very much doubt we'll have to, though.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
