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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Currently the kernel-install man page only documents the bls layout for use
with the boot loader spec type #1. 90-loaderentry.install uses this layout to
generate loader entries and copy the kernel image and initrd to $BOOT.
This commit documents a second layout "uki" and adds 90-uki-copy.install,
which copies a UKI "uki.efi" from the staging area or any file with the .efi
extension given on the command line to
$BOOT/EFI/Linux/$ENTRY_TOKEN-$KERNEl_VERSION(+$TRIES).efi
This allows for both locally generated and distro-provided UKIs to be handled
by kernel-install.
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.
It's pretty hard to write tests without this. I started out by adding separate
variables for each of the files we read, but there's a bunch, and in practice
it's good enough to just override the directory.
Variables read by kernel-install and those exported by it were described
without any clear separation. So in particular it was pretty hard to answer
a question like "what variables can be set in install.conf". The in- and
out-variables are now split into two separate subsections.
In --help output, change "$0" → "kernel-install". We generally don't include
the full path in --help output, and let's not do this here either.
kernel-install is now in build/ directly, not in the subdirectory.
Change f887eab1da conditionalized the
building of ther kenel-install man page in the generated meson output,
instead of the source in the XML markup. Thus, whenever the rules file
is updated the conditionalization is lost. Correct that.
Follow-up for: f887eab1da
This drops documentation of KERNEL_INSTALL_MACHINE_ID as machine-info
field (though we'll still read it for compat).
This updates the kernel-install man page to always say "ENTRY-TOKEN"
instead of "MACHINE-ID" where appropriate, to clear the confusion up
between the two.
This also tries to fix how we denote env vars (always prefix with $ and
without = suffix), and other vars (without $ but with = suffix)
Other fixes.
The general approach of kernel-install was that each plugin would drop in some
files into the entry directory. But this doesn't scale well, because if we have
multiple initrd generators, or multiple initrds, each generator would need to
recreate the logic to put the generated files in the right place.
Also, effective cleanup is impossible if anything goes wrong on the way, so we
could end up with unused files in $BOOT.
So let's invert the process: plugins drop files into $KERNEL_INSTALL_STAGING_AREA,
and at the end 90-loaderentry.install DTRT with those files.
This allow new plugins like 50-mkosi-initrd.install to be significantly simpler.
The idea is that when not set, we do whatever we did in the past. But
with a new setting of initrd_generator=mkosi-initrd, mkosi-initrd will
generate an initrd.
341890de86 made "bootctl install" create
ESP\MID, in preparation of cf73f65089 that
followed it and created 00-entry-directory.install to make ESP\MID\KVER
if ESP\MID existed ‒ this meant that "bootctl install" followed by
"kernel-install $(uname -r) /boot/vml*$(uname -r) /boot/ini*$(uname -r)"
actually installed the kernel correctly.
Later, 31e57550b5 reverted the first
commit, meaning, that now running those two commands first installs
sd-boot, but then does nothing. Everything appears to work right,
nothing errors out, but no changes are actually done. To the untrained
eye (all of them), even running with -v appears to work:
all the hooks are run, as is depmod, but, again, nothing happens.
This is horrible. Nothing in either manpage suggests what to do
(nor should it, really), but the user is left with a bootloader that
appears fully funxional, since nothing suggests a failure in the output,
but with an unbootable machine, /no way to boot it/, even if they drop
to an EFI shell, since the boot bundle isn't present on the ESP,
and no real recourse even if they boot into a recovery system,
apart from installing like GRUB or whatever.
00- is purely instrumentation for 90-,
and separating one from the other has led to downstream dissatisfaxion
(indeed, the last mentioned commit cited cited exactly that as the
reversion reason), while creating $ENTRY_DIR_ABS is only required
for bootloaders using the BLS, and shouldn't itself toggle anything.
To that end, introduce an /{e,l}/k/install.conf file that allows
overriding the detected layout, and detect it as "bls" if
$BOOT_ROOT/$MACHINE_ID ($ENTRY_DIR_ABS/..) exists, otherwise "other" ‒
if a user wishes to select a different bootloader,
like GRUB, they (or, indeed, the postinst script) can specify
layout=grub. This disables 90- and $ENTRY_DIR_ABS manipulation.
If KERNEL_INSTALL_MACHINE_ID is defined in /etc/machine-info, prefer it
over the machine ID from /etc/machine-id. If a machine ID is defined in
neither /etc/machine-info nor in /etc/machine-id, generate a new UUID
and try to write it to /etc/machine-info as KERNEL_INSTALL_MACHINE_ID
and use it as the machine ID if writing it to /etc/machine-info succeeds.
In practice, this means we have a more robust fallback if there's no
machine ID in /etc/machine-id than just using "Default" and allows
image builders to force kernel-install to use KERNEL_INSTALL_MACHINE_ID
by simply writing it to /etc/machine-info themselves.
Confer https://github.com/systemd/systemd/pull/19006#issuecomment-800234022:
On some systems it's the admin's explicit choice not to to have the
machine ID leak into the ESP
On some systems the machine ID is transient, generated at every boot,
and hence should not be written to the ESP
The "include" files had type "book" for some raeason. I don't think this
is meaningful. Let's just use the same everywhere.
$ perl -i -0pe 's^..DOCTYPE (book|refentry) PUBLIC "-//OASIS//DTD DocBook XML V4.[25]//EN"\s+"http^<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"\n "http^gms' man/*.xml
No need to waste space, and uniformity is good.
$ perl -i -0pe 's|\n+<!--\s*SPDX-License-Identifier: LGPL-2.1..\s*-->|\n<!-- SPDX-License-Identifier: LGPL-2.1+ -->|gms' man/*.xml
Things are currently fairly ugly in Fedora: we create $BOOT/$MACHINE_ID/$KERNEL_VERSION/,
and then 20-grub.install that is installed by grub2-common.rpm wants to remove that
directory before 50-dracut.install get a chance to run. 50-dracut.install
checks for the presence of that directory to decide where to install the
kernel. So let's make the creation of the directory conditional. Previous
commit changes bootctl install to create $BOOT/$MACHINE_ID, and this commit
makes kernel-install not create it. In effect, the entry directory will only be
created if 'bootctl install' or something else created the parent directory.
https://bugzilla.redhat.com/show_bug.cgi?id=1648907
This makes it easier to see what is going on. Documentation for
--verbose and --help is added to the man page. Our plugins are updated
to also log a bit.
Instead of having just a single INITRD field, add support for all
additional parameters being INITRD fields in order.
Signed-off-by: Mike Auty <mike.auty@gmail.com>
The current support in kernel-install for initrd images doesn't copy
over the initrd file or allow a means for it to be specified (it
requires a specific filename in a particular directory).
This patchset adds support for (optionally) providing the name of
initial ramdisk file to copied over and used by kernel-install.
Docbook styles required those to be present, even though the templates that we
use did not show those names anywhere. But something changed semi-recently (I
would suspect docbook templates, but there was only a minor version bump in
recent years, and the changelog does not suggest anything related), and builds
now work without those entries. Let's drop this dead weight.
Tested with F26-F29, debian unstable.
$ perl -i -0pe 's/\s*<authorgroup>.*<.authorgroup>//gms' man/*xml
This part of the copyright blurb stems from the GPL use recommendations:
https://www.gnu.org/licenses/gpl-howto.en.html
The concept appears to originate in times where version control was per
file, instead of per tree, and was a way to glue the files together.
Ultimately, we nowadays don't live in that world anymore, and this
information is entirely useless anyway, as people are very welcome to
copy these files into any projects they like, and they shouldn't have to
change bits that are part of our copyright header for that.
hence, let's just get rid of this old cruft, and shorten our codebase a
bit.
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
This did not really work out as we had hoped. Trying to do this upstream
introduced several problems that probably makes it better suited as a
downstream patch after all. At any rate, it is not releaseable in the
current state, so we at least need to revert this before the release.
* by adjusting the path to binaries, but not do the same thing to the
search path we end up with inconsistent man-pages. Adjusting the search
path too would be quite messy, and it is not at all obvious that this is
worth the effort, but at any rate it would have to be done before we
could ship this.
* this means that distributed man-pages does not make sense as they depend
on config options, and for better or worse we are still distributing
man pages, so that is something that definitely needs sorting out before
we could ship with this patch.
* we have long held that split-usr is only minimally supported in order
to boot, and something we hope will eventually go away. So before we start
adding even more magic/effort in order to make this work nicely, we should
probably question if it makes sense at all.
In particular, use /lib/systemd instead of /usr/lib/systemd in distributions
like Debian which still have not adopted a /usr merge setup.
Use XML entities from man/custom-entities.ent to replace configured paths while
doing XSLT processing of the original XML files. There was precedent of some
files (such as systemd.generator.xml) which were already using this approach.
This addresses most of the (manual) fixes from this patch:
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/Fix-paths-in-man-pages.patch?h=experimental-220
The idea of using generic XML entities was presented here:
http://lists.freedesktop.org/archives/systemd-devel/2015-May/032240.html
This patch solves almost all the issues, with the exception of:
- Path to /bin/mount and /bin/umount.
- Generic statements about preference of /lib over /etc.
These will be handled separately by follow up patches.
Tested:
- With default configure settings, ran "make install" to two separate
directories and compared the output to confirm they matched exactly.
- Used a set of configure flags including $CONFFLAGS from Debian:
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/rules
Installed the tree and confirmed the paths use /lib/systemd instead of
/usr/lib/systemd and that no other unexpected differences exist.
- Confirmed that `make distcheck` still passes.
