[Bug 1835660] Re: initramfs unpacking failed

[babazako@yahoo.com]

I am also having this issue, however not a new install. I have been
running xubuntu 20.04.1 for two month +-

acer travelmate P215-52
Xubuntu 20.04.1
Kernel: 5.4.0-60 and 5.4.0-58
/ not encrypted
/Home is encrypted

The system worked fine. while booting the system drops to initramfs

with :
- Boot args ( cat /proc/cmdline)
 - Check rootdelay=(did the system wait long enough?)
- Missing modules (cat /proc/modules; ls /dev)
ALERT! UUID=***** dose not exist Dropping to shell

in the initramfs, /dev has no nvme drive or crypt drive, /dev/mapper/
has only control in it.

I did not have luck booting in to root via gurb, or getting a shell to edit files on the disk.
Grub shell is showing the root (hd0,gpt2) part /etc , /var... no issues with a cat command of the file on it. (hd0,gpt1) is a efi boot part.


Booting with live usb(xubuntu 20.04.1):
No local block device was found, so it was not possible to mount or a clean reinstall.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
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:
  Triaged

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