- automotive-sig - lists.centos.org

[NOTICE] Upcoming AutoSD Webserver Downtime
by Hubert Stefański 07 May '25

07 May '25

Hi folks Hubert from the Automotive Toolchain team here, we're the folks that produce and manage the artifacts (and the associated infrastructure) that you can find on the autosd.sig.centos.org web server. We'll be performing a bit of maintenance and an upgrade to that deployment tomorrow *6th May 2025 @ 1300 CEST *see below for a handy reference for your local timezone *[1].* *What's going to change?* We'll no longer be serving the artifacts from local storage attached to the web server instance, instead we'll be using AWS CloudFront. So, instead of downloading the files directly from the web server, you'll be redirected to the relevant file in CloudFront. The aim of this change is to improve download speeds and resiliency at scale for our users. If you're simply browsing the UI through autosd.sig.centos.org you won't really notice anything out of the ordinary, we've kept the index structure as-is, what you will notice is that once you click a file download through the UI, you'll be redirected to https://download.autosd.sig.centos.org/ (with the relevant file key) so don't be surprised, or alarmed by that. However, if you're using recursive wget, or anything of that sort to fetch artifacts from autosd.sig.centos.org, you'll need to be aware that normal page crawling might not be possible, so if you intend to download a whole directory, please use the following: ``` wget autosd.stg.sig.centos.org/AutoSD-9/nightly/download.txt wget -i download.txt ``` The command above will work for all directories, and subdirectories, the download.txt file simply gathers all the file reference keys from the s3 and puts them into a single file. Likewise, if you want to download a file from that web server, all you need to do is replace `autosd.sig.centos.org/<filepath>` with ` https://download.autosd.sig.centos.org/<filepath>` This is still an early experimental version, so If you have any questions, concerns, issues, bugs or feedback, feel free to reach out*, *and we'll do our best to address it ASAP. Thank you! *[1]* Timezone Local Time *UTC (GMT)* 11:00 AM *New York (EDT)* 7:00 AM *Los Angeles (PDT)* 4:00 AM *London (BST)* 12:00 PM (Noon) *Tokyo (JST)* 8:00 PM *Sydney (AEST)* 9:00 PM *India (IST)* 4:30 PM *Dubai (GST)* 3:00 PM *Beijing (CST)* 7:00 PM Hubert stefański Senior Software Engineer Red Hat In-Vehicle OS Red Hat <https://www.redhat.com/> Remote Poland [image: Red Hat In-Vehicle Operating System logo]

1 3

aboot-deploy and aboot-update development repository request
by Ian Mullins 01 May '25

01 May '25

Hello, Can you please create two new repositories in the src namespace as seen below: - https://gitlab.com/CentOS/automotive/src/aboot-update - https://gitlab.com/CentOS/automotive/src/aboot-deploy Both the aboot-deploy and aboot-update projects currently reside in https://gitlab.com/CentOS/automotive/rpms/ , which serves both as development and dist-git repo. The new repositories are required to migrate the development of both projects, leaving the original project repositories as dist-git only. Thank you, Ian

1 0

osbuild-auto development repository request
by Mark Kemel 01 Apr '25

01 Apr '25

Hello, The osbuild-auto project currently resides in https://gitlab.com/CentOS/automotive/rpms/osbuild-auto, which serves both as development and dist-git repo. Requesting a new repository at https://gitlab.com/CentOS/automotive/src/ osbuild-auto to migrate the development of the project to, and leave the original repo as dist-git only. Thank you in advance Mark

2 1

Repository Request
by Leonardo Rossetti 01 Apr '25

01 Apr '25

Hello, I would like to request a new repository creation: https://gitlab.com/CentOS/automotive/autosd-image-score This repository will host AIB files to build an AutoSD image for the Eclipse S-CORE project. Regards, -- Leonardo Rossetti Principal Software Engineer, Red Hat <https://www.redhat.com> lrossett(a)redhat.com <https://www.redhat.com>

2 1

Request for rust-vhost-device-gpu and its deps dist-git repos
by Sandro Bonazzola 25 Mar '25

25 Mar '25

Please create rpm dist-git repos for the following packages: - rust-vhost-device-gpu - gfxstream - aemu Thanks, -- Sandro Bonazzola MANAGER, ENGINEERING Red Hat In-Vehicle Operating System Red Hat EMEA <https://www.redhat.com/> <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

2 3

Dist-git repo request for fusa-gcc-plugin
by Mark Kemel 25 Mar '25

25 Mar '25

Hi, Can we have a dist-git repo for fusa-gcc-plugin created under https://gitlab.com/CentOS/automotive/rpms ? Thank you in advance! Mark

2 1

Custom kernel build fails: rsync: Argument list too long
by Sebastian Hetze 27 Feb '25

27 Feb '25

