[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1009807: marked as done (Kernels with no compression support no longer work)

Your message dated Sat, 30 Apr 2022 20:16:25 +0300
with message-id <52759981-e674-578e-a358-3cc8a6a6d9ee@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 owner@bugs.debian.org
immediately.)


-- 
1009807: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009807
Debian Bug Tracking System
Contact owner@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 ---
Reply to: