| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Clarify portions of HACKING.md so folks don't spend as much time as I
did on it.
Signed-off-by: William Roberts <william.c.roberts@intel.com>
|
| |
|
|
|
|
|
|
|
|
| |
(s) is just ugly with a vibe of DOS. In most cases just using the normal plural
form is more natural and gramatically correct.
There are some log_debug() statements left, and texts in foreign licenses or
headers. Those are not touched on purpose.
|
|\
| |
| | |
mkosi: Optionally build a kernel image from mkosi.kernel/
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If mkosi.kernel/ exists, the mkosi script will try to build a kernel
image from it. We use the architecture defconfig as a base and add
our own extra configuration on top.
We also add some extra tooling to the build image required to build
the kernel and include some documentation in HACKING.md on how to
use this new feature.
To avoid the kernel sources from being copied into the build or
final image (which we don't want because it takes a while), we put
the mkosi.kernel/ directory in .gitignore and use
"SourceFileTransfer=mount" so that the sources are still accessible
in the build image.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, we'd iterate an entry array from start to end every time
we added an entry offset to it. To speed up this operation, we cache
the last entry array in the chain and how many items it contains.
This allows the addition of an entry to the chain to be done in
constant time instead of linear time as we don't have to iterate
the entire chain anymore every time we add an entry.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To do this, we move EntryItem out of journal-def.h and turn it into
a host only struct in native endian mode so we can still use it to
ship the necessary info around.
Aside from that, the changes are pretty simple, we introduce some
extra functions to access the right field depending on the mode and
convert all the other code to use those functions instead of
accessing the raw fields.
We also drop the unused entry item hash field in compact mode. We
already stopped doing anything with this field a while ago, now we
actually drop it from the format in compact mode.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before:
OBJECT TYPE ENTRIES SIZE
Unused 0 0B
Data 3610336 595.7M
Field 5310 285.2K
Entry 3498326 1.2G
Data Hash Table 29 103.1M
Field Hash Table 29 151.3K
Entry Array 605991 1011.6M
Tag 0 0B
Total 7720021 2.9G
After:
OBJECT TYPE ENTRIES SIZE
Unused 0 0B
Data 3562667 591.0M
Field 3971 213.6K
Entry 3498566 1.2G
Data Hash Table 20 71.1M
Field Hash Table 20 104.3K
Entry Array 582647 505.0M
Tag 0 0B
Total 7647891 2.4G
|
| |
| |
| |
| |
| |
| | |
We also add an environment variable $SYSTEMD_JOURNAL_COMPACT that
can be used to disable compact mode if needed (similar to
$SYSTEMD_JOURNAL_KEYED_HASH).
|
| |
| |
| |
| |
| |
| | |
This adds a new flag in preparation for incompatible journal changes
which will be gated behind this flag. The max file size of journal
files in compact mode is limited to 4 GiB.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
tweaks
The text made it sound like breaking ABI in libsystemd is allowed with good reasons.
In fact, we plan never to do this, so make the language stronger.
Also remind people about distro forums for reporting bugs. Those are probably a
better place than systemd-devel for new users.
Also, add some missing articles and apostrophes, fix URLs, remove repeated phrases,
etc.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The linked filter gives an up-to-date list of pull requests that need review.
(Yes, there's too many.) We used to set 'needs-review' label, but that is
not available to non-members, and also every pull requests which is not labeled
'reviewed/needs-rework'/'ci-fails/needs-rework'/'needs-rebase' can and should
be reviewed.
If this is merged, I'll drop the 'needs-review' label.
|
|/ |
|
|\
| |
| | |
use "initrd" rather than "initial RAM disk" or "initramfs" to refernce the concept
|
| |
| |
| |
| |
| | |
With this the concept is now called the same way everywhere except where
historical info is relevant or where the other names are API.
|
|\ \
| | |
| | | |
repart: Add support for generating verity sig partitions
|
| |/ |
|
|/ |
|
|\
| |
| | |
Expose various GPT UUIDs as public contants and link them up in docs
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
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
4565246911adbdd1b20d8944c0754772788a768c in a slightly different fashion.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In 53c26db4dac0f5b79ca2a57364ee7df78a14bbfd 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
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
If the environment variable SOURCE_DATE_EPOCH is set, use its value
instead of the current time.
|
|
|
|
| |
devlink to be configured
|
|
|
|
|
|
| |
as per:
https://titlecase.com/
|
|
|
|
|
| |
CREDENTIAL_PATH appears nowhere in the systemd source code.
$CREDENTIALS_DIRECTORY is what is used instead.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Less configuration required than downloading and configuring an
askpass program.
|
| |
|
| |
|
|
|
|
|
|
| |
To be enabled on rc1, and disabled again after the final release.
Gives contributors a clear warning that new features/APIs will be
postponed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Extra memory because ASAN needs it
- The environment variables to make the sanitizers more useful
- LD_PRELOAD because the ASAN DSO needs to be the first in the list
- The sanitizer library packages
- Disable syscall filters because they interfere with ASAN
- Disable systemd-hwdb-update because it's super slow when systemd-hwdb
is built with sanitizers
- Take the value for meson's b_sanitize option from the SANITIZERS
environment variable
|
|\
| |
| | |
Make generators easier to test, fix various corner issues
|
| |
| |
| |
| | |
This adds $SYSTEMD_SYSROOT_FSTAB analoguous to $SYSTEMD_FSTAB.
|
| |
| |
| |
| |
| |
| |
| | |
credentials passed in
This is useful when provisioning systems via nspawn/qemu and running
specific services only if specific data is passed into the system.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This imports credentials also via SMBIOS' "OEM vendor string" section,
similar to the existing import logic from fw_cfg.
Functionality-wise this is very similar to the existing fw_cfg logic,
both of which are easily settable on the qemu command line.
Pros and cons of each:
SMBIOS OEM vendor strings:
- pro: fast, because memory mapped
- pro: somewhat VMM independent, at least in theory
- pro: qemu upstream sees this as the future
- pro: no additional kernel module needed
- con: strings only, thus binary data is base64 encoded
fw_cfg:
- pro: has been supported for longer in qemu
- pro: supports binary data
- con: slow, because IO port based
- con: only qemu
- con: requires qemu_fw_cfg.ko kernel module
- con: qemu upstream sees this as legacy
|
| |
|
|
|
|
|
|
| |
The "Networking" section has a lonely single document listed right now,
even though the "Concepts" section has two more network related docs.
Move them over, let's end this loneliness.
|