6a488fa7cc
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.
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.