Hoi,
> Hi,
>
> Johannes, what's the status of this patchset?
the status is: it's working (locally) since around v6
but some combination of the testing CI where failing, which led to back-n-forth
up to v11
which was AFAICT almost there, but then the patchstack was dropped :'-(
> I'd like to star
:'-(
> I'd like to start experimenting
> with system extensions and this looks like the place to start.
please do, more voices that use the feature might get it picked up again :-)
>
>/Ola
On Wed, May 22 2024, Johannes Schneider via lists.openembedded.org wrote:
> system
The bpf-framework is used to pre-compile eBPFs that required for the
systemd.resource-control features RestrictFileSystems=[1] and
RestrictNetworkInterfaces=[2] to work.
Apart from 'clang-native' to compile the eBPFs, the required kernel
switches are described in [3].
Link:
https://www.freedeskt
Systemd has eBPF based resource-control features to limit file-system
and network-interface access [1][2]
For these to be usable the corresponding eBPFs that come with systemd
need to be compiled an deployed to the system - this could now be done
by setting the PACKAGECONFIG+="bpf-framework" in th
Pass the "recipe-sysroot" path via the CFLAGS=--sysroot= to the
compiler used by systemd to build the BPF, so that it can find the
needed system includes.
Signed-off-by: Johannes Schneider
---
meta/recipes-core/systemd/systemd_255.6.bb | 4
1 file changed, 4 insertions(+)
diff --git a/meta
The eBPFs are pre-compiled during the systemd-build with a different
compiler than the cross-compiler used to build systemd itself.
This is either a 'clang-native' or a gcc (bpf-unknown-none) which do
not see the BUILD_CFLAGS, that point to the correct include search
patch. To address this have sy
Hoi,
> >
> > I went to have a quick look at this but can’t built bpftool:
> >
> > ERROR: bpftool-native-1.0-r0 do_compile: oe_runmake failed
> > ERROR: bpftool-native-1.0-r0 do_compile:
> > ExecutionError('/work/ross/build/tmp/work/aarch64-linux/bpftool-native/1.0/temp/run.do_compi)
> > ERROR: Lo
Hoi,
and thanks for taking the time to look into this patch-set!
>
> Hello,
>
> On 13/06/2024 07:44:59+0100, Richard Purdie wrote:
> > On Tue, 2024-06-04 at 08:50 +0200, Johannes Schneider wrote:
> > > systemd-sysext allows to overlay another image (or multiple) ontop of
> > > a "base-image" =
The eBPFs are pre-compiled during the systemd-build with a different
compiler than the cross-compiler used to build systemd itself.
This is either a 'clang-native' or a gcc (bpf-unknown-none) which do
not see the BUILD_CFLAGS set -isystem ${STAGING_INCDIR}. For this the
meson.build file constructi
The bpf-framework is used to pre-compile eBPFs that required for the
systemd.resource-control features RestrictFileSystems=[1] and
RestrictNetworkInterfaces=[2] to work.
Apart from 'clang-native' to compile the eBPFs, the required kernel
switches are described in [3].
Link:
https://www.freedeskt
The eBPFs are pre-compiled during the systemd-build with a different
compiler than the cross-compiler used to build systemd itself.
This is either a 'clang-native' or a gcc (bpf-unknown-none) which do
not see the BUILD_CFLAGS set -isystem ${STAGING_INCDIR}. For this the
meson.build file constructi
Systemd has eBPF based resource-control features to limit file-system
and network-interface access [1][2]
For these to be usable the corresponding eBPFs that come with systemd
need to be compiled an deployed to the system - this could now be done
by setting the PACKAGECONFIG+="bpf-framework" in th
systemd-sysext can load a raw-image containing usr/ and opt/ folders
to mount them as RO overlay over the rootfs, to "extend" the systems.
This class provides the necessary changes/additions to the enclosed
file-system so that systemd-sysext accepts the extension for "merge"
into the rootfs.
With
set the package-database of a "lower image" to unpack and build upon
when installing packages for the current image. This way a lean image
will be created, which only holds the packages that are not already
present in the lower image.
An image build such could then be used with overlayfs or system
archive the package database after the rootfs has been put together as
*rootfs-pkdbfs.tar.gz, and put it into the deploy folder.
This creates a snapshot of the package mangers state at the point in
time when all dependencies have been resolved and installed; which
could be used by "extension image
systemd-sysext allows to overlay another image (or multiple) ontop of
a "base-image" = the current rootfs, via the use of overlayfs; to add
tools and features meant for development purposes.
To quote the documentation on systemd-sysext:
" ...addition in order to make debugging/development easier).
ps://autobuilder.yoctoproject.org/typhoon/#/builders/127/builds/3398/steps/15/logs/stdio
On 22/05/2024 16:11:49+0200, Johannes Schneider via lists.openembedded.org
wrote:
> systemd-sysext allows to overlay another image (or multiple) ontop of
> a "base-image" = the current rootfs, via
archive the package database after the rootfs has been put together as
*rootfs-pkdbfs.tar.gz, and put it into the deploy folder.
This creates a snapshot of the package mangers state at the point in
time when all dependencies have been resolved and installed; which
could be used by "extension image
set the package-database of a "lower image" to unpack and build upon
when installing packages for the current image. This way a lean image
will be created, which only holds the packages that are not already
present in the lower image.
An image build such could then be used with overlayfs or system
systemd-sysext can load a raw-image containing usr/ and opt/ folders
to mount them as RO overlay over the rootfs, to "extend" the systems.
This class provides the necessary changes/additions to the enclosed
file-system so that systemd-sysext accepts the extension for "merge"
into the rootfs.
With
systemd-sysext allows to overlay another image (or multiple) ontop of
a "base-image" = the current rootfs, via the use of overlayfs; to add
tools and features meant for development purposes.
To quote the documentation on systemd-sysext:
" ...addition in order to make debugging/development easier).
atabase and systemd-sysext image
>
> This email is not from Hexagon’s Office 365 instance. Please be careful while
> clicking links, opening attachments, or replying to this email.
>
>
> Hello,
>
> deb and rpm seem successful but ipk still fails:
>
> https://autobu
seem successful but ipk still fails:
https://autobuilder.yoctoproject.org/typhoon/#/builders/127/builds/3335/steps/14/logs/stdio
On 16/05/2024 00:34:57+0200, Johannes Schneider via lists.openembedded.org
wrote:
> systemd-sysext allows to overlay another image (or multiple) ontop of
> a &quo
g attachments, or replying to this email.
Hello,
It seems that this reliably fails oe-selftest-armhost. I didn't really
pay attention until now beause we had other issues but in this build,
those are the only failing tests:
https://autobuilder.yoctoproject.org/typhoon/#/builders/127/build
systemd-sysext can load a raw-image containing usr/ and opt/ folders
to mount them as RO overlay over the rootfs, to "extend" the systems.
This class provides the necessary changes/additions to the enclosed
file-system so that systemd-sysext accepts the extension for "merge"
into the rootfs.
With
set the package-database of a "lower image" to unpack and build upon
when installing packages for the current image. This way a lean image
will be created, which only holds the packages that are not already
present in the lower image.
An image build such could then be used with overlayfs or system
archive the package database after the rootfs has been put together as
*rootfs-pkdbfs.tar.gz, and put it into the deploy folder.
This creates a snapshot of the package mangers state at the point in
time when all dependencies have been resolved and installed; which
could be used by "extension image
systemd-sysext allows to overlay another image (or multiple) ontop of
a "base-image" = the current rootfs, via the use of overlayfs; to add
tools and features meant for development purposes.
To quote the documentation on systemd-sysext:
" ...addition in order to make debugging/development easier).
systemd-sysext can load a raw-image containing usr/ and opt/ folders
to mount them as RO overlay over the rootfs, to "extend" the systems.
This class provides the necessary changes/additions to the enclosed
file-system so that systemd-sysext accepts the extension for "merge"
into the rootfs.
With
systemd-sysext allows to overlay another image (or multiple) ontop of
a "base-image" = the current rootfs, via the use of overlayfs; to add
tools and features meant for development purposes.
To quote the documentation on systemd-sysext:
" ...addition in order to make debugging/development easier).
archive the package database after the rootfs has been put together as
*rootfs-pkdbfs.tar.gz, and put it into the deploy folder.
This creates a snapshot of the package mangers state at the point in
time when all dependencies have been resolved and installed; which
could be used by "extension image
set the package-database of a "lower image" to unpack and build upon
when installing packages for the current image. This way a lean image
will be created, which only holds the packages that are not already
present in the lower image.
An image build such could then be used with overlayfs or system
Hoi
>
> This still fails on the autobuilders, I'm pretty sure the config for the
> build folder has:
> PACKAGE_CLASSES = "package_rpm"
>
aha! that is the missing puzzle piece - thanks!
thought i read somewhere that ipk is the default and geared the tests towards
that... "always check yous assum
systemd-sysext allows to overlay another image (or multiple) ontop of
a "base-image" = the current rootfs, via the use of overlayfs; to add
tools and features meant for development purposes.
To quote the documentation on systemd-sysext:
" ...addition in order to make debugging/development easier).
systemd-sysext can load a raw-image containing usr/ and opt/ folders
to mount them as RO overlay over the rootfs, to "extend" the systems.
This class provides the necessary changes/additions to the enclosed
file-system so that systemd-sysext accepts the extension for "merge"
into the rootfs.
With
set the package-database of a "lower image" to unpack and build upon
when installing packages for the current image. This way a lean image
will be created, which only holds the packages that are not already
present in the lower image.
An image build such could then be used with overlayfs or system
archive the package database after the rootfs has been put together as
*rootfs-pkdbfs.tar.gz, and put it into the deploy folder.
This creates a snapshot of the package mangers state at the point in
time when all dependencies have been resolved and installed; which
could be used by "extension image
le
clicking links, opening attachments, or replying to this email.
On 15/04/2024 08:02:00+0200, Johannes Schneider via lists.openembedded.org
wrote:
> systemd-sysext allows to overlay another image (or multiple) ontop of
> a "base-image" = the current rootfs, via the use of o
systemd-sysext allows to overlay another image (or multiple) ontop of
a "base-image" = the current rootfs, via the use of overlayfs; to add
tools and features meant for development purposes.
To quote the documentation on systemd-sysext:
" ...addition in order to make debugging/development easier).
set the package-database of a "lower image" to unpack and build upon
when installing packages for the current image. This way a lean image
will be created, which only holds the packages that are not already
present in the lower image.
An image build such could then be used with overlayfs or system
archive the package database after the rootfs has been put together as
*rootfs-pkdbfs.tar.gz, and put it into the deploy folder.
This creates a snapshot of the package mangers state at the point in
time when all dependencies have been resolved and installed; which
could be used by "extension image
systemd-sysext can load a raw-image containing usr/ and opt/ folders
to mount them as RO overlay over the rootfs, to "extend" the systems.
This class provides the necessary changes/additions to the enclosed
file-system so that systemd-sysext accepts the extension for "merge"
into the rootfs.
With
archive the package database after the rootfs has been put together as
*rootfs-pkdbfs.tar.gz, and put it into the deploy folder.
This creates a snapshot of the package mangers state at the point in
time when all dependencies have been resolved and installed; which
could be used by "extension image
systemd-sysext can load a raw-image containing usr/ and opt/ folders
to mount them as RO overlay over the rootfs, to "extend" the systems.
This class provides the necessary changes/additions to the enclosed
file-system so that systemd-sysext accepts the extension for "merge"
into the rootfs.
With
set the package-database of a "lower image" to unpack and build upon
when installing packages for the current image. This way a lean image
will be created, which only holds the packages that are not already
present in the lower image.
An image build such could then be used with overlayfs or system
systemd-sysext allows to overlay another image (or multiple) ontop of
a "base-image" = the current rootfs, via the use of overlayfs; to add
tools and features meant for development purposes.
To quote the documentation on systemd-sysext:
" ...addition in order to make debugging/development easier).
lse is not true : opkg's status file was not present in:
/home/pokybuild/yocto-worker/oe-selftest-centos/build/build-st-3332915/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs-pkgdb.tar.gz
On 04/03/2024 07:15:50+0100, Johannes Schneider via lists.openembedded.org
wrote:
> sy
king links, opening attachments, or replying to this email.
There is a feature freeze now, so this might have to wait for after that.
Alex
On Mon, 4 Mar 2024 at 07:16, Johannes Schneider via
lists.openembedded.org
wrote:
>
> systemd-sysext allows to overlay another image (or multiple) on
systemd-sysext allows to overlay another image (or multiple) ontop of
a "base-image" = the current rootfs, via the use of overlayfs; to add
tools and features meant for development purposes.
To quote the documentation on systemd-sysext:
" ...addition in order to make debugging/development easier).
systemd-sysext can load a raw-image containing usr/ and opt/ folders
to mount them as RO overlay over the rootfs, to "extend" the systems.
This class provides the necessary changes/additions to the enclosed
file-system so that systemd-sysext accepts the extension for "merge"
into the rootfs.
With
set the package-database of a "lower image" to unpack and build upon
when installing packages for the current image. This way a lean image
will be created, which only holds the packages that are not already
present in the lower image.
An image build such could then be used with overlayfs or system
archive the package database after the rootfs has been put together as
*rootfs-pkdbfs.tar.gz, and put it into the deploy folder.
This creates a snapshot of the package mangers state at the point in
time when all dependencies have been resolved and installed; which
could be used by "extension image
systemd-sysext allows to overlay another image (or multiple) ontop of
a "base-image" = the current rootfs, via the use of overlayfs; to add
tools and features meant for development purposes.
To quote the documentation on systemd-sysext:
" ...addition in order to make debugging/development easier).
systemd-sysext can load a raw-image containing usr/ and opt/ folders
to mount them as RO overlay over the rootfs, to "extend" the systems.
This class provides the necessary changes/additions to the enclosed
file-system so that systemd-sysext accepts the extension for "merge"
into the rootfs.
With
systemd-sysext can load a raw-image containing usr/ and opt/ folders
to mount them as RO overlay over the rootfs, to "extend" the systems.
This class provides the necessary changes/additions to the enclosed
file-system so that systemd-sysext accepts the extension for "merge"
into the rootfs.
With
set the package-database of a "lower image" to unpack and build upon
when installing packages for the current image. This way a lean image
will be created, which only holds the packages that are not already
present in the lower image.
An image build such could then be used with overlayfs or system
systemd-sysext allows to overlay another image (or multiple) ontop of
a "base-image" = the current rootfs, via the use of overlayfs; to add
tools and features meant for development purposes.
To quote the documentation on systemd-sysext:
" ...addition in order to make debugging/development easier).
archive the package database after the rootfs has been put together as
*rootfs-pkdbfs.tar.gz, and put it into the deploy folder.
This creates a snapshot of the package mangers state at the point in
time when all dependencies have been resolved and installed; which
could be used by "extension image
Hoi Richard,
and thanks for the feedback!
>> archive the package database after the rootfs has been put together as
>> *rootfs-pkdbfs.tar.gz, and put it into the deploy folder.
>>
>> This creates a snapshot of the package mangers state at the point in time
>> when
>> all dependencies have been r
Hoi Richard,
and thanks for the feedback!
your other mail is still being processed, but to get already back to you on
this one:
>> set the package-database of a "lower image" to unpack and build upon when
>> installing packages for the current image. This way a lean image will be
>> created, whi
>From 0013c8a6482018d5476e4eb2f4d537c96551e0c6 Mon Sep 17 00:00:00 2001
From: Johannes Schneider
Date: Fri, 13 Oct 2023 08:28:38 +0200
Subject: [PATCH v1] base-files: profile: allow profile.d to set EDITOR
With a profile.d configuration in place that sets the EDITOR variable,
the automatic termin
Hi,
v4 adds a variant for sysv - when/if using util-linux getty, since busybox does
not seem to support an autologin option
also adds some documentation to the bbclass
regards
From: Johannes Schneider
Sent: Tuesday, August 2, 2022 11:40
To: openembedded-core@lis
when empty-root-password AND serial-autologin-root are part of the
IMAGE_FEATURES, save some of the developers time by not having to type
the (then still sole) 'root' username on the serial console after each
and every reboot
this is done by inserting '--autologin root' into the command line of
th
good question, haven't had a sysvinit system in ages... so no easy "let's test
it on this platform" :-s
do you happen to have one?
should the patch include a warning to sysvinit users like "not supported"
"config switch only applies to systemd" ... suggestions? (-:
the only sysvinit+getty refe
his email.
On Wed, Jul 27, 2022 at 5:37 AM Johannes Schneider via
lists.openembedded.org
wrote:
>
> when empty-root-password AND serial-autologin-root are part of the
> IMAGE_FEATURES, save some of the developers time by not having to type
> the (then still sole) 'root' user
when empty-root-password AND serial-autologin-root are part of the
IMAGE_FEATURES, save some of the developers time by not having to type
the (then still sole) 'root' username on the serial consoleafter each
and every reboot
this is done by inserting '--autologin root' into the command line of
the
when empty-root-password AND serial-autologin-root are part of the
IMAGE_FEATURES, save some of the developers time by not having to type
the (then still sole) 'root' username on the serial consoleafter each
and every reboot
this is done by inserting '--autologin root' into the command line of
the
when debug-tweaks or empty-root-password are part of the
IMAGE_FEATURES, save some of the developers time by not having to type
the (then still sole) 'root' username on the serial consoleafter each
and every reboot
by inserting '--autologin root' into the command line of the
responsible 'getty' se
68 matches
Mail list logo
