WALinuxAgent falls back to using the `distro` module to figure out the
distribution details in case the `get_linux_distribution` function
from the builtin `platform` module is not able to do it. With the
update of python-oem to python3, the distribution detection broke,
because we stopped carrying a patch that implemented fetching the
distribution information from `/etc/os-release`. It does not make
sense to backport that patch though, because
`platform.get_linux_distribution` is deprecated and removed in python
3.7 or 3.8. So when we update python3 to the newer version, we would
need to add the `distro` module anyway.
Maybe we can drop `distro-oem` module in future, when python-oem will
use version 3.10 and WALinuxAgent starts using the newly added
functionality in 3.10 to figure out the distribution information.
Now that sys-apps/policycoreutils is pulled in explicitly for both
architectures, we should be able to pull in its dependencies, e.g.
sys-apps/semodule-utils, sys-libs/libselinux, sys-libs/libsemanage,
sys-libs/libsepol. In case of arm64, however, all the ebuilds have
only `~arm64`. So we need to enable the keywords for the ebuilds.
Without the changes, build fails like:
```
!!! All ebuilds that could satisfy
">=sys-libs/libselinux-3.1:=[python?,python_targets_python3_6(-)?,-python_single_target_python3_6(-)]"
for /build/arm64-usr/ have been masked.
!!! One of the following masked packages is required to complete your
request:
- sys-libs/libselinux-9999::coreos (masked by: missing keyword)
- sys-libs/libselinux-3.2::coreos (masked by: ~arm64 keyword)
- sys-libs/libselinux-3.1-r1::coreos (masked by: ~arm64 keyword)
```
Now that Kernel config `CONFIG_ICE` is enabled, its corresponding
firmware file needs to be also in place. However, upstream
linux-firmware tarball does not contain a correct symlink to
`intel/ice/ddp/ice-1.3.26.0.pkg`, but `modinfo ice.ko` shows it
requires `ice.pkg`. So we need to create the symlink to avoid failures
at the firmware scanning stage like below:
```
Missing firmware: intel/ice/ddp/ice.pkg (ice.ko.xz)
```
The image contents are defined by the list in this package and the
dependencies pulled in. Once we would lose some dependency due to
a package change, that would also meant that this dependency's
binaries are not available to the user anymore. To prevent user
binaries from being lost we have to explicitly list them in this
package.
Add the packages that have binaries relevant to the user and are
currently installed (seen in flatcar_production_image_packages.txt
and checked manually). Also add sys-apps/acl which got lost when
removing rkt.
This pulls in
https://github.com/kinvolk/init/pull/47
to randomize OEM filesystem UUID if mounting fails, and to avoid trying
to install the QEMU qcow2 images.
Current cross builds of perl segfault on simple operations such as `perl -V`.
This appears to be due to the cross-build not getting `-fwrapv -fno-strict-aliasing`
passed from the configure script. While we try to get this fixed upstream, we
can monkeypatch our old version of perl to fix this.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
This change results in building the pam_tty_audit additionally, nothing else.
Related to https://github.com/kinvolk/Flatcar/issues/485.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
It produces files with the same contents as the python2 version of the
script, but the filename handling is a bit different wrt. filenames
with weird, non-unicode characters. But overall, it does not affect
anything.
This change adds the "slirp" use flag to qemu (SDK only), enabling
qemu's user networking. This fixes a bug where qemu is unable to start
the Flatcar qemu image:
$ ./flatcar_production_qemu.sh
qemu-system-x86_64: Parameter 'type' expects a netdev backend type
The issue has been discussed on the qemu mailing list:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg786275.html
Signed-off-by: Thilo Fromm <thilo@kinvolk.io>
It contained some chromium version of flatcar scripts, from which we
were using the common.sh script in the cros-workon script (from the
now-removed coreos-base/cros-devutils package). It's not used any more
- we updated flatcar scripts to call into its internal copy of
cros-workon.
The package contained scripts that are not used in our workflow, are
unmaintained by us for a number of years now and it presents an
obstacle in porting the packages to python3.
Our scripts are using cert-to-efi-sig-list and flash-var from
efitools, and sbsign from sbsigntools. Currently the cros-devutils
package is pulling in the efitools package, which in turn pull in the
sbsigntools package.
We plan to drop the cros-devutils package, so better be explicit about
the dependencies.
