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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
Let's separate the PE section options in the --help text to make clearer
that they are about PE sections, and thus make things less confusing
regarding the cryptic names. Specifically, there's now a separate
section in the --help text that looks like this:
<snip>
UKI PE Section Options: UKI PE Section
--linux=PATH Path Linux kernel image → .linux
--osrel=PATH Path to os-release file → .osrel
--cmdline=PATH Path to file with kernel command line → .cmdline
--initrd=PATH Path to initrd image → .initrd
--splash=PATH Path to splash bitmap → .splash
--dtb=PATH Path to Devicetree file → .dtb
--pcrpkey=PATH Path to public key for PCR signatures → .pcrpkey
</snipe>
(The section title is underlined, like we usually do it)
I think separating this out, and organizing the section name in tabular
form emphasizes nicely where this switches get their name from and what
they mean.
Hopefully addresses concerns from
https://github.com/systemd/systemd/pull/24458#discussion_r967052720 in a
diferent way.
(Also dropped a hint regarding DER format for public key. it's simply
wrong, we use PEM like everyone else on Linux. Outside of Java land DER
isn't popular, so we don't need to mention it here in the --help text,
man page should be enough.)
"located on the same disk as the ESP is located on" is hard to grok. Let's
use more natural phrasing. Also, we shouldn't say that "The first foo partition
… is mounted to …", because this doesn't explain what is happening. The
partition could be empty, and there could be other partitions with the "foo"
content, but what matters is the UUID.
We listed many of the root-partition type uuids, but not all. I think the
chances of somebody using the discoverable partition magic on an Itanium system
are fairly low at this point. So let's remove all architectures except the two
most popular consumer architectures. People building Longsoon or RISC-V images
are likely to have the online version of the Discoverable Partitions
Specifications handy anyway, and it makes the man page easier to read. It also
reduces the chances that somebody adding new entries to the table has some
select&paste mishap. We've already had this happen in the past and it's fairly
nasty bug. We don't need to expose the information in two places with manual
propagation between them.
In all other cases we have the older variant before the newer. And since we
generate some documentation tables from the header, this order is also visible
for users. Let's restore the order. This commit does
4565246911 in a slightly different fashion.
I think those constants are generally useful. It's quite easy to make a mistake
when copying things from the docs, so let's make them easy and convenient to
access.
In many places we spelled out the phrase behind "initrd" in full, but this
isn't terribly useful. In fact, no "RAM disk" is used, so emphasizing this
is just confusing to the reader. Let's just say "initrd" everywhere, people
understand what this refers to, and that it's in fact an initramfs image.
Also, s/i.e./e.g./ where appropriate.
Also, don't say "in RAM", when in fact it's virtual memory, whose pages
may or may not be loaded in page frames in RAM, and we have no control over
this.
Also, add <filename></filename> and other minor cleanups.
This documents that explicit `Before=`/`After=` dependencies can be
used to selectively override implicit ordering coming from default
dependencies. That allows for more granular control compared to the
already documented `DefaultDependencies=no` option.
The alternative approach came up in a discussion around the ordering
of `boot-complete.target`, so this also adds an explicit suggestion
in that direction to the "Automatic Boot Assessment" documentation.
Ref: https://lists.freedesktop.org/archives/systemd-devel/2022-September/048330.html
Let's rework verify_fsroot_dir() around two statx() calls, which should
usually give us all information we need. Let's then add a call to the
btrfs ioctl only if the caller actually wants to know the backing block
device (which it generally only wants if it then intends to verify
partition type, and similar).
This makes things more robust on new kernels, and bypasses the btrfs
ioctls in environments where we cannot actually interpret the results
properly (since they reference btrfs devices via /dev/ paths, which we
likely cannot resolve in containers)
Fixes: #24616
There's little reason to require this, given that we can just say that
if a relative path is specified it is to be read relative to the root.
This fixes a bootctl bug introduced by
3730dc5d5b which didn't bother prefixing
paths as necessary.
The kernel PE image version can be used to detect support for this
feature, allowing us to prefer the generic code of the deprecated EFI
handover protocol.
We could try to relocate these but that is probably not needed. So far
we have not been bitten by this in the real world and kernels we boot
likely already support this anyway.
The boot params passed to the kernel only has to be one page in size
and the size of the setup header has to be calculated as it depends on
the boot protocol version supported by the kernel.
The kernel x86 boot protocol does not expect this value to be set when
using EFI handover protocol. If the stub is loaded above 4G we would
end up discarding the high bits, breaking boot.
Fixes: #24707
No functional changes, just refactoring.
Note, this also makes synthesize_change() propagate the error from
synthesize_change_one(). However, the caller of synthesize_change()
ignores the failure anyway, hence the change does not take any effect.
This works becuase TPM2_FLAGS_USE_PIN is 1 and bool is a 1 so the bits
line up as expected, however if for some reason flags change values and
for clarity check if the boolean indicates this flag and pass the flag
value.
Signed-off-by: William Roberts <william.c.roberts@intel.com>
This way we can use it directly in measure.c, and thus remove a bit of
redundant code.
OpenSSL prefers uppercasing the MD names, others don't hence let's be
lenient here.
