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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
For use with sysupdate or other systemd tooling, it's useful to be
able to generate split artifacts from disk images, where each
partition is written to a separate file. Let's support this with
a --split switch for repart and a SplitName= configuration option.
--split enables split artifacts generation, and SplitName= configures
for which partition to generate split artifacts, and which suffix to
add to the split artifact name.
For SplitName=, we add support for some extra specifiers, more specifically
the partition Type UUID and the partition UUID.
All users were setting this to some static string (usually "-"), so let's
simplify things by not doing strdup, but instead limiting callers to a fixed
set of values. In preparation for the next commit, the function is renamed from
"empty" to "replacement", because it'll be used for more than empty fields. I
didn't do the whole string-table setup, because it's all used internally in one
file and this way we can immediately assert if an invalid value is passed in.
Some callers were (void)ing the error, others were ignoring it, and others
propagating. It's nicer to remove the boilerplate.
systemd-run's man page says the following about the working directory of
the process:
"If a command is run as transient scope unit, it will be executed
by systemd-run itself as parent process and will thus inherit the
execution environment of the caller."
This means working directory assignment does not work, as evidenced by
the following invocation:
```bash
$ systemd-run --scope --property=WorkingDirectory=/tmp/ bash -c 'echo $(pwd)'
Unknown assignment: WorkingDirectory=/tmp/
```
However, using the shorthand switch --working-directory silently ignores
this instead of giving a similar error.
```bash
systemd-run --scope --user --working-directory=/tmp/ bash -c 'echo $(pwd)'
Running scope as unit: run-r19cc32e744e64285814dbf2204637a2b.scope
/home/test/projects/systemd
```
This commit fixes this by explicitly generating an error instead of
silently ignoring the switch:
```bash
$ systemd-run --scope --working-directory=/tmp/ bash -c 'echo $(pwd)'
--working-directory is not supported in --scope mode.
```
We forgot to conditionalize this on pcrsig/pcrpkey too. So if you have
ne creds or sysext configured we actually wouldn't pass pcrsig/pcrpkey
along. Let's fix that.
To make this work, we have to set up everything in a temporary
directory tree that we can pass to mksquashfs as a single directory.
To make the most common scenario more efficient, we skip the temporary
setup directory if we only get a single source tree destined to root
in the squashfs filesystem.
Previously, existing device units for devlinks or aliases were not
removed unless the main device unit is removed. This makes all existing
device units for devlinks and aliases are checked if they are still
required, and remove if not necessary anymore.
Fixes#24518.
In 53c26db4da the meaning of $BOOT was
redefined. I think that's quite problematic, since the concept is
implemented in code and interface of bootctl. Thus, I think we should
stick to the original definition, which is: "where to *place* boot menu
entries" (as opposed to "where to *read* boot menu entries from").
The aforementioned change was done to address two things afaiu:
1. it focussed on a $BOOT as the single place to put boot entries in,
instead of mentioning that both ESP and $BOOT are expected to be
the source
2. it mentioned the /loader/ dir (as location for boot loader resources)
itself as part of the spec, which however only really makes sense in
the ESP. /loader/entries/ otoh makes sense in either the ESP or
$BOOT.
With this rework I try to address these two issues differently:
1. I intend to make clear the $BOOT is the "primary" place to put stuff
in, and is what should be mounted to /boot/.
2. The ESP (if different from $BOOT) is listed as "secondary" source to
read from, and is what should be mounted to /efi/. NB we now make the
distinction between "where to put" (which is single partition) and
"where to read from".
3. This drops any reference of the /loader/ dir witout the /entries/
suffix. Only the full /loader/entries/ dir (and its companion file
/loader/entries.srel) are now mentioned. Thus isolated /loader/
directory hence becomes irrelevant in the spec, and the fact that
sd-boot maintains some files there (and only in the ESP) is kept out
of the spec, because it is irrelevant to other boot loaders.
4. It puts back the suggestion to mount $BOOT to /boot/ and the ESP to
/efi/ (and suggests adding a symlink or bind mount if both are the
same partition). Why? Because the dirs are semantically unrelated:
it's OK and common to have and ESP but no $BOOT, hence putting ESP
inside of a useless, non-existing "ghost" dir /boot/ makes little
sense. More importantly though, because these partitions are
typically backed by VFAT we want to maintain them as an autofs, with
a short idle delay, so that the file systems are unmounted (and thus
fully clean) at almost all times. This doesn't work if they are
nested within each other, as the establishment of the inner autofs
would pin the outer one, making the excercise useless. Now I don't
think the spec should mention autofs (since that is an implementation
detail), but it should arrange things so that this specific, very
efficient, safe and robust implementation can be implemented.
The net result should be easy from an OS perspective:
1. *Put* boot loader entries in /boot/, always.
2. *Read* boot loader entries from both /boot/ and /efi/ -- if these are distinct.
3. The only things we define in the spec are /loader/entries/*.conf and
/EFI/Linux/*.efi in these two partitions (well, and the companion
file /loader/entries.srel
4. /efi/ and /boot/ because not nested can be autofs.
5. bootctl code and interface (in particular --esp-path= and
--boot-path=) match the spec again. `bootctl -x` and `bootctl -p`
will now print the path to $BOOT and ESP again, matching the concepts
in the spec again.
From the sd-boot perspective things are equally easy:
1. Read boot enrties from ESP and XBOOTLDR.
2. Maintain boot loader config/other resources in ESP only.
And that's it.
Fixes: #24247
