Your message dated Sat, 30 Apr 2022 20:16:25 +0300
with message-id <52759981-e674-578e-a358-3cc8a6a6d...@tambre.ee>
and subject line Re: Bug#1009807: Kernels with no compression support no longer
work
has caused the Debian Bug report #1009807,
regarding Kernels with no compression support no longer work
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1009807: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009807
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: initramfs-tools
Version: 0.141
Severity: important
Dear maintainer,
I was using a custom downstream kernel required for my hardware. The
kernel had only CONFIG_RD_XZ enabled, which I wasn't aware of.
With version 0.141 initramfs creation fails with:
Processing triggers for initramfs-tools (0.141) ...
update-initramfs: Generating /boot/initrd.img-4.14.102-rt53
grep: /boot/config-4.14.102-rt53: No such file or directory
W: zstd compression (CONFIG_RD_ZSTD) not supported by kernel, using gzip
grep: /boot/config-4.14.102-rt53: No such file or directory
E: gzip compression (CONFIG_RD_GZIP) not supported by kernel
update-initramfs: failed for /boot/initrd.img-4.14.102-rt53 with 1.
dpkg: error processing package initramfs-tools (--configure):
installed initramfs-tools package post-installation script
subprocess returned error exit status 1
After commit 035190cc4385c0441dddc1bbaba000cf7f1f179b the code tries to
default to gzip if the first method didn't work, and errors if so.
Previously it would fall back to no compression.
While the setup is a bit exotic, falling back to no compression as a
last resort (with a warning) would be what I expect.
For robustness it would probably even be ideal to test support for all
that known methods in some order of preference and only then fall back
to no compression.
All the best,
Raul
--- End Message ---
--- Begin Message ---
Thanks for the extra background.
My kernel in question is actually for arm64, has all necessary drivers built-in
and initramfs has firmware prepended.
> It seems to me that your custom kernels have been booting without actually
using the main initramfs, because they could not decompress it and they had all
the necessary drivers built-in.
The boot logs contain "Unpacking initramfs..." and no subsequent error, which is
really strange as binwalk'ing the initrd shows it's gzip-compressed, but the
kernel was built with CONFIG_RD_GZIP=n.
I'll chalk this up as my error and have re-built the kernel with
CONFIG_RD_GZIP=y and will consider CONFIG_BLK_DEV_INITRD=n as I probably don't
actually need initramfs.
--- End Message ---
