initramfs unpacking failed

Bug #1835660 reported by vmc on 2019-07-07
58
This bug affects 11 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Undecided
Unassigned

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.

vmc (vmclark) wrote :

This error is for Ubuntu eoan.

tags: added: eoan ubuntu

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1835660/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags: added: bot-comment
vmc (vmclark) on 2019-07-07
affects: ubuntu → initramfs-tools (Ubuntu)
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in initramfs-tools (Ubuntu):
status: New → Confirmed
tags: added: rls-ee-incoming
Steve Langasek (vorlon) wrote :

Just to confirm, you mean that this message is shown on the otherwise-blank console when booting with 'quiet'?

affects: initramfs-tools (Ubuntu) → linux (Ubuntu)
vmc (vmclark) wrote :

There are two messages that appear, the first is "initramfs unpacking failed: Decoding failed", right afterwards the partitions is clean message appears.

So, yes.

vmc (vmclark) wrote :

I also noticed on July 3rd thereabouts, was a change for 'lz4', that was approved.
 Not sure if I had this error then. I just started noticing around July 7th.

Brian Murray (brian-murray) wrote :

I also see this message in my journal but it doesn't seem to affect my system i.e. its booted and working.

Jul 10 09:22:14 speedy kernel: Unpacking initramfs...
Jul 10 09:22:14 speedy kernel: Initramfs unpacking failed: Decoding failed

vmc (vmclark) wrote :

As of today's ISO (7/11) installed, there is no "initramfs unpacking failed: Decoding failed" message. It appears solved.

vmc (vmclark) wrote :

"initramfs unpacking failed: Decoding failed" message still fails.
Using:

 eoan ubuntu-budgie, ISO dated 7/18/19

Gérard Bigot (gerard-bigot) wrote :

I also get this

   Trying to unpack rootfs image as initramfs...
   Initramfs unpacking failed: Decoding failed

on a fully uptodate eoan, just after booting today, in 'journalctl -b'.

vmc (vmclark) wrote :

as of 10/12/2019 eoan 19.10, Ubuntu, Lubuntu, Xubuntu still have this issue.

What I do to "fix" it is change:

COMPRESS=lz4, to COMPRESS=gzip, @:

/etc/initramfs-tools/initramfs.conf, then

 sudo update-initramfs -u.

tom (tombuntus) wrote :

Changing to gzip is bad. 19.10 switched over to lz4 because it's way faster decompressing, which makes for faster boots!

vmc (vmclark) wrote :

Did you read the part: "initramfs unpacking failed: Decoding failed".

  So what's the point if its faster and fails?

If you have splash on, you won't see the error message. use dmesg.

vmc (vmclark) wrote :

Boot up is actually faster after fix:

dmesg, boot-time b4-fix

$ dmesg|grep Decoding
[ 0.461068] Initramfs unpacking failed: Decoding failed
====
$ systemd-analyze
Startup finished in 14.140s (firmware) + 4.226s (loader) + 6.079s (kernel) + 17.270s (userspace) = 41.717s
graphical.target reached after 17.263s in userspace
====

dmesg, boot-time after-fix

$ dmesg|grep Decoding
====
$ systemd-analyze
Startup finished in 10.258s (firmware) + 3.650s (loader) + 3.262s (kernel) + 16.529s (userspace) = 33.701s
graphical.target reached after 16.507s in userspace

tom (tombuntus) wrote :

Boot lz4
Startup finished in 6.907s (firmware) + 8.338s (loader) + 2.595s (kernel) + 3.705s (userspace) = 21.547s
graphical.target reached after 3.695s in userspace

Will come back with gzip and see.

tom (tombuntus) wrote :

Boot lz4
Startup finished in 6.907s (firmware) + 8.338s (loader) + 2.595s (kernel) + 3.705s (userspace) = 21.547s
graphical.target reached after 3.695s in userspace

Boot gzip
Startup finished in 7.799s (firmware) + 8.070s (loader) + 3.562s (kernel) + 10.306s (userspace) = 29.739s
graphical.target reached after 10.162s in userspace

