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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
sd-boot has a copy of a subset of codes from libbasic. This makes
sd-boot share the code with libbasic, and dedup the code.
Note, startswith_no_case() is dropped from sd-boot, as
- it is not used,
- the previous implementation is not correct,
- gnu-efi does not have StrniCmp() or so.
As far as I can see, at some point the parser function for MountAPIVFS
was changed from the generic bool parser to a custom implementation, to
allow the context to keep track of whether MountAPIVFS had been set
explicitly. If not, exec_context_get_effective_mount_apivfs would fall
back to a default value. However, the corresponding entry in the big
parser table wasn't updated, meaning that the old bool parser was still
used, meaning that context->mount_apivfs_set remained at its default
value of false, meaning that the default value was always used and the
config option was effectively ignored.
Fix for 5e98086d16.
When executed in test mode, "OUTDATED" is appropriate. But when executed
to actually update the text, after the tool executes, those pages are the
opposite, not outdated.
It happens too often that what people ask for already is implemented.
Let's help cut the noise a bit, and make people check things first
hopefully, and at least make it either for us to detect such cases.
If we don't have ifindex info, don't set the field for it.
We already do that for parsed IP address replies, let's do it for all
cases: it's a bit nicer to suppress the ifindex prop if it doesn't apply
than to pass it invalid.
This is the other side of #18482, i.e. fixes things so that the parser
doesn't get tripped up by this.
(This too makes a problem go away we should track down properly, i.e.
figure out how the ifindex got lost in
https://github.com/systemd/systemd/pull/17823#issuecomment-742439422 )
Since the test suite overhaul, the test units are now under
/usr/lib/systemd/tests/testdata/tetsuite-06.units with
system_u:object_r:lib_t context. This causes an AVC denial, since the
systemd unit files are expected to have the
system_u:object_r:systemd_unit_file_t context. Let's fix this by using a
custom file context definition.
Aaargh. See the comment in the code.
Apparently the range is like that:
$ sudo bash -c 'echo "default 1001" >/sys/fs/cgroup/user.slice/io.bfq.weight'
bash: line 0: echo: write error: Numerical result out of range
$ uname -r
5.11.0-0.rc4.129.fc34.x86_64
Instead of using a short fixed string, let's use a huge blob for
testing, with randomized size and contents, that definitely is above the
16K buffer size conservative_renameat() uses internally.
The "XDG standardization for applications" specification states that
services should be in the form:
app[-<launcher>]-<ApplicationID>[@<RANDOM>].service or
app[-<launcher>]-<ApplicationID>-<RANDOM>.scope
In this case "autostart" takes the place of [RANDOM] to provide a unique
identifier if the same app is launched elsewhere. As it is a service
that means it should be set as a template not using a hyphen delimiter.
To add secure-boot enrolling support, we need to be able to specify
the EFI_VARIABLE_APPEND_WRITE flag so let's make the efivar_set()
methods more generic so we can set that flag.
Let's make sure we still look at the etags reported by http 304 (i.e.
the cache management code). Otherwise we won't properly realize we
already downloaded this before.
This fixes a bug introduced in 6792cbbcf8
The old name originates when this was used to discover "machine" images,
as managed by machined/machinectl. But nowadays this is also used by
portable services and system extensions, hence let's use a more generic
name for this API. Taking inspiration from "dissect-image.[ch]", let's call
this "discover-image.[ch]".
This is pure renaming, no other changes.
There is no technical reason to support systems with split-usr, except for
backwards compatibility. Even though systemd itself makes an effort to support
this, many other tools aren't as careful. Despite those efforts, we
(collectively) get it wrong often, because doing it "wrong" on systems with
merged-usr has no consequences. Since almost all developers are on such
systems, any issues are only discovered late. Supporting this split-usr mode
makes both code and documentation more complicated. The split is purely
artificial and has no justification except to allow old installation to not
update. Mechanisms to update existing systems are available though: Fedora
did that in https://fedoraproject.org/wiki/Features/UsrMove, Debian has
the usrmerge package.
The next version of Debian will only support systems with split-usr=false,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636#178:
The Technical Committee resolves that Debian 'bookworm' should
support only the merged-usr root filesystem layout, dropping support
for the non-merged-usr layout.
Let's start warning if split-usr mode is used, in preparation to removing the
split in one of the future releases.
Let's split out the two codepaths a bit, and emphasize which ones it the
new-style and which the old-style codepath, and let's clearly convert
the params of the old-stye into the new style for further processing, so
that the old style path is brief and isolated.
No change in behaviour.
Follow-up for: 8885fed4e3
