These packages are pulling in iputils, that used to provide the
traceroute utility. The updated iputils package stopped doing that
altogether, recommending to install net-analyzer/traceroute or
net-analyzer/mtr instead. We are going with the former here.
Also drop the comment, it was related to the media-libs/mesa package
that was dropped over 9 years ago in commit
de91081f00a4ab07332759b1bbfc3072d530c9fd.
Qemu-guest-agent gets activated using a udev rule, and so will only run
when the correct virtio-port name is detected. Qemu-guest-agent is used
across several oems so we include it in the usr partition.
Disable ARCH_QCOM, ARCH_ZYNQMP, ARCH_MEDIATEK which enable other options that
are only relevant on the respective boards, none of which are supported targets
for Flatcar. Since the arm64 kernel does not support compression, these
settings have a significant impact on kernel size. The boot partition size is
only 128MB and needs to fit 2 kernels, so we have set ourselves a target of
60MB per kernel. This commit brings down the arm64 kernel size by 3MB.
At the same time, enable the settings that are actually relevant: ARCH_BCM,
because that one is relevant for Raspberry Pi 4 that runs Linux.
No point in setting UPDATE_NEEDED to zero if we exit the script
without doing anything with the just set variable.
Also to avoid mismatches in branch names, export the branch name as a
github workflow step output, so the follow-up steps can pick it up and
use.
No point in setting UPDATE_NEEDED to zero if we exit the script
without doing anything with the just set variable.
Also fix the mismatch in branch names - we normally create a branch
like "cacerts-${NSS_VERSION}-${BRANCH}" in the last workflow step
whereas we were checking if a branch like "${NSS_VERSION}-${BRANCH}"
existed in the script. To avoid repetition, export the branch name as
a github workflow step output, so the follow-up steps can pick it up
and use.
This sets up the coreos-overlay submodule inside the SDK container to
use the remote of the fork and the base branch from that fork. That
way, we can test the workflows in the forks too.
While glibc 2.33 has /lib64/ld-2.33.so, glibc 2.34 does not have that,
but only /lib64/ld-linux-x86-64.so.2. So we should also check ld-linux-*
as well.
Pulls in https://github.com/flatcar-linux/update_engine/pull/17.
- take care of nscd.conf via tmpfiles, add files/nscd-conf.tmpfiles.
- don't run sanity checks in pkg_pretend to prevent gcc checks when
only the binary package is installed.
- comment out 'dostrip -x' to force the OS image binaries to be stripped
- remove everything glibc wants to put under /etc since we use
baselayout to provide that
The libxslt upstream fixed their python bindings, so they are not
python2 only. Gentoo then started to build them. Since we have fared
well so far without the bindings, keep on not building them.
Bpftool 5.18.11 is gone from portage-stable, 5.19.2 is the new stable
version for amd64. There's still no keyword for arm64, so we need to
keep the entry in the profiles for arm64.
This was left as a 'TODO', but finally showed up when building the arm64 SDK.
The generic parent profile caused arm64 SDK (but also production images) to
have several USE flags missing, most importantly acl. Without acl, `usermod -m`
fails to correctly copy skeleton files when creating a new user.
Switch to parent profile to one matching the amd64 parent profile, which brings
the two arches closer together.
With `--strip-unneeded` some static symbols are also stripped from modules, making stacktraces
incomplete, and making it harder to debug kernel issues. Switch to the default setting of
`--strip-debug`, which keeps symbols intact and does not appear to lead to a measurable
size increase of the /usr partition.
`ign-converter` is now part of the Ignition codebase, it should ease the
maintaining of these patches.
Only the v24tov31 translation (and its tests) has been ported to the codebase.
Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>
It partially reverts commits 9ecbd31df40e8cf4361db7f638c089e4df3dc503
and 1b08c65f7b5797dd153898f148b98429feeacd2c. The reverted parts were
workarounds for old LTS, which used to have no run_sdk_container
stuff.
This reverts commit f008fb5883afee1d83d636a06cc9c9b192705793.
This was introduced for old LTS that didn't use submodules in
scripts. Now it's backported, so this workaround is not needed.
For the main branch (so for nightly builds) the group in
`/usr/share/flatcar/update.conf` is not "main", but "developer". This
needs a small translation when turning it into a channel
information. Without that, we are trying to checkout a nonexistent tag
named `developer-3363.0.0-…` instead of `main-3363.0.0-…`, which
fails.
In developer builds version string contains version numbers and a
build ID with plus symbol sitting between them. Git tags are formatted
in similar way, but with a dash, instead of plus. Thus the plus needs
to be replaced to obtain a proper git tag.
Put them into targets/generic profile instead of duplicating them in
amd64/generic and arm64/generic profiles. There's isn't anything
arch-specific in those USE flags.
These are not Flatcar specific modifications per se. We just bump the
version from 9.0.0099 to 9.0.0469 and drop a patch that was already
applied upstream.
These are not Flatcar specific modifications per se. We just bump the
version from 9.0.0099 to 9.0.0469 and drop a patch that was already
applied upstream.
If git show-ref returns an error, i.e. the branch already exists,
then we should not create a pull request, but simply return error.
Otherwise, the Github Actions would always try to create pull
requests even when the branch still exists.
Now that the upstream Docker 20.10.18 started building the source
with Go 1.18 instead of 1.17, we should also remove code to force
building with 1.17 and simply build with 1.18.
Otherwise the build fails like:
```
vendor/archive/tar/common.go:541:32: undefined: any
vendor/archive/tar/strconv.go:204:15: undefined: strings.Cut
vendor/archive/tar/strconv.go:254:20: undefined: strings.Cut
vendor/archive/tar/strconv.go:276:13: undefined: strings.Cut
```
See also https://github.com/moby/moby/commit/3d4616f943b3.
This pulls in https://github.com/flatcar/mayday/pull/10
to update the package name after the github org move.
It also changes the homepage to use our repo instead of the archive.
The "flatcar-linux" github org was renamed to "flatcar". There are no
github redirects in this case, thus we have to fix the links.
Left to do are the patch files.
This Flatcar dependency needs to be now explicitly pulled in the OS
since this commit: 4a06200e9d
Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>
To make Github Actions of LTS-2021 work with SDK containers,
checkout_branches needs to take an additional parameter
CHECKOUT_SCRIPTS. That defaults to true, but false only for LTS-2021.
To be able to make each apply patch script run with SDK containers,
we need to pass additional env variables like PACKAGES_CONTAINER or
SDK_NAME.
Note, in case of LTS-2021, we need to also pass CHECKOUT_SCRIPTS=false,
to make LTS-2021 run with the script run_sdk_container.
Now that Flatcar SDK does not support cork of mantle any more,
we need to migrate the Github Actions of coreos-overlay to the
new container SDK based approach.
Simply download a container image of the latest Flatcar release,
run the container, generate patches from there.
Note, since the Flatcar scripts repo of LTS-2021 still does not
have necessary Container SDK scripts like run_sdk_container, we
need to skip checking out a specific base branch in case of
LTS-2021.
Since rsync 3.2.4, IUSE_CPU_FLAGS_X86="sse2" does not exist any
more in upstream ebuilds. So it is not necessary to disable
`cpu_flags_x86_sse2` USE flag for avoiding cross toolchain build
failures.
- Fix config install paths, use systemd-tmpfiles (all configs should
be installed to /usr and tmpfiles should be used to create and fix
directory permissions instead of the ebuild's postinst.)
Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>
The m3.small.x86 instance type had no serial console output because
ttyS0 was used because the GRUB CPU check didn't trigger. It seems that
most instances had i386 reported but this new one not (maybe EFI is
used here?).
Extend the GRUB check to cover both i386 and x86_64 when setting up the
serial console. For arm64 this still shouldn't be needed and the
defaults worked so far.
- Carry over our custom tmpfiles and securetty files
- Remove /etc files and install them to /usr, use tmpfiles
- Switch /etc/login.defs edits to /usr/share/shadow/login.defs
- Drop moving passwd out of /usr since we don't have split-usr
- Drop pkg_postinst
- Make BDEPEND independent from DEPEND (The `BDEPEND` is a
build-time requirement, so it should not be included in the whole
`DEPEND` list. If it does, an installation of `sys-auth/sssd`
causes other dependencies to be installed not only in the
`/build`, but also under the SDK. That's not what we want, so we
need to exclude `BDEPEND` from the list.)
- Move runstatedir option from configure to make (Now that the
upstream sssd 2.3.1 does not support `--runstatedir` option from
its configure script, we need to remove the option, to unblock the
configure issue like `unrecognized option --runstatedir`. Instead
we need to pass `runstatedir=` to emake commands.)
- Disable realm check for nsupdate (At the moment bind-tools does
not enable `gssapi`, so its `nsupdate` tool is also not able to
run `realm` command. As a result, configure script of `sssd` fails
when running `echo realm | nsupdate`, like `syntax error`.
To avoid such issues, we need to disable the nsupdate check for
now. After we could enable `gssapi` for the SDK correctly, we can
bring back the nsupdate check in the future.)
- Add patch for CVE-2021-3621
- Set the conf dir path explicitly (Without passing the
--with-systemdconfdir flag, the configure script will query
pkg-config for the directory itself. In the cross-compilation
setup that we have, this will result in a path sysroot prepended
to the path twice. systemd.eclass has a workaround for this issue,
but it does not provide an elegant getter of the system
configuration directory, thus we call `_systemd_get_dir`
ourselves.)
- Make it compatible with newer python versions.
- Fix samba version detection by exporting the CPP variable. For
some reason it was empty after the toolchain updates.
- take care of nscd.conf via tmpfiles, add files/nscd-conf.tmpfiles.
- don't run sanity checks in pkg_pretend to prevent gcc checks when
only the binary package is installed.
- comment out 'dostrip -x' to force the OS image binaries to be stripped
- remove everything glibc wants to put under /etc since we use
baselayout to provide that
## Description
When an EC2 instance boots up with a flatcar image (even the latest) the kubelet fails.
The userdata defines (and should do so) that the `/etc/eks/bootstrap.sh` should run, which it does.
This seems to add a ExecStartPre to the kubelet.service:
`ExecStartPre=/usr/share/oem/eks/download-kubelet.sh`
Both the `bootstrap.sh` and the `download-kubelet.sh` are consistent with:
https://github.com/flatcar-linux/coreos-overlay/blob/main/coreos-base/flatcar-eks/files/bootstrap.shhttps://github.com/flatcar-linux/coreos-overlay/blob/main/coreos-base/flatcar-eks/files/download-kubelet.sh
The `download-kubelet.sh` fails with `Unsupported Kubernetes version` because in the case statement on line 24->50 (https://github.com/flatcar-linux/coreos-overlay/blob/main/coreos-base/flatcar-eks/files/download-kubelet.sh#L25) only has values for kubernetes version 1.15 -> 1.21
If I manually alter the file and add 1.22 (when I test this on 1.22.9 kubernetes version deployment) and re-run the `bootsrap.sh` it works fine as far as I can see, the node than joins the cluster and shows up as `Ready` and pods starting running on the node.
The last PR I can see on this particular thing was done about a year ago f0da7f8c9e
## Impact
No EKS support for kubernetes versions higher than 1.21
## Environment and steps to reproduce
1. **Set-up**: Create an EKS cluster with the latest flatcar AMI in the worker nodes
2. **Task**: SSH into the node (probably through a Bastion)
3. **Action(s)**: No actions needed
4. **Error**: kubelet.service fails because the download-kubelet.sh doesn't have download locations for kubernetes version above 1.21
## Expected behavior
Download locations for kubernetes versions 1.22 and 1.23 (EKS doesn't have support for 1.24 yet it seems) should be located inside the download-kubelet.sh
## Additional information
By running `aws s3 ls s3://amazon-eks/` you can list the available locations of the other versions, so for it should result in this:
``` sh
case $CLUSTER_VERSION in
1.23)
S3_PATH="1.23.9/2022-07-27/"
;;
1.22)
S3_PATH="1.22.12/2022-07-27/"
;;
1.21)
S3_PATH="1.21.2/2021-07-05"
;;
1.20)
S3_PATH="1.20.4/2021-04-12"
;;
1.19)
S3_PATH="1.19.6/2021-01-05"
;;
1.18)
S3_PATH="1.18.9/2020-11-02"
;;
1.17)
S3_PATH="1.17.12/2020-11-02"
;;
1.16)
S3_PATH="1.16.15/2020-11-02"
;;
1.15)
S3_PATH="1.15.12/2020-11-02"
;;
*)
echo "Unsupported Kubernetes version"
exit 1
;;
esac
```
We fetch the latest release of calico from calicoproject/calico
releases instead of from calico-version.yaml file in tigera/operator
repo. This is because we download the Tigera Operator manifest from
the calico repository, so we can expect that when the release happens,
both calico and the operator agree on versions used (so we expect that
calico 3.24.0 is using operator version 1.28.0, and the operator
1.28.0 is using calico 3.24.0).
Update keywords to stable amd64 and arm64.
Note, fix-dos patch is not necessary any more, because 1.3.2-r1 from
upstream Gentoo already has the patch.
Based on commit f3150e4b458e8d8979a37a91e44a7e1d2334d2aa.
and refresh other patches. The changes in PCI irq masking on hyperv resulted in
the previous set of patches not building on arm64. Resolve this by taking
another 2 patches. Patch z0006 makes the non-compiling code x86 specific
(fixing the build failure on arm64) and patch z0007 fixes a subsequent "not
used function" error.
ORIG_HEAD is the previous HEAD, so it is not what we are after. HEAD
only contains the hash if we are in a detached head situation, otherwise
it will contain a ref and we need to resolve it. `git rev-parse HEAD`
should work as well but hits an issue with git's new `safe.directory`
setting, I have not found a way to set this parameter for a signle call.
For toolchain packages are built with catalyst, and the HEAD value needs
to pre-resolved because we do not have access to the whole git
repository. So build_toolchains will need to inject the correct HEAD
file contents.
If the uri points to a path within the repo then the format is
git+https://repo@ref#path. ORIG_HEAD is actually the previous HEAD, so read
use that to extract the correct ref.
This change adds initial support for SLSA provenance report generation.
Reports are generated in package build post-install hooks after
compilation.
See https://slsa.dev/ for SLSA and https://slsa.dev/provenance/v0.2 for
the provenance report syntax.
Signed-off-by: Thilo Fromm <thilo@kinvolk.io>
Our ebuild modifies the systemd owned tmpfiles.d entry that creates the
/etc/resolv.conf symlink to point to resolv.conf instead of stub-resolv.conf.
The file that contains that entry changed from etc.conf.in to
systemd-resolve.conf, so update the ebuild to touch that file.
