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.
It is quite a bit of data to download for no real reason. We are
trying to update packages here, so we will be grabbing them from the
most recent commit that made the changes to the package. With the
advancement the package updates effort, we possibly can later lower
the number of the fetched commits even further.
Packages (and eclasses) in Gentoo are sometimes moved around or
completely removed. It's good to know about this when it happens,
because such package won't be updated any more, so print a warning.
Packages in the list are not necessarily packages only, which are
represented as directories (like sys-apps/systemd), but also, in case
of eclasses, plain files. The check was checking for the path to be a
directory and emitted the warning if it was not, which resulted in
eclasses being kept not updated. Just check if the path exists.
The workflow was inconsistent with usage of actions/checkout. The
first checkout used v3, whereas the next two - v2. These are the same,
but v3 runs on currently supported node 16. Using v2 emits
warnings. To avoid them, update the action versions to v3.
- add static-libs, openmp
'static-libs' and 'opempn' are added to the bootstrap emerge USE
flags (stage 3 of the bootstrap-sh script, which is run in stage 2
of the SDK catalyst bootstrapping process):
- 'static-libs' un-breaks the zlib build: zlib installed has this
flag set and zlib requested per emerge command line in
bootstrap.sh stage 3 needs this flag to prevent a slot conflict.
- 'openmp' is to honor requirements of newer versions of GCC and is
added according to Gentoo guidelines published here:
https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki%27s_EFI_Install_Guide/Building_the_Gentoo_Base_System_Minus_Kernel#Gentoo_Bootstrap_Remix:_Progressing_from_Stage_1_to_Stage_2
- install curl before baselayout
Now that Github rejects access to an unauthenticated URL with
`git://`, we have to make git and libcurl work with
`https://`. However, during the SDK stage2, curl is not explicitly
installed, but just inherited from the stage1. As a result, curl is
built without the `ssl` USE flag. So installation of baselayout
fails with:
```
git fetch https://github.com/flatcar-linux/baselayout.git --prune +HEAD:refs/git-r3/HEAD
fatal: unable to access 'https://github.com/flatcar-linux/baselayout.git/':
Protocol "https" not supported or disabled in libcurl
```
To resolve the issue, we need to install curl with `BOOTSTRAP_USE=ssl`
before trying to install baselayout.
- update openssl before stage3
Right now our bootstrap flow is different then gentoo's - we don't
update the seed when building stage1 and use a different ebuilds
snapshot for stage1 compared to stage2 and stage3. This is causing
us trouble now, because we introduced openssl-3, but seed/stage1
still contains openssl-1.1. During `emerge -e @system` in stage3,
some packages that depend on openssl may build against the stage1
version, which results in an error during depcleaning (they would
need to be rebuilt instead). Stage3 is not extensible, so instead,
explicitly update openssl in stage2. This workaround can be removed
as soon as we release a seed with openssl-3.
Co-authored-by: Dongsu Park <dpark@linux.microsoft.com>
Co-authored-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
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
