Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Sync "Discoverable Partitions Specifications" with "Boot Loader Specification" #35

Closed
ljrk0 opened this issue Nov 1, 2022 · 0 comments · Fixed by #75
Closed

Sync "Discoverable Partitions Specifications" with "Boot Loader Specification" #35

ljrk0 opened this issue Nov 1, 2022 · 0 comments · Fixed by #75

Comments

@ljrk0
Copy link

ljrk0 commented Nov 1, 2022

The change systemd/systemd@0b81e47 also implemented in this repository changes (reverts) the meaning of $BOOT as well as the recommended mounting scheme. To cite from the BLS:

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.

And:

It is recommended to mount $BOOT to /boot/, and the ESP to /efi/. If $BOOT and the ESP are the same, then either a bind mount or a symlink should be established making the partition available under both paths.

From the commit message:

  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".

This is perhaps a bit less clear than it could: In the case of ESP being $BOOT, should it be mounted to /boot or /efi and in what "direction" should the symlink/bind-mount be? While this is probably irrelevant, this spec seems to recommend mounting to /boot. However, the DPS specifies:

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. This partition type is defined by the UEFI Specification.

The Extended Boot Loader Partition (XBOOTLDR) used for the current boot is automatically mounted to /boot/, unless a different partition is mounted there (possibly via /etc/fstab) or the directory is non-empty on the root disk. This partition type is defined by the Boot Loader Specification.

So here the ESP should be mounted to /efi by default, and only then to /boot. Further, if a XBOOTLDR partition exists (that is, ESP is not $BOOT) the spec is unclear whether /boot should then be used (which is exactly opposite to the BLS which then would mount the ESP to /efi and $BOOT/XBOOTLDR to /boot) or somewhere else entirely.

This probably stems from the rather recent change in upstream systemd on part of the BLS.

Also note that the link from the DPS to BLS quoted above references the BLS on systemd.io instead of on uapi-group.
keszybz added a commit to keszybz/systemd that referenced this issue Apr 16, 2023
@keszybz
gpt-auto-generator: rework/simplify logic for picking /efi or /boot
455cc75 
I started looking into uapi-group/specifications#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.

The two specs are contradictory.

The code in gpt-auto-generator implemented logic from the DPS.
keszybz added a commit to keszybz/systemd that referenced this issue May 18, 2023
@keszybz
gpt-auto-generator: rework/simplify logic for picking /efi or /boot
77a347e 
I started looking into uapi-group/specifications#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 exist:
  - 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 exists:
  - if XBOOTLDR exists:
    XBOOTLDR on /boot
  - if only ESP exists:
    ESP on /boot
- if only /efi exists:
  - if ESP exists:
    ESP on /efi
Not mounting stuff because the mount points don't exist is treated as success.

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.
@keszybz keszybz mentioned this issue May 18, 2023
Merged
keszybz added a commit to keszybz/systemd that referenced this issue May 19, 2023
@keszybz
gpt-auto-generator: rework/simplify logic for picking /efi or /boot
0f84a26 
I started looking into uapi-group/specifications#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 exist:
  - 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 exists:
  - if XBOOTLDR exists:
    XBOOTLDR on /boot
  - if only ESP exists:
    ESP on /boot
- if only /efi exists:
  - if ESP exists:
    ESP on /efi
Not mounting stuff because the mount points don't exist is treated as success.
If /boot exists but is "busy" (i.e. has content or is a mount point), it is not
used, i.e. the effect is the same as if it didn't exist.

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.
keszybz added a commit to keszybz/systemd that referenced this issue May 19, 2023
@keszybz
gpt-auto-generator: rework/simplify logic for picking /efi or /boot
1d9ff44 
I started looking into uapi-group/specifications#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 exist:
  - 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 exists:
  - if XBOOTLDR exists:
    XBOOTLDR on /boot
  - if only ESP exists:
    ESP on /boot
- if only /efi exists:
  - if ESP exists:
    ESP on /efi
Not mounting stuff because the mount points don't exist is treated as success.
If /boot exists but is "busy" (i.e. has content or is a mount point), it is not
used, i.e. the effect is the same as if it didn't exist.

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.
keszybz added a commit to keszybz/systemd that referenced this issue May 24, 2023
@keszybz
gpt-auto-generator: rework/simplify logic for picking /efi or /boot
fa26d87 
I started looking into uapi-group/specifications#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.
keszybz added a commit to keszybz/systemd that referenced this issue May 24, 2023
@keszybz
gpt-auto-generator: rework/simplify logic for picking /efi or /boot
009d426 
I started looking into uapi-group/specifications#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.
keszybz added a commit to keszybz/systemd that referenced this issue May 26, 2023
@keszybz
gpt-auto-generator: rework/simplify logic for picking /efi or /boot
f47bbff 
I started looking into uapi-group/specifications#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.
keszybz added a commit to keszybz/systemd that referenced this issue May 29, 2023
@keszybz
gpt-auto-generator: rework/simplify logic for picking /efi or /boot
6a488fa 
I started looking into uapi-group/specifications#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.
@keszybz keszybz mentioned this issue Aug 14, 2023
Closed
keszybz added a commit to keszybz/specifications that referenced this issue Sep 15, 2023
@keszybz
Reconcile the handling of /boot and /efi in BLS and DPS
8cc7436 
Fixes uapi-group#35.

systemd/systemd@6a488fa
updated systemd-gpt-auto-generator as the first step. Now this commit
updates both specifications to match the implementation. The implementation
is actually much more complex than the specs, because it needs to take into
account a state where the mount points are missing, or used by something else,
or contain files. The specs just describe the desired end state:

  It is recommended to mount $BOOT (either XBOOTLDR or the ESP) to /boot/.
  If both XBOOTLDR and the ESP are present, the ESP should be mounted to /efi/.

  Effectively, this means that /boot/ is the location where new boot entries
  shall be written to. For the boot loader itself, the situation is more
  complicated, because its files may be located under /boot/ or /efi/, depending
  on whether XBOOTLDR exists.

So now the implementation, the man page, and the two specs should be in sync.
@keszybz keszybz mentioned this issue Sep 15, 2023
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Reconcile the handling of /boot and /efi in BLS and DPS keszybz/specifications
1 participant
@ljrk0