98d81cf974 moved the assertion at the beginning of home_dispatch_acquire(),
which is however before we even check for any ongoing operation, hence we
might hit it even in legitimate cases.
Let's move it back to after we check for any possibly ongoing operation, to
make it once again a safety check.
Follow-up to 98d81cf974.
Resolves: #22443 and #24036
gpt-auto-generator does three checks: 1. whether the directory doesn't have
files, 2. whether it's not in fstab, and 3. whether it is not a mount point.
For dissect logic, 3. is not relevant, and it ignores 2.
But the check whether files exists was done only partially: it was done
for /efi, but not for /boot.
Two changes are made:
- the check whether /boot is empty is now done.
- for ESP, /boot is used in preference to /efi, if not used for XBOOTLDR.
With those changes, the logic in dissect matches what gpt-auto-generator does.
There are the two intentional differences described in the first paragraph,
I started looking into https://github.com/uapi-group/specifications/issues/35.
BLS says:
> Otherwise [no existing XBOOTLDR partition], if on GPT and an ESP is found and
> it is large enough (let’s say at least 1G) it should be used as $BOOT and
> used as primary location to place boot loader menu resources in.
> It is recommended to mount $BOOT to /boot/, and the ESP to /efi/.
DPS says:
> The ESP used for the current boot is automatically mounted to /efi/ (or
> /boot/ as fallback), unless a different partition is mounted there (possibly
> via /etc/fstab, or because the Extended Boot Loader Partition — see below —
> exists) or the directory is non-empty on the root disk.
I don't think we want to mount the same partition in two places.
If the same partition is not mounted in two places, then the two specs are
contradictory.
The code in gpt-auto-generator implemented the logic from the DPS. It is
modified to implement the logic from BLS.
Effectively:
- if both /boot and /efi are available:
- if both XBOOTLDR and ESP exist:
ESP on /efi, XBOOTLDR on /boot
- if only ESP exists:
ESP on /boot
- if only XBOOTLDR exists:
XBOOTLDR on /boot
- if only /boot is available:
- if XBOOTLDR exists:
XBOOTLDR on /boot
- if only ESP exists:
ESP on /boot
- if only /efi is available:
- if ESP exists:
ESP on /efi
"Available" means that it the mount point is not mounted over and does not
contain files. If the directory doesn't exist, it is also "available" and will
be created later when the mount or automount unit is started.
Thus, the generator attempts to match the partitions and mount points to the
extent possible. In all cases, /boot is the primary place to install kernels.
ESP can be found on /boot or /efi, depending on the situation.
If this patch is merged, I'll submit fixes for BLS and DPS to describe the
same logic.
The gc_unit_queue is dispatched before the cgroup_empty_queue. Because
of this, when we enter in on_cgroup_empty_event, the unit in
cgroup_empty_queue may already have been freed and we don't clean up the
corresponding cgroup. With this change, we prevent the unit from being
garbage collected if it is in the cgroup_empty_queue.
In mkosi we set the default architecture to platform.machine() which
is again slightly incompatible for a few architectures, so add more
aliases, so that repart works by default with these names.
When there is no matching entry stored in journal, then initial call of
`sd_journal_previous()` following `sd_journal_seek_tail()` returns
zero, and does not move the read pointer.
In the main loop, on every journal event, we call `sd_journal_next()`,
even though the current location is tail, and it takes no effect.
In such a case, we need to call `sd_journal_previous()` instead of
`sd_journal_next()`.
After the commit 7a4ee86161,
sd_journal_next() following sd_journal_seek_tail() takes no-op,
and we need to call sd_journal_previous(). This may be useful in
some cases, e.g. to fix the issue explained in the previous commit.
Scripts used to detect files that should be in POTFILES.in, like
intltool-update -m used on https://l10n.gnome.org/module/systemd/,
falsely detect this file as containing translations. Avoid this
behavior by putting the file in POTFILES.skip.
Adds a new JSON object called DHCPServer for each interface that has a
DHCPServer configured. It has the following attributes:
- PoolSize and PoolOffset from the configuration
- List of offered leases
- List of static leases from the configuration
Temporarily revert the test case for #27167, as the additional
daemon-reexecs exacerbate #27287, making CIs fail quite often.
As the #27167 is also covered by TEST-01-BASIC itself, since we do
daemon-reexec there anyway, we shouldn't lose any coverage, but it
should make CIs more stable until #27287 is figured out.
Resolves (or more like works around): #27807
This reverts commit d689f70a2c.
Previously, get_boots() used for three ways; finding boot entry by
boot ID, finding boot entry by offset, listing up all boot IDs.
Let's split it into three for each usecase.
No functional change, just refactoring.
The DSP and our implementation mixes Debian terminology with CPU
terminology. It uses arm64 which is a Debian thing instead of
aarch64, but x86-64 which is a CPU thing instead of amd64.
Add some convenience and transparent aliasing, so that we don't
need to maintain architecture-specific and tool-specific translation
layers in mkosi among other places, while at the same time the DDIs
still look the same (ie: the partlabel does not change depending on
which alias is used, the canonical label is used on disk).
This adds a function to fully calculate the authPolicy needed to seal a secret,
and updates tpm2_seal() to use the new function instead of a trial policy.
This updates the function to build the sealing policy to use the dedicated
function to perform PolicyAuthorize.
This is separate from the previous commit to make each commit easier to read.
This adds functions to get the digest for a PolicyAuthorize operation. For
building a policy hash, this provides a function to calculate the hash; and for
building a policy hash to satisfy the authPolicy for an existing object, this
provides a function to perform PolicyAuthorize with an existing session.
This adds functions to get the digest for a PolicyAuthValue operation. For
building a policy hash, this provides a function to calculate the hash; and for
building a policy hash to satisfy the authPolicy for an existing object, this
provides a function to perform PolicyAuthValue with an existing session.
This adds functions to get the digest for a PolicyPCR operation. For building
a policy hash, this provides a function to calculate the hash; and for building
a policy hash to satisfy the authPolicy for an existing object, this provides a
function to perform PolicyPCR with an existing session.
This adds functions to get the "name" of a key. The key "name", as defined
by the TPM2 spec, includes its entire public area (with attribute fields),
not only its key fingerprint.
A function is added to calculate the name of a provided key public area,
as well as a function to get the name of a key which is present in the TPM.
These functions allow extending (or initializing) a TPM2B_DIGEST with additional
data, using a specified hash operation. This is needed to perform hash
calculations instead of relying on the TPM to perform the calculations in
trial sessions.
The check added by 4c27749b8c breaks
booting an arm64 image on x86 using qemu-bin-fmt, so remove it.
Without it, the image built with mkosi --architecture=aarch64
boots fine in nspawn.
Mike Yuan
James Hilliard
Frantisek Sumsal
Zbigniew Jędrzejewski-Szmek
Richard Phibel
David Tardon
Yu Watanabe
Luca Boccassi
Piotr Drąg
Daan De Meyer
Dan Streetman
Rene Hollander
Lennart Poettering
Vitaly Kuznetsov