I want to sincerely thank you for your information. I assume that you are
referring to my ubuntu based Linux Mint 20.04 problem. Since yesterday, I
have removed and installed Mint 20.1 and find a little error with my
initramfs but I have nothing to worry about. I will file this in my archive
of Mint/Ubuntu remedies. Thank you for your input.



On Wed, Jan 13, 2021, 3:41 PM Ubuntu Kernel Bot <email address hidden>
wrote:

> This bug is missing log files that will aid in diagnosing the problem.
> While running an Ubuntu kernel (not a mainline or third-party kernel)
> please enter the following command in a terminal window:
>
> apport-collect 1835660
>
> and then change the status of the bug to 'Confirmed'.
>
> If, due to the nature of the issue you have encountered, you are unable
> to run this command, please add a comment stating that fact and change
> the bug status to 'Confirmed'.
>
> This change has been made by an automated script, maintained by the
> Ubuntu Kernel Team.
>
> ** Changed in: linux (Ubuntu)
>        Status: New => Incomplete
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1870260).
> 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:
>   Incomplete
>
> 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
>