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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
"ninja -C build mkosi" doesn't actually work and fails because ninja
thinks the mkosi target does not exist. "meson compile -C build mkosi"
dpes work so let's use that instead.
Fixes#35741
We carry our own definitions in missing_mman.h, and otherwise
sys/mman.h is employed. Let's drop the unneeded detection/inclusion
of linux/memfd.h hence.
New version of mdadm now asks a second question, so send 'y' twice
to it in the test scripts
[ 5.253483] TEST-64-UDEV-STORAGE.sh[684]: + echo y
[ 5.254412] TEST-64-UDEV-STORAGE.sh[685]: + mdadm --create /dev/md/mdmirror --name mdmirror --uuid aaaaaaaa:bbbbbbbb:cccccccc:00000001 /dev/disk/by-id/scsi-0systemd_foobar_deadbeefmdadm0 /dev/disk/by-id/scsi-0systemd_foobar_deadbeefmdadm1 -v -f --level=1 --raid-devices=2
[ 5.254759] TEST-64-UDEV-STORAGE.sh[685]: To optimalize recovery speed, it is recommended to enable write-indent bitmap, do you want to enable it now? [y/N]? mdadm: Note: this array has metadata at the start and
[ 5.255085] TEST-64-UDEV-STORAGE.sh[685]: may not be suitable as a boot device. If you plan to
[ 5.255418] TEST-64-UDEV-STORAGE.sh[685]: store '/boot' on this device please ensure that
[ 5.255745] TEST-64-UDEV-STORAGE.sh[685]: your boot-loader understands md/v1.x metadata, or use
[ 5.256285] TEST-64-UDEV-STORAGE.sh[685]: --metadata=0.90
[ 5.256672] TEST-64-UDEV-STORAGE.sh[685]: mdadm: size set to 64512K
[ 5.257063] TEST-64-UDEV-STORAGE.sh[685]: Continue creating array [y/N]? mdadm: create aborted.
This is backward compatible with the older version that asks just one
question
Otherwise, we see "WARNING: failed to open /dev/btrfs-control,
skipping device registration: Operation not permitted" in systemd-homed's
logs when creating a btrfs on luks home.
Let's implement the spec more comprehensively.
This is piece by piece work, There's more to do on the EFI side before
all CHID types are supported, but in userspace it should be reasonably
complete now.
Let's use "mkosi sandbox" in the docs so that users can build systemd
without having to install anything except mkosi. Using mkosi sandbox
will use tools and dependencies from the tools tree which is also used
in CI and thus has a higher chance of working from the first try compared
to whatever tools might be installed on the host system of a new contributor.
Building systemd with mkosi generally requires a very recent version
of systemd which might not be installed on the host. Let's configure
mkosi to look for extra executables in the build/ directory by default
so that we prefer systemd executables from the build directory over those
on the host as those on the host are likely to be too old.
Let's enable usage of a tools tree by default to simplify the setup
for new contributors and save them from having to install or upgrade
a bunch of extra tools to get mkosi working as expected.
We need packages from EPEL to be able to build CentOS Stream images
with a CentOS Stream tools tree so enable it. This is broken on CentOS
Stream 10 but given using a CentOS Stream tools tree is broken without
EPEL as well, we might as well enable it and just wait until the packages
are added to EPEL 10.
This add he missing CHID types to our tables, but doesn't add all
necessary code to calculate them yet.
This brings us closer to what the CHID spec documents, and what
"fupwdtool hwids" outputs.
Some of the field names between kernel and smbios spec differ. Kinda
confusing. Let's use the smbios field names, to match the CHID spec,
which also uses them, and thus be least confusing, treating kernel
attribute fields as an internal Linux thing only.
As per previous commit, accept that not all SMBIOS fields are alwaysa
available (or set, but empty), hence handle this gracefully and don't
generate relevant CHIDs, as per docs.
And the CHID documentation says that CHIDs that require fields that are
not available on the local system should not be generated. Follow that,
and generate a NULL CHID in that case (which we generally ignore
otherwise).
We nowadays support unprivileged invocation of systemd-nspawn +
systemd-vmspawn, but there was no support for discovering suitable disk
images (i.e. no per-user counterpart of /var/lib/machines). Add this
now, and hook it up everywhere.
Instead of hardcoding machined's, importd's, portabled's, sysupdated's
image discovery to RUNTIME_SCOPE_SYSTEM I introduced a field that make
the scope variable, even if this field is always initialized to
RUNTIME_SCOPE_SYSTEM for now. I think these four services should
eventually be updated to support a per-user concept too, this is
preparation for that, even though it doesn't outright add support for
this.
This is for the largest part not user visible, except for in nspawn,
vmspawn and the dissect tool. For the latter I added a pair of
--user/--system switches to select the discovery scope.
When I added support for unprivileged credentials I apparently never
hooked them up to service management correctly. Let's fix that.
Fixes: #33796#33318