5f1944b072
The growth of binaries over time and the inclusion of new features filled the available boot partition space, so that the kernel+initrd almost couldn't fit twice anymore as required for updates. We employed workarounds such as wrapper scripts for ignition, afterburn and other binaries so that they are loaded from /usr. However, this was still not enough and we would have to do the same for (network) kernel modules and firmware. To avoid making this ever more complex we can use a dedicated initrd focused on loading the full initrd from /usr and then this full initrd can use dracut as before and even drop all the workarounds we accumulated. Generate a minimal initrd to use instead of the full bootengine initrd. The bootengine initrd gets stored as squashfs on /usr. The minimal initrd still includes the early_cpio for amd64 microcode updates. We have a fixed list of modules or module directories to include, only focused on loading /usr and any emergency console interaction. This requires also checking for module dependencies to copy over. The busybox, veritysetup, and kmod binaries are needed and get their required libraries resolved and copied over. They are not static and use shared libraries which should be ok for now. The resulting vmlinuz file is 27 MB for amd64, down from ~60 MB, so we have enough room to include more kernel modules and so on for the next years while we also grow the boot partition and wait for users to redeploy until we can rely on a larger boot partition and eventually drop the minimal initrd again. Pulls in https://github.com/flatcar/bootengine/pull/110 for the minimal initrd script and https://github.com/flatcar/seismograph/pull/12 for making the device mapper discovery for the "rootdev" command more reliable. This also requied a backport of a kernel patch from 2017 that exposes the PARTUUID in the /sys uevent file. Co-authored-by: James Le Cuirot <jlecuirot@microsoft.com> Signed-off-by: Kai Lueke <kailuke@microsoft.com>
The changelog directory contains the description of the changes introduced
into the repository. The changes are essentially divided into 4 categories:
- changes: PRs bringing Changes and/or Enhancements
- bugfixes: PRs fixing existing issues
- security: PRs fixing security issues
- updates: PRs updating packages
How to add the file
Based on the category the PR falls into create a new file in the respective
directory with the filename format YYYY-MM-DD-<few-words-about-the-change>.md
(can be generated via: $(date '+%Y-%m-%d')-<few-words-about-the-change>.md).
The file should contain a markdown bullet point entry (- TEXT...).
Example for the bugfix section:
- The Torcx profile `docker-1.12-no` got fixed to reference the current Docker version instead of 19.03 which wasn't found on the image, causing Torcx to fail to provide Docker [scripts#1456](https://github.com/flatcar/scripts/pull/1456)
The contents of the file should describe the changes in a concise manner, and only contain information relevant for the end users. (use the past tense for the change/bugfix description to avoid confusion with the imperative voice for actions the user should do as a result). Security fixes of upstream packages and package updates can be kept short in most cases and follow a standard format.
As Updates refer to the package updates, contents of the file should be of
the following format: - Package Name ([Version](link to changelog)). Example:
- Linux ([5.10.77](https://lwn.net/Articles/874852/)). Note the leading dash
that will create a bullet list in the rendered markdown.
The security section follows this format:
- Package Name ([CVE-NUMBER](NIST-LINK), [CVE-NUMBER](NIST-LINK), ...)
E.g., Linux ([CVE-2021-4002](https://nvd.nist.gov/vuln/detail/CVE-2021-4002), [CVE-2020-27820](https://nvd.nist.gov/vuln/detail/CVE-2020-27820)).