Works well, thank you for the update.


On Fri, Mar 26, 2021, 7:31 AM Armandoobnaiala <email address hidden>
wrote:

> update-initramfs: Generating /boot/initrd.img-5.8.0-45-generic
> /usr/sbin/mkinitramfs: 177: COMPRESS: parameter not set
> update-initramfs: failed for /boot/initrd.img-5.8.0-45-generic with 2.
>
>
> ** Changed in: initramfs-tools (Ubuntu Focal)
>      Assignee: (unassigned) => Armandoobnaiala (armando1986)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1835660
>
> Title:
>   initramfs unpacking failed
>
> Status in OEM Priority Project:
>   New
> Status in grub2 package in Ubuntu:
>   Invalid
> Status in initramfs-tools package in Ubuntu:
>   Invalid
> Status in linux package in Ubuntu:
>   Fix Released
> Status in grub2 source package in Focal:
>   Invalid
> Status in initramfs-tools source package in Focal:
>   Invalid
> Status in linux source package in Focal:
>   Fix Released
> Status in grub2 source package in Groovy:
>   Invalid
> Status in initramfs-tools source package in Groovy:
>   Invalid
> Status in linux source package in Groovy:
>   Fix Released
> Status in grub2 source package in Hirsute:
>   Invalid
> Status in initramfs-tools source package in Hirsute:
>   Invalid
> Status in linux source package in Hirsute:
>   Fix Released
>
> Bug description:
>   "initramfs unpacking failed: Decoding failed",  message appears on
>   boot up.
>
>   If I "update-initramfs" using gzip instead of lz, then boot up passes
>   without decoding failed message.
>
>   ---
>
>   However, we currently believe that the decoding error reported in
>   dmesg is actually harmless and has no impact on usability on the
>   system.
>
>   Switching from lz4 to gzip compression, simply papers over the
>   warning, without any benefits, and slows down boot.
>
>   Kernel should be fixed to correctly parse lz4 compressed initrds, or
>   at least lower the warning, to not be user visible as an error.
>
>   [Impact]
>
>    * Decoding failure messages in dmsg with a single lz4 initrd
>
>    * Multiple lz4 compressed initrds cannot be decompressed by kernel,
>   when loaded by grub
>
>    * Multiple lz4 compressed initrds cannot be decompressed by kernel,
>   when there is padding between them
>
>   [Test Case]
>
>    * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4
>
>    * Create an lz4 compressed initrd with a single test-file in it with
>   some content. I.e. echo "second-initrd" > test-file, and then pack
>   that with cpio hewc owned by root & lz4 -l.
>
>    * Create a combined padded initrd of stock initrd, pad4, and the
>   test-marker initrd created above.
>
>    * Boot above with "break=top" kernel command line.
>
>    * With broken kernels, there should be dmesg error message that
>   decoding failed, and one will observe that /test-file does not exist
>   in the shell.
>
>    * With fixed kernel, /test-file in the initrd shell should exist, and
>   should have the expected content "second-initrd".
>
>    * The alignment and padding in the above test case depends on the
>   size of the first initrd => if a given padded initrd does not
>   reproduce the problem, try varying the size of the first initrd or
>   that of the padding between 0..4.
>
>
>   [Where problems could occur]
>
>    * This changes compatible lz4 decompressor in the kernel, which can
>   also be used by other kernel modules such as cryptography, squashfs,
>   zram, f2fs, comprssed kernel image, pstore. For example, previously
>   rejected files with "bogus" length and extra padding may now be
>   accepted, whereas they were previously getting rejected by the
>   decompressor.
>
>    * Ideally kernel should switch to the stable lz4 format which has
>   better specification of end of stream.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions
>