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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This allows starting systemd-boot from \EFI\Linux for easier testing
and bisection without risking an unbootable system as the user does not
need to replace their working loader.
This adds an env var which we can use to redirect where homed stores and
looks for user records kept on the host. This is useful for debugging
purposes so that one can easily run another homed instnce that doesn't
interfere with the main instance.
Imports are sorted in the usual fashion: stdlib first.
literal_eval() parses string/numbers/lists/sets/dicts, and nothing else, while
eval will execute any python code. Using literal_eval() is generally more
correct, because it avoids the risk of side effects from the parsed expression.
In this case, we generate the parsed strings ourselves, so it's very unlikely
to have anything unexpected in the expressions. But let's do the correct thing
anyway.
The LoopDevice object supports a shortcut: if the backing fd we are
supposed to create a loopback device of refers to a
block device alrady then we'll use it as is – if we can – instead of
setting up an unnecessary loopback device that would be pretty much
the same as its backing device.
Previously, when doing this we'd just dup() the original backing fd and
use that. But that's problematic in case O_DIRECT was set on the fd,
since we'll keep that flag set on our copy too, which means we can't do
simple, regular IO on it anymore.
Thus, let's reopen the inode in this case with the exact access flags
we'd apply if we'd actually allocate and open a new loopback device.
Fixes: #21176
efi_arch is set to whatever meson returns from host_machine.cpu_family() and
gnu_efi_arch is then set accordingly.
On x86, efi_arch == x86 and gnu_efi_arch == ia32. Surprisingly, compilation
worked (without disabling some instruction sets) and nobody ever complained
about systemd-bootia32.efi not working.
This brings the final list of compiler arguments more in line with
how meson does things. In particular, --buildtype=plain will not
add any optimizations on its own (and would have to be provided
through CFLAGS=).
These flags are used by gnu-efi. Adding --no-undefined even allows
us to drop the no-undefined-symbols.sh test in favor of immediate
compile time errors.
This is not a hosted environment and we should not pretend otherwise
if -ffreestanding is not supported.
With EFI strings being in UCS2, it is not supported to build without
-fshort-wchar as gcc/clang default to a w_char_t size of 4 bytes.
This also makes the charset for wide chars explicit on gcc. This way
we get a nice error message if anyone ever tries to add 💩 to strings.
(Or when -H is used, since -H and -M are incompatible.)
Note that the slightly unusual form with separate boolean variables (hint_vars,
hint_addr) instead of e.g. a const char* variable to hold the message, because this
way we don't trigger the warning about non-literal format.
rearrange_stdio() invalidates specified fds even on failure, which means
we should always invalidate the fds we pass in no matter what. Let's
make this explicit by using TAKE_FD() for that everywhere.
Note that in many places we such invalidation doesnt get us much
behaviour-wise, since we don't use the variables anymore later. But
TAKE_FD() in a way is also documentation, it encodes explicitly that the
fds are invalidated here, so I think it's a good thing to always make
this explicit here.
Alternative to https://github.com/systemd/systemd/pull/20531.
Whenever a service triggered by another unit fails condition checks,
stop the triggering unit to prevent systemd busy looping trying to
start the triggered unit.
I got the logic reversed in 6d93265955.
Let's just remove the conditionalization of the status message: if we're
sending something, we might just as well always attach READY=1, the extra
few bytes don't make much of a difference.
FWIW, it seems that this bug didn't cause problems, probably because we'd send
READY=1 either from user_manager_send_ready() or from a later call to
manager_send_ready().
Most sd_notify() calls are like log_info() — the result is only informative
and if they fail, it's best ignore this. But if a call with READY=1 fails,
the unit may enter a failed state, so we should warn about this. Similarly
for FSTOREREMOVE=1: the manager may be left with a stale fd, at least wasting
resources.
… but only for a single variable.
The guidelines already allowed declaring variables at the point of
initialization. But not making a function call to do that. Let's allow that
now. The existing style of declaring and initializing seperate is still
allowed, and whatever makes most sense should be used.