Hi *, when trying to build the centos-stream-9 main-automotive kernel for the x86_64 architecture as described in the automotive sig documentation <https://sigs.centos.org/automotive/building/building_an_os_image_that%20use…>, it fails. The failing command appears to be /usr/bin/make -s 'HOSTCFLAGS=-O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'HOSTLDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 ' -j12 ARCH=x86_64 V=1 'TARGETS=bpf cgroup mm livepatch net net/forwarding net/mptcp netfilter tc-testing memfd drivers/net/bonding iommu cachestat drivers/net' SKIP_TARGETS= FORCE_TARGETS=1 INSTALL_PATH=/home/she/rpmbuild/BUILDROOT/kernel-automotive-5.14.0-570.518_at.el9iv.x86_64/usr/libexec/kselftests VMLINUX_H= DEFAULT_INSTALL_HDR_PATH=0 install with the error make[3]: Entering directory '/home/she/Workspace/centos-stream-9/redhat/rpm/BUILD/kernel-5.14.0-570.518_at.el9iv/linux-5.14.0-570.518_at.el9iv.x86_64/tools/testing/selftests/bpf' Auto-detecting system features: ... llvm: [ OFF ] make[3]: rsync: Argument list too long make[3]: *** [Makefile:768: test_progs-no_alu32-extras] Error 127 make[3]: Leaving directory '/home/she/Workspace/centos-stream-9/redhat/rpm/BUILD/kernel-5.14.0-570.518_at.el9iv/linux-5.14.0-570.518_at.el9iv.x86_64/tools/testing/selftests/bpf' make[2]: *** [Makefile:233: install] Error 2 This is the unmodified main-automotive branch of the current centos-stream-9 kernel on a current centos-stream-9 system. Setting ulimit -S -s unlimited for ARG_MAX 6291456 does not make any difference. It looks like the actual problem is not with the rsync command line. Any hint what is going wrong and how to proceed? Beste Grüße Sebastian Hetze -- Principal Software Engineer Red Hat GmbH. Niederlassung Berlin Leipziger Platz 16, 10117 Berlin Mobil: +49 173 8914205 E-Mail: she(a)redhat.com Registered seat: Werner von Siemens Ring 14, D-85630 Grasbrunn, Germany Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross

2 1

Re: Request for new git repos
by Pierre-Yves Chibon 26 Feb '25

26 Feb '25

On Wed, Feb 26, 2025 at 03:48:58PM +0100, Alexander Larsson wrote: > I'd lke to request two new gitlab repos: > [1]https://gitlab.com/CentOS/automotive/src/ukiboot > [2]https://gitlab.com/CentOS/automotive/rpms/ukiboot Created and fixed the sig's list address :) Pierre

1 0

Re: autosd install on x86_64 hardware
by Alexander Larsson 18 Feb '25

18 Feb '25

The current automotive images are not compatible with bootc. We hope to eventually change this, but that needs some serious engineering work. The approach for image updates in automotive is based on ostree. automotive-image-builder builds ostree commits, as well as an initial physical image containing that commit. Once the image with the initial commit is deployed, ostree is used to do the update. This happens either by pulling from an ostree repository or by side-loading an offline update file (an ostree static delta) using whatever mechanism you have available. Here are some some docs explaining how this works: https://sigs.centos.org/automotive/building/updating_ostree/#updating-ostre… https://sigs.centos.org/automotive/building/creating_static_deltas/ Also, in general the approach we the automotive images use is to produce physical images that are flashed, we don't use installers like anaconda. Installers are not really a good fit for embedded style hardware. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl(a)redhat.com alexander.larsson(a)gmail.com

2 1

autosd install on x86_64 hardware
by shetze＠redhat.com 11 Feb '25

11 Feb '25

Hi *, we are currently trying to install autosd on hardware for our railway project. x86_64 hardware is used in Deutsche Bahn rolling stock. For the Automated Train project, we want to install the CentOS autosd on a duagon G28M processor module. We intend to install a bootc container via Anaconda from an ISO image. On the running system, a rebase to a registry-based image can then be performed for (incremental) updates. Does this make sense, or is there a better approach? As far as I can see, containers or OCI images created by auto-image-builder are not recognized as bootable by bootc-image-builder. With rpm-ostree compose I can create a correct bootc container image from the auto-image-builder's ostree commit. I can perform a rebase on this image, but it doesn't boot because the commitmeta signature for ostree-prepare-root cannot be loaded. I can't make an installable ISO from the bootc container image either, because the osbuild doesn't support the autosd-9 distro. My impression is also that the containers created by the auto-image-builder contain only a single blob, so they are not suitable for incremental updates at all. So we won't reach our goal on the way decribed above. Do you have any hints, feedback or tips?

1 0

2025

2024

2023

2022

2021

automotive-sig