```
update-initramfs: Generating /boot/initrd.img-5.19.0-35-generic
grep: /boot/config-5.19.0-35-generic: No such file or directory
W: zstd compression (CONFIG_RD_ZSTD) not supported by kernel, using gzip
grep: /boot/config-5.19.0-35-generic: No such file or directory
E: gzip compression (CONFIG_RD_GZIP) not supported by kernel
update-initramfs: failed for /boot/initrd.img-5.19.0-35-generic with 1.
```
LP: #2018171
Signed-off-by: Benjamin Drung <benjamin.drung@canonical.com>
With MODULES=dep, we walk a few /sys/ paths to include panel drivers
based on what we know. These might not be enough to catch everything,
and we don't have enough data to know what we are missing.
Instead of only walking sysfs directories for select buses and specific
panel drivers, do it for any panel-related driver under any bus.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Apparently display panels connected over MIPI DSI can show up under /sys
as e.g. `/sys/bus/mipi-dsi/drivers/panel-boe-tv101wum-nl6/` on a MT8183
Chromebook tablet [1]. The related `mt8183-kukui.dtsi` device-tree file
indeed has the `panel` device under a `&dsi0` section. Presumably, we
also need to include modules for this and similar drivers in initramfs
to get a working display on these boards.
Add a wildcard for the mipi-dsi bus to the list of /sys/ paths we walk
for panel drivers when MODULES=dep.
[1] https://lore.kernel.org/linux-mediatek/CAJMQK-jOgkRzYOTsiuUY4X8hzcGQL0XRiJSs7giiShnRb=nO_A@mail.gmail.com/
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Originally reported in the Kali Linux bug tracker: it's not possible to
type the LUKS password, in case of full disk encryption, in a Gen2
Hyper-V virtual machine. This is due to missing support for keyboard.
The original bug is at https://bugs.kali.org/view.php?id=7846, and I'll
quote the bits that are relevant:
> Because Generation 2 virtual machines in Hyper-V are presented with a
> minimal set of EFI hardware, the kernel module "hyperv_keyboard" must
> be present to interact with the console keyboard. On systems with disk
> encryption, the user will be prompted for the key to decrypt the disk,
> but cannot enter the password because no keyboard driver is present.
>
> [...]
>
> This module *is* present when the grub menu is presented and later
> when the kernel is fully loaded. FYI, if some mechanism requires a
> mouse or touch, the hid_hyperv module will also be needed.
This issue also affects Debian, as discussed in:
<https://forums.debian.net/viewtopic.php?t=131468>
This issue was also reported in the Ubuntu tracker, back in 2016:
<https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1567107>
It was fixed in Ubuntu, but the changes never made it to Debian.
This commit adds the module hyperv-keyboard along with the other
keyboard drivers.
Closes: #1028511
If the kernel command line has `ip=` in it, it is arguable that
configure_networking should be run.
Add `qemu-net` autopkgtest to test the behavior for several values of
the `ip=` cmdline parameter.
Closes: #789067
LP: #1463846
Signed-off-by: Benjamin Drung <benjamin.drung@canonical.com>
Include drivers for MediaTek USB3 Dual Role controller along with other
USB drives. ARM64 Chromebooks do not have a usable platform framebuffer
available with their stock firmware, so add the drivers needed to get
visible output (for initramfs password prompts).
There seem to be a few dependency chains not expressed in module info
with these devices. Add those who would not be included even with a
devlink supplier relation as hidden dependencies.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
ldd can print warnings about user installed libraries:
```
$ env --unset=LD_PRELOAD ldd /usr/lib/x86_64-linux-gnu/plymouth//two-step.so
/usr/lib/x86_64-linux-gnu/plymouth//two-step.so: /usr/local/lib/x86_64-linux-gnu/libpng16.so.16: no version information available (required by /lib/x86_64-linux-gnu/libply-splash-graphics.so.5)
linux-vdso.so.1 (0x00007ffc0f9fe000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f349dd70000)
libply.so.5 => /lib/x86_64-linux-gnu/libply.so.5 (0x00007f349dd52000)
libply-splash-core.so.5 => /lib/x86_64-linux-gnu/libply-splash-core.so.5 (0x00007f349dd2f000)
libply-splash-graphics.so.5 => /lib/x86_64-linux-gnu/libply-splash-graphics.so.5 (0x00007f349dd1e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f349daf6000)
/lib64/ld-linux-x86-64.so.2 (0x00007f349de84000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f349daca000)
libpng16.so.16 => /usr/local/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f349da7e000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f349da62000)
```
This causes `copy_exec` to parse the warning and wanting to install the
analyzed `two-step.so` library again (and then failing).
LP: #2046570
Signed-off-by: Benjamin Drung <benjamin.drung@canonical.com>
Echoing shell code that sets the variables `ec1` and `ec2` when
evaluated is way too complicated for implementing pipefail (which is not
available in dash). Just write the exit code to FD 3 instead.
Signed-off-by: Benjamin Drung <benjamin.drung@canonical.com>
To potentially reduce the execution time a bit, call qemu with
`-nodefaults`. Only the serial console is needed to be setup.
The execution time of `amd64-virtio-only` on an AMD Ryzen 7 5700G system
reduced from 10.01 +- 0.04 seconds to 9.82 +- 0.04 seconds. This
improvement is neglectable on amd64, but could be noticeable on slower
architectures.
Signed-off-by: Benjamin Drung <benjamin.drung@canonical.com>
With MODULES=dep, we walk through sysfs to add device-specific modules,
and their dependencies based on `modprobe --show-depends`. However in
embedded systems, a lot dependency relations ended up being expressed
only in device-tree instead of in the usual ways.
This dependency information is exposed in sysfs as a "devlink" [1],
where each involved driver is a "consumer" or "supplier" [2] of the
link. Not including suppliers for a driver in initramfs can make it
defer probing indefinitely, leading to breakage. This led to dracut
including them as well [3].
While walking sysfs for modules we want to add, also walk their
suppliers and add those as well. The supplier dependencies can have
cycles in them, so we can't recursively call sys_walk_mod_add. Instead,
do an iterative traversal of the dependency graph to collect all device
paths we need to look into, then actually add the modules for those.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/sysfs-class-devlink?h=v6.6
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/sysfs-devices-supplier?h=v6.6
[3] https://github.com/dracutdevs/dracut/pull/2075
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Group tests with identical dependencies that will support the same
number of architectures in a later commit.
Signed-off-by: Benjamin Drung <benjamin.drung@canonical.com>
Explicitly specify supported architectures. Then the restriction
`skip-not-installable` can be dropped.
Signed-off-by: Benjamin Drung <benjamin.drung@canonical.com>
Instead of spreading all temporary files in the temporary directory,
create one common sub-directory in the temporary directory named
`initramfs-test` and place everything inside there. This makes looking
at the generated files easier.
Signed-off-by: Benjamin Drung <benjamin.drung@canonical.com>
The `amd64-separate-usr` autopkgtest fails always in a Debian unstable
schroot environment (with overlayfs) with:
```
genext2fs: couldn't allocate a block (no free space)
```
This is caused by specifying a too small amount of blocks:
```
$ mkdir /tmp/empty
$ genext2fs -b 20 -N 12 -U -d /tmp/empty /tmp/empty.raw
genext2fs: couldn't allocate a block (no free space)
$ genext2fs -b 25 -N 12 -U -d /tmp/empty /tmp/empty.raw
copying from directory /tmp/empty
```
Increase the minimum to 28 blocks solved the failure.
Signed-off-by: Benjamin Drung <benjamin.drung@canonical.com>
