Comment 137 for bug 1835660

Revision history for this message
paul-lawrenceville (pkowalzyk) wrote : Re: [Bug 1835660] Re: initramfs unpacking failed

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
>