- automotive-sig - lists.centos.org

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

Re: Please create fusa-gcc-plugin repo
by Pierre-Yves Chibon 30 Jan '25

30 Jan '25

On Wed, Jan 29, 2025 at 01:07:40PM +0100, Pavel Odvody wrote: > Hey, my ACO is pavel1 > Thanks! You have been added to the group. You should visit: https://id.centos.org/gitlab to have this membership propagated to gitlab. Happy hacking! Pierre > On Wed, Jan 15, 2025 at 2:32 PM Pierre-Yves Chibon > <[1]pingou(a)pingoured.fr> wrote: > > On Wed, Jan 15, 2025 at 01:07:58PM +0100, Martin Perina wrote: > > Hi Pierre, > > Hi Martin, > > > Pavel is still not able to access the new repo. Are there any steps > he > > needs to take to become maintainer of the repo? > > Is Pavel a member of the automotive SIG? > If not, I'll need his FAS/ACO username to add him to the group on > [2]accounts.centos.org (ACO). > > Note: FAS and ACO share the same backend (2 frontend, 1 backend) so your > ACO > username is your FAS username, and vice-versa. > > Thanks, > Pierree > > > On Mon, Dec 9, 2024 at 4:17 PM Pierre-Yves Chibon > <[1][3]pingou(a)pingoured.fr> > > wrote: > > > > Hi all, > > > > The repo has been created and the SIG has been given access to > it: > > [2][4]https://gitlab.com/CentOS/automotive/src/fusa-gcc-plugin/ > > > > Sorry for the slow turn-around, > > > > Happy hacking! > > Pierre > > > > On Mon, Dec 09, 2024 at 02:14:31PM +0100, Sandro Bonazzola wrote: > > > [1]@Pierre-Yves Chibon can you help here? > > > Thanks > > > Il giorno lun 9 dic 2024 alle ore 13:01 Martin Perina > > > <[2][3][5]mperina(a)redhat.com> ha scritto: > > > > > > Hi, > > > who could help with setting up this new repo? > > > Thanks, > > > Martin > > > On Wed, Dec 4, 2024 at 4:50 PM Martin Perina > > <[3][4][6]mperina(a)redhat.com> > > > wrote: > > > > > > Hi, > > > could you please create fusa-gcc-plugin repo under > > > [4][5][7]https://gitlab.com/CentOS/automotive/src ? This > repo > > should be used > > > to upstream fusa-gcc-plugin source code. > > > The package will become part of AutoSD as soon as > packaging is > > > finished. > > > Also could you please give maintainer permissions to > Mark Kemel > > and > > > Pavel Odvody? > > > Thanks a lot, > > > Martin > > > -- > > > Martin Perina > > > Manager, Software Engineering > > > Red Hat Czech s.r.o. > > > > > > -- > > > Martin Perina > > _______________________________________________ > > automotive-sig mailing list -- > [6][8]automotive-sig(a)lists.centos.org > > To unsubscribe send an email to > [7][9]automotive-sig-leave(a)lists.centos.org > > > > -- > > Martin Perina > > Manager, Software Engineering > > Red Hat Czech s.r.o. > > > > Links: > > 1. mailto:[10]pingou@pingoured.fr/ > > 2. [11]https://gitlab.com/CentOS/automotive/src/fusa-gcc-plugin/ > > 3. mailto:[12]mperina@redhat.com/ > > 4. mailto:[13]mperina@redhat.com/ > > 5. [14]https://gitlab.com/CentOS/automotive/src > > 6. mailto:[15]automotive-sig@lists.centos.org/ > > 7. mailto:[16]automotive-sig-leave@lists.centos.org/ > > > _______________________________________________ > > automotive-sig mailing list -- [17]automotive-sig(a)lists.centos.org > > To unsubscribe send an email to > [18]automotive-sig-leave(a)lists.centos.org > > -- > [19]pavel(a)redhat.com > > Links: > 1. mailto:pingou@pingoured.fr/ > 2. http://accounts.centos.org/ > 3. mailto:pingou@pingoured.fr/ > 4. https://gitlab.com/CentOS/automotive/src/fusa-gcc-plugin/ > 5. mailto:mperina@redhat.com/ > 6. mailto:mperina@redhat.com/ > 7. https://gitlab.com/CentOS/automotive/src > 8. mailto:automotive-sig@lists.centos.org/ > 9. mailto:automotive-sig-leave@lists.centos.org/ > 10. mailto:pingou@pingoured.fr/ > 11. https://gitlab.com/CentOS/automotive/src/fusa-gcc-plugin/ > 12. mailto:mperina@redhat.com/ > 13. mailto:mperina@redhat.com/ > 14. https://gitlab.com/CentOS/automotive/src > 15. mailto:automotive-sig@lists.centos.org/ > 16. mailto:automotive-sig-leave@lists.centos.org/ > 17. mailto:automotive-sig@lists.centos.org/ > 18. mailto:automotive-sig-leave@lists.centos.org/ > 19. mailto:pavel@redhat.com/

1 0

Request new git repositories: kmod-qcom-scmi
by Eric Chanudet 30 Jan '25

30 Jan '25

Hi, I would like to request the following repos under the Automotive SIG: - https://gitlab.com/CentOS/automotive/src/kmod-qcom-scmi.git - https://gitlab.com/CentOS/automotive/rpms/kmod-qcom-scmi.git Recent BSPs are changing how some devices are initialized on some QC boards (e.g, Ride4). Until that logic is upstreamed, out-of-tree drivers from the downstream sources[1] can be used to help enablement and debugging, as well as allowing testing efforts to occur on newer firmware versions. Best, [1] https://git.codelinaro.org/clo/la/kernel/ark-5.14/-/tree/LR.AU.0.1.1.r2-166… -- Eric Chanudet

2 1

Please create fusa-gcc-plugin repo
by Martin Perina 15 Jan '25

15 Jan '25

Hi, could you please create fusa-gcc-plugin repo under https://gitlab.com/CentOS/automotive/src ? This repo should be used to upstream fusa-gcc-plugin source code. The package will become part of AutoSD as soon as packaging is finished. Also could you please give maintainer permissions to Mark Kemel and Pavel Odvody? Thanks a lot, Martin -- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.

3 5

Request new git repos
by Alexander Larsson 02 Jan '25

02 Jan '25

Hi, I'd like to request two new git repos: https://gitlab.com/CentOS/automotive/src/auto-boot-check and https://gitlab.com/CentOS/automotive/rpms/auto-boot-check -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl(a)redhat.com alexander.larsson(a)gmail.com

3 2

Request new git repos
by Alexander Larsson 17 Dec '24

17 Dec '24

Hi, I'd like to request two new git repos: https://gitlab.com/CentOS/automotive/src/auto-boot-check and https://gitlab.com/CentOS/automotive/rpms/auto-boot-check -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl(a)redhat.com alexander.larsson(a)gmail.com

1 0

Creating an Automotive SIG doc group
by Pierre-Yves Chibon 03 Dec '24

03 Dec '24

Good Morning Everyone! Until now the documentation of the SIGs have been a little bit maintained by everyone, as they saw fit and as they had time or interest in doing so. I've been contacted by a team at Red Hat who is used to working and maintaining documentation and who has offered to take the lead with our documentation. So we discussed created a dedicated Automotive SIG documentation team which would have its own group and would be in charge of the SIG's docs. In this spirit, I have asked yesterday the creation of the group: https://accounts.centos.org/group/gitlab-centos-sig-automotive-docs-maintai… Which is mapped in gitlab to: https://gitlab.com/groups/CentOS/automotive/groups/automotive-docs-maintain… and has been made maintainer of: https://gitlab.com/CentOS/automotive/sig-docs/ I realize now that it would have been good of me to announce/offer this idea up for discussion before moving ahead with this, I apologies for this. I didn't remove access to the entire SIG, so at the moment except for a new group, nothing has changed. I do think though that it would make sense, down the line, to make the automotive-sig group be developer (rather than maintainer) for the sig-docs project and only have the automotive-docs-maintainers group be maintainer. That being said, I think we should do that only once the group who is looking at our documentation has started communicated on this list about their ideas and plans :) Thoughts and feedbacks most welcome! Thanks, Pierre

2 3

2025

2024

2023

2022

2021

automotive-sig