IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Azure skips the file permissions when upload/downloaded from the object
store. Make sure all binaries under `_out` have executable permissions.
Signed-off-by: Noel Georgi <git@frezbo.dev>
This PR updates CI to remove the immutability policy and tags the azure
"containers" (aka buckets) with a ci=true tag. This will allow us to
handle the deletion of buckets with the cloud-cleaner app.
Signed-off-by: Spencer Smith <spencer.smith@talos-systems.com>
Add cilium e2e tests. The existing cilium check was very old, update to
latest cilium version and also add a test for KPR strict mode.
Signed-off-by: Noel Georgi <git@frezbo.dev>
If we don't pre-build, it's getting built each time the `e2e-*` step
runs, and we have some running in parallel.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Use boot kernel arg `talos.unified_cgroup_hierarchy=0` to force Talos to
use cgroups v1. Talos still defaults to cgroupsv2.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
There's a cyclic dependency on siderolink library which imports talos
machinery back. We will fix that after we get talos pushed under a new
name.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This commit adds support for building Talos for the
Compute Module 4 and other generic Raspberry Pi
hardware.
Fixes: #6273
Signed-off-by: Kris Reeves <kris@pressbuttonllc.com>
Signed-off-by: Noel Georgi <git@frezbo.dev>
Don't skip pods which are not ready, try still to stop containers inside
not ready pod sandboxes.
Re-enable the test with Canal CNI (upstream Calico got fixed).
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This commit adds initial support for the Nano Pi
R4S from Friendlyelec. This device is a networking focused
rk3399 based SBC with two 1G ethernet interfaces,
making it perfect for edge or SOHO deployments.
Signed-off-by: Marvin Drees <marvin.drees@9elements.com>
Signed-off-by: Noel Georgi <git@frezbo.dev>
Fixes#6119
With new stable default hostname feature, any default hostname is
disabled until the machine config is available.
Talos enters maintenance mode when the default config source is empty,
so it doesn't have any machine config available at the moment
maintenance service is started.
Hostname might be set via different sources, e.g. kernel args or via
DHCP before the machine config is available, but if all these sources
are not available, hostname won't be set at all.
This stops waiting for the hostname, and skips setting any DNS names in
the maintenance mode certificate SANs if the hostname is not available.
Also adds a regression test via new `--disable-dhcp-hostname` flag to
`talosctl cluster create`.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This PR adds support for building talosctl for FreeBSD on
amd64 and arm64 architectures.
It also pulls in the latest go-blockdevice library to ensure the FreeBSD
stubs are there for proper build.
Signed-off-by: Spencer Smith <spencer.smith@talos-systems.com>
This change replaces the gzipped tar with a gzipped image, which
DigitalOcean natively supports uploading, and means that it can be
linked directly to the image when using, for example, Terraform.
Signed-off-by: Ryan Heywood <me@ryansquared.pub>
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
It wasn't used when building an endpoint to the local API server, so
Talos couldn't talk to the local API server when port was changed from
the default one.
Fixes#5706
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Uses Sidero Labs d2ctl to install a small sample of
common cluster services to ensure the Talos cluster
is capable.
Signed-off-by: Tim Jones <tim.jones@siderolabs.com>
This is needed to make sure that those steps don't run in parallel on
release builds, as they write same output files.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Fixes#4947
It turns out there's something related to boot process in BIOS mode
which leads to initramfs corruption on later `kexec`.
Booting via GRUB is always successful.
Problem with kexec was confirmed with:
* direct boot via QEMU
* QEMU boot via iPXE (bundled with QEMU)
The root cause is not known, but the only visible difference is the
placement of RAMDISK with UEFI and BIOS boots:
```
[ 0.005508] RAMDISK: [mem 0x312dd000-0x34965fff]
```
or:
```
[ 0.003821] RAMDISK: [mem 0x711aa000-0x747a7fff]
```
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Fixes#4694
User services run alongside with Talos system services.
Every user service container root filesystem should be already present
in the Talos root filesystem.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
As `_out` is a shared volume across Drone steps, we should prefetch CLI
dependencies early, as fetching them concurrently from multiple steps
might lead to surpising results.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Fixes#4816
This changes the way system extensions are packaged into the squashfs
images: `/lib/firmware` is now moved out of the future squashfs images
and becomes part of `initramfs` to make firmware available in the early
boot.
Talos will bind-mount `/lib/firmware` into rootfs as well, so it will be
available in the rootfs as well.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Instead, build all images for a release and in the integration pipeline
which is triggered `nightly` and can be promoted to with
`/promote integration-images`.
This saves time and resources on regular builds.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
The `installer` image is used for initial install and upgrades, so it
contains only Talos artifacts for the same arch as the image
The `imager` image is used to produce Talos images, so it contains artifacts
for all arhitectures, so that it's possible e.g. to build Raspberry PI
Talos image on amd64 machine
Unpacked size comparison for amd64 (before this change, size of
`installer` was same as `imager` size):
```
REPOSITORY TAG IMAGE ID CREATED SIZE
ghcr.io/smira/installer v0.14.0-alpha.2-8-g73293bc2-dirty 264995cf56df 4 minutes ago 176MB
ghcr.io/smira/imager v0.14.0-alpha.2-8-g73293bc2-dirty 3ba8e0176565 6 minutes ago 616MB
```
As the `installer` image is pulled into `tmpfs` on upgrade, it's important
to have it as small as possible to avoid putting too much pressure on
node memory.
Both images are generated anyways for both `amd64` and `arm64` target
architectures.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This fixes the issue with kubelet picking up wrong IP on restart, as
Talos doesn't know pod IPs (Cilium is using its own pod CIDR, it doesn't
look up Kubernetes settings).
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This enables cluster discovery by default for Talos 0.14. KubeSpan is
not enabled by default.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Our CI amd64 builders are 3-4 times faster to build Talos than our arm64
builders when building Talos.
Our Dockerfile was restructured a while ago to support cross-compilation
on all platforms but CI was still using amd64/arm64 workers, so arm64
part was done on arm64 builders.
As our CI runs on Talos, `binfmt_misc` is not enabled in the kernel, but
buildkit has built-in QEMU emulation layer which works just fine for
those small pieces which actually need to run arm64 binaries on amd64
(mostly `apk add` in the installer container). Interesting enough,
buildkit QEMU support fails for `ca-certificates` script which runs
after install. At the same time I believe we don't need
`ca-certificates` in the installer, as installer doesn't download
anything from the network, and `ca-certificates` were added a while ago
when installer was actually downloading configuration on its own.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
