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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
systemd-boot expects being loaded from ESP and is quite unhappy in case
the loaded image device path is something else. When running on qemu
this can easily happen though. Case one is direct kernel boot, i.e.
loading via 'qemu -kernel systemd-bootx64.efi'. Case two is sd-boot
being added to the ovmf firmware image and being loaded from there.
This patch detects both cases and goes inspect all file systems known to
the firmware, trying to find the ESP. When present the
VMMBootOrderNNNN variables are used to inspect the file systems in the
given order.
* Fix reading /etc/machine-id in kernel-install
The kernel-install script has code to read the contents of
/etc/machine-id into the MACHINE_ID variable. Depending
on the variable content kernel-install either logs the
value or creates a new machine id via 'systemd-id128 new'.
In that logic there is one issue. If the file /etc/machine-id
exists but is empty, the script tries to call read on an
empty file which return with an exit code != 0. As the
script code also uses 'set -e', kernel-install will exit at
this point which is unexpected.
The condition of an empty /etc/machine-id file exists for
example when building OS images, which should initialize the
system id on first boot but not staticly inside of the image.
afaik an empty /etc/machine-id is also a common approach
to make systemd indicate that it should create a new system
id. Because of this, the commit makes sure the reading of
/etc/machine-id does not fail in any case such that the
handling of the MACHINE_ID variable takes place.
Let's add some extra validation before constructing and using the .so
name to load. This isn't really security sensitive, given that we
used secure_getenv() to get the device string (and it thus should have
been come from a trusted source) but let's better be safe than sorry.
Apparently some distros default to tss-abmrd. Let's bypass that and
always go to the kernel resource manager.
abmrd cannot really work for us, since we want to access the TPM already
in earliest boot i.e. in environments the abmrd service is not available
in.
Fixes: #25352
To make sure rootless mode keeps working, let's run all repart
integration tests that we can without root privileges. The only ones
we need to keep running with root privileges are the tests that operate
on a block/loop device and those that use --image=.
When repart is not operating on a block device, if we avoid using
any loop devices at all, it becomes possible to run repart without
needing root privileges.
Note that this also depends on the filesystems in use to support
population without needing root privileges (specifically, squashfs,
ext4 or btrfs).
By forking off a user namespace before running mkfs and ID mapping
the user running repart to root in the user namespace, we can make
sure that files in the generated filesystems are all owned by root
instead of the user running repart.
To make this work we have to make sure that all the files in the
root directory that's passed to the mkfs binary are owned by the
user running repart, so we have to drop the shortcut for only a
single root directory in partition_populate_directory().
Offline encryption can be done without mounting the luks device. For
now we still use loop devices to split out the partition we want to
write to but in a later commit we'll replace this with a regular file.
For offline encryption, we need to keep 2x the luks header size space
free at the end of the partition, so this means our encrypted partitions
will be 16M larger than before.
mkfs.vfat doesn't support specifying a root directory to bootstrap
the filesystem from (see https://github.com/dosfstools/dosfstools/issues/183).
Instead, we can use the mcopy tool from the mtools package to copy
files into the vfat filesystem after creating it without needing to
mount the vfat filesystem.
Let's allow filtering the partitions to operate on by partition
type UUID. This is necessary when building bootable images with a
verity protected root/usr partition as we can only build the UKI
image when we have the verity roothash which means we cannot populate
the EFI partition yet when we run repart initially to determine the
verity roothash.
If we skip some partition types in a first run of systemd-repart,
we don't want their partition numbers to be different than usual,
so let's change the allocation of partition numbers to account for
that.
Instead of exposing just the partition type UUID, let's expose the
GptPartitionType struct, which has a lot more information available
in a much more accessible way.
Also, let's get rid of SECONDARY/OTHER in PartitionDesignator. These
were only there to support preferred architectures in dissect-image.c,
but we can easily handle that by comparing architectures when we decide
whether to override a partition. This is done in a new function
compare_arch().
A copy paste error has crippled in the objcopy example in 'systemd-measure'
manual, "--change-section-vma" should reference the section being added,
not ".splash". When used as-is, the resulting UKI is unbootable.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
In provision.conf we ship:
d- /root :0700 root :root -
d- /root/.ssh :0700 root :root -
These are allowed to fail, for example on a read-only filesystem. But they still
log at error level, which is annoying and gets flagged. Tune those specific errors
down to info.
There are likely more that could be tuned down, but the important thing is to cover
the tmpfiles.d that we ship right now.
Before:
$ echo -e "d- /root :0700 root :root - \nd- /root/.ssh :0700 root :root -" | SYSTEMD_LOG_LEVEL=err build/systemd-tmpfiles --root=/tmp/img --create -
Failed to create directory or subvolume "/tmp/img/root": Read-only file system
Failed to open path '/tmp/img/root': No such file or directory
$
After:
$ echo -e "d- /root :0700 root :root - \nd- /root/.ssh :0700 root :root -" | SYSTEMD_LOG_LEVEL=err build/systemd-tmpfiles --root=/tmp/img --create -
$
When a module is blacklisted using module_blacklist=
we shouldn't fail with 'Operation not permitted'.
Instead we check for it and skip it if this is the case.
