Comment 115 for bug 1835660

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
>