Ben Cotton <bcotton@xxxxxxxxxx> writes: > https://fedoraproject.org/wiki/Changes/mkosi-initrd > > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > > == Summary == > > `mkosi-initrd` is an alternative builder for initrds. > It will be packaged in Fedora, so that users can use it to build > initrds locally. > A `kernel-install` plugin will be provided to build the initrd when a > kernel package is installed. > As a stretch goal, initrds will be build in koji and delivered via rpm packages. > As a further stretch goal, pre-built initrds will be used in Unified > Kernel Images that can be delivered via rpm packages. > > Only a subset of installation types will be supported. > > == Owner == > * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]] > * Name: [[User:lnykryn| Lukáš Nykrýn ]] > * Name: [[User:Daandemeyer| Daan De Meyer]] > * Email: zbyszek - at - in.waw.pl, lnykryn - at - redhat.com, > daandemeyer - at - fb.com > > > > == Detailed Description == > The process by which we create initrds is complicated and inefficient. > Initrds contain duplicate functionality and require a lot of maintainer effort. > The aim of this proposal is to introduce a vastly simplified mechanism > of initrd creation and simplified initrd contents. > > The `mkosi-initrd` project is a set of config files for `mkosi`. > `mkosi` is a program to build operating system images from system packages. > An initrd is built by invoking `mkosi` with the config provided by > `mkosi-initrd`. > > Instead of building initrds by scraping the file system and figuring > out dependencies again, > existing packages and normal package installation via `dnf`/`rpm` is > used to populate the initrd. > This also means that the package manager is responsible for satisfying > dependencies. > At runtime, `systemd` is responsible for setting up the execution > environment and invoking programs. > > Currently, initrds built in this way are bigger than initrds built by dracut. > They also have limited functionality: > many common types of systems work just fine, but more exotic > configurations are not supported. > See [[#Scope|Scope]] below for a list of known good/bad features. > > The goal of this change is to provide an ''alternative'' mechanism. > If the feedback is positive, we may consider using initrds built with > `mkosi-initrd` as default in certain scenarios. > There are no plans to remove `dracut` in the foreseeable future. > This means that for any case not supported or not working well, > `dracut` remains a natural fallback. > In this way this change is similar to > [[Changes/Unified_Kernel_Support_Phase_1]], > as it provides a preview of a new technology as an alternative to the > current established approach. > > == Feedback == > > > == Benefit to Fedora == > Current initrd generation with `dracut` is showing its age. > As upstream packages evolve, > repeating the dependency resolution in `dracut` is a constant drain of > maintainer time. > Our `dracut` initrds are already using `systemd`. > But `systemd` is constantly evolving and adding new functionality > related to early boot: > decryption of disks, access to secrets, new configuration mechanisms, > state checks and boot counting. > More and more, `dracut` runtime scripting is a thin wrapper around `systemd`. > We have two job queues: the `dracut` initqueue, and the `systemd` job queue. > This duplication makes everything harder, both during preparation and > at runtime, for little benefit. > > The design principle of the new approach is to remove duplicate functionality: > * package `Requires` replace dracut module dependency logic and > automatic installation of libraries based on `ldd` output > * `systemd` job management replaces the remainder of `dracut` runtime > * the environment in the initrd is just a normal linux system (albeit > on a temporary root fs) > * normal package contents replace special scripts crafted for the initrd > > Generally, the new scheme requires very little new stuff. > We reuse things that are already available (and used): > `dnf` and `rpm`, > packages for all stuff that is used in the initrd, > `systemd`, > special systemd units for the initrd. > > The new component is a mechanism that builds the initrd out of packages. > But it is a relatively simple step that requires very little maintenance. > The biggest part of the initial work is the creation of package lists > to install in the initrd, > and adjusting packages to to function correctly in the initrd and not > pull in unnecessary dependencies. > Afterwards, there might be occasional maintenance related to bugs or > package splits. > > Initrds built with `mkosi-initrd` should be fully reproducible (in the > sense of reproducible builds). > > The work done in packages has external benefits: > package minimization automatically benefits other "small" installations. > > == Scope == > * Proposal owners: > ** package `mkosi-initrd` > ([https://copr.fedorainfracloud.org/coprs/zbyszek/mkosi-initrd/builds/ > copr], review-request > https://bugzilla.redhat.com/show_bug.cgi?id=2189633) > ** verify (and fix if necessary) `mkosi-initrd`/`systemd`/other > packages to work with: > *** root on a plain partition > *** root on LVM2 > *** root on LUKS > *** root on RAID > *** root on NFS > *** hibernation > ** provide a `kernel-install` plugin that builds an initrd locally > ** provide a `kernel-install` plugin that combines this initrd with a > kernel binary into a Unified Kernel Image locally > ** make dracut not interfere with mkosi-initrd (merge > https://github.com/dracutdevs/dracut/pull/1825 or carry downstream > patch) > ** work with koji developers to allow `mkosi-initrd` to run in koji > (stretch goal 1). This requires changing koji to allow access to > downloaded rpms during build. > ** add a `mkosi-initrd-initrd` (name TBD) package that builds a set of > subpackages with initrds (stretch goal 2). > > (Out of scope: support for root on iSCSI is not planned currently. > Our experiments with iSCSI show that the existing tooling is a bunch > of terrible scripts that don't work at all outside of dracut.) > > More items may be added to Scope or listed as not planned based on feedback. > > * Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> > ** koji developers: help with the rpms-in-buildroot functionality and > ** koji maintainers and releng: deploy changes in koji in Fedora infra > ** anyone: Install the new packages to opt-in into testing the new initrds. > > * Release engineering: > * Policies and guidelines: N/A (not needed for this Change) > * Trademark approval: N/A (not needed for this Change) > * Alignment with Objectives: > > > == Upgrade/compatibility impact == > This is new functionality that will only impact people who opt-in. > > == How To Test == > * Right now: > ** enable the copr and install `mkosi-initrd` (see > [https://github.com/systemd/mkosi-initrd/#mkosi-initrd--build-initrd-images-using-distro-packages > instructions]) > ** adjust configuration:<pre>echo 'initrd_generator=mkosi-initrd' >>>/etc/kernel/install.conf # Until > https://github.com/dracutdevs/dracut/pull/1825 is merged mkdir -p > /etc/kernel/install.d ln -s /dev/null > /etc/kernel/install.d/50-dracut.install</pre> > ** Upgrade or reinstall kernel package and reboot > * After `mkosi-initrd` has an official build: > ** disable the copr and update to the distro package > ** Upgrade or reinstall kernel package and reboot > * After stretch goal 2: > ** Install `mkosi-initrd-initrd-<variant>` > ** Upgrade or reinstall kernel package and reboot Would it be possible to build bootable images using mkosi-initrd in koji? Then these could be booted in openQA directly and catch simple regressions like unbootable images quite easily. Cheers, Dan _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
