We never use the return value, and it's confusing and kinda pointless
what we return there.
Hence drop it.
Originally noticed by: tristone13th <tristone13th@outlook.com>
Alternative to: #25810
The text said /dev/tty* as a whole was the VT subsystem and that VT is
not supported in containers.
But that's not accurate as /dev/tty* will match /dev/tty too and that
one device node is special and is not related to VT: it always points to
the current process own controlling tty, regardless what that is.
hence, rewrite /dev/tty* as /dev/tty[0-9]*.
We want to make use of that when formatting file systems, hence let's
pull in these modules explicitly.
(This is necessary because we are an early boot service that might run
before systemd-tmpfiles-dev.service, which creates /dev/loop-control and
/dev/mapper/control.)
Alternatively we could just order ourselves after
systemd-tmpfiles-dev.service, but I think there's value in adding an
explicit minimal ordering here, since we know what we'll need.
Fixes: #25775
EFI_LOADER_VARIABLE() already applies to the stringify to construct the
path of EFI variable in efivars, so it is wrong to enclose the name of
EFI variable with the quotes. Otherwise, the following errors are
reported.
Reading EFI variable /sys/firmware/efi/efivars/StubFeatures-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f.
Reading EFI variable /sys/firmware/efi/efivars/"StubPcrKernelImage"-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f.
open("/sys/firmware/efi/efivars/"StubPcrKernelImage"-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f") failed: No such file or directory
Reading EFI variable /sys/firmware/efi/efivars/"StubPcrKernelParameters"-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f.
open("/sys/firmware/efi/efivars/"StubPcrKernelParameters"-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f") failed: No such file or directory
Reading EFI variable /sys/firmware/efi/efivars/"StubPcrInitRDSysExts"-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f.
open("/sys/firmware/efi/efivars/"StubPcrInitRDSysExts"-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f") failed: No such file or directory
Signed-off-by: Jia Zhang <zhang.jia@linux.alibaba.com>
This is useful to make the dissection logic at boot a bit safer, as we
can reference device nodes by diskseq.
This locks down dissection a bit, since it makes it harder to swap out
the backing device between the time we dissected and validated it, until
we actually mounted it.
This is not complete though, as /bin/mount would have to verify the
diskseq after opening the diskseq symlink again.
See: https://github.com/util-linux/util-linux/issues/1786
This allows FIDO2 users to wipe out password slots and still be able to
enroll new key slots via systemd-cryptenroll. Note that when the user
wants to both unlock with a FIDO2 token and enroll a new FIDO2 token,
they cannot be set to automatic discovery. This is to safeguard against
confusion, because there will be multiple tokens connected to the system
when doing so -- and we require users to explicitly confirm which one to
use for unlocking and which one to use for enrollment.
Addresses #20230 for the FIDO2 case.
`acquire_fido2_key_auto()` will not be used in PLAIN mode, and
parameters such as the salt will be acquired from the LUKS header.
Parameters intended for PLAIN mode are useless in
`acquire_fido2_key_auto()`.
llvm-objcopy works on stubs built for foreign architectures whereas
objcopy doesn't so let's prefer using llvm-objcopy instead of objcopy.
llvm-objcopy automatically sets the virtual address and doesn't provide
an option to set it manually so we only add --change-section-vma when
using objcopy
The default section flags differ between llvm-objcopy and objcopy
so we add a default for the section flags so we make sure all sections
are read-only data unless specified otherwise.
When we dissect images automatically, let's be a bit more conservative
with the file system types we are willing to mount: only mount common
file systems automatically.
Explicit mounts requested by admins should always be OK, but when we do
automatic mounts, let's not permit barely maintained, possibly legacy
file systems.
The list for now covers the four common writable and two common
read-only file systems. Sooner or later we might want to add more to the
list.
Also, it might make sense to eventually make this configurable via the
image dissection policy logic.