This is why developers switched to lz4!

It's really weird that vmclark is getting faster boot with gzip. It seems like a spinning hard drive and some other weird configurations are to blame.

tom (tombuntus) wrote :

Is yours failing? Mine is displaying the error message with lz4, but still booting and finding the root filesystem, that's what I thought this bug is about. You must not be failing either, as you have a boot time to measure. In the olden days, the other people who got this error weren't able to boot, and that's what failure to decode error means means.

tom (tombuntus) wrote :

Switching back to lz4, now I don't get the error! Maybe it's the newest kernel (.19 out today), or maybe it's just tweaking the decoding to gzip and back? Very strange.

Booting lz4 again
Startup finished in 7.775s (firmware) + 7.947s (loader) + 2.136s (kernel) + 9.105s (userspace) = 26.965s
graphical.target reached after 8.947s in userspace

Nick B. (futurepilot) wrote :

I still see this message on a fully up-to-date Kubuntu 19.10 system. However the system boots fine and everything seems to be working ok. This is apparently a non-fatal error message? It sounds pretty bad but it still seems to have been able to load the initramfs image fine. What does this really mean then?

Mario (mario-gleirscher) wrote :

Same for me.

I am on Ubuntu 19.10 with EFI Secure Boot and dual boot with Windows 10 (fastboot/hibernation disabled)

uname -a
... 5.3.0-26-generic #28-Ubuntu ...

initramfs-tools are still configured to produce a LZ4 image (the default)

dmesg | grep -i "error\|fail\|warn"
[ 0.504105] Initramfs unpacking failed: Decoding failed
[ 0.589422] i8042: Warning: Keylock active
[ 6.677615] EXT4-fs (nvme0n1p3): re-mounted. Opts: errors=remount-ro

Often booting fails but works after a couple of tries, resulting in this dmesg output.

No clue, it exceeds my knowledge what's going on here.

I fully reinstalled the kernel image and grub boot loader from the Live CD.

Mario (mario-gleirscher) wrote :

After reinstallation, the issue persists (see dmesg in my last comment) but my machine manages to boot (with EFI Secure Boot!).

Mario (mario-gleirscher) wrote :

For sake of completeness, dmesg says:

[ 0.476436] Trying to unpack rootfs image as initramfs...
[ 0.559806] Initramfs unpacking failed: Decoding failed
[ 0.565777] Freeing initrd memory: 46704K

Does that mean that the kernel is booting without using initramfs?

I was also looking whether the initrd image needs to be signed in order to be used in a UEFI Secure Boot scenario. But I couldn't find any information on whether Ubuntu's initramfs-tools or other scripts sign initrd, it surely comes with signed kernel images which seem to work fine.

Anyway, booting my machine is still a dice rolling experiment.

Per-Inge (per-inge-hallin) wrote :

Added Fedora 31 and made a triple boot system with Ubuntu 20.04, Windows 10 and Fedora 31.
Fedora stored the boot record in /dev/sdc1 and I had to change boot disk to sdc in BIOS.
Fedora provides a boot menu with
Fedora
Ubuntu
Windows
When I start Ubuntu via the Fedora boot menu I get this error message.

Per-Inge (per-inge-hallin) wrote :

I get different behavior depending on how I boot the computer using the BIOS boot menu
- When I select sda with Ubuntu 20.04, I don't get the error message
- When I select sdc with Fedora 31 and select Ubuntu from Fedora's boot menu I get the error message

Willem Hobers (whobers) wrote :

I am seeing this in my log as well,

Kubuntu 19.10

Linux willem-Aspire-A315-53 5.3.0-29-generic #31-Ubuntu SMP Fri Jan 17 17:27:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Operating System: Kubuntu 19.10
KDE Plasma Version: 5.17.5
KDE Frameworks Version: 5.66.0
Qt Version: 5.12.4
Kernel Version: 5.3.0-29-generic
OS Type: 64-bit
Processors: 8 × Intel® Core™ i5-8250U CPU @ 1.60GHz
Memory: 3,7 GiB

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers