initramfs unpacking failed

Bug #1835660 reported by vmc on 2019-07-07
This bug affects 31 people
Affects Status Importance Assigned to Milestone
initramfs-tools (Ubuntu)
linux (Ubuntu)

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.

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 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 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.

 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 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 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 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 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 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 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
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

Dan Andreșan (danyer) wrote :

Possible explanation and fix: in my case it seems the error message appeared since I enabled secure boot (which I think was disabled when I installed Ubuntu). Look below, from my journal:

Dec 05 15:07:52 elite kernel: secureboot: Secure boot could not be determined (mode 0)
Dec 05 15:07:54 elite systemd[1]: secureboot-db.service: Succeeded.
Dec 05 15:14:19 elite kernel: secureboot: Secure boot enabled
Dec 05 15:14:21 elite systemd[1]: secureboot-db.service: Succeeded.

You can see that on December 5th I booted at 15:07 without secureboot and starting with 15:14 with secureboot enabled.

And now, let's see when the error message appeared first:

$ journalctl|grep "unpacking failed"
Dec 05 15:14:19 elite kernel: Initramfs unpacking failed: Decoding failed

Now a possible fix (it was possible for me, it might be possible for you too):

What I did is that I switched compression to gzip, the message dissapeared, then back to lz4, still there is no sign of error (same result as tom in #18). My guess it that there is no need to switch it to gzip and back to lz4, but just regenerate initramfs (which we did after changing compression) with "sudo update-initramfs -u".

Maybe this takes into account that now I have secureboot enabled and generates a "compatible" initramfs.

Someone else should confirm if the fix works for them too, then I guess this bug can be closed.

Vincenzo Conti (vinc.o) wrote :

Still present in Ubuntu 20.04

Dan Andreșan (danyer) wrote :


can you confirm (or not) that you changed your secure boot settings since Ubuntu was installed? Can you check comment #26?


vmc (vmclark) wrote :

My Secure Boot is always off, and all three U, X, Kubuntu have the error, as of yesterdays ISO.

Edward Savage (epssyis) wrote :

Regenerating initramfs as suggested by Dan resolved this issue for me.

I did not attempt to change compression or change any settings in the BIOS.

vmc (vmclark) wrote :

Xubuntu 20.04 failed:
$ dmesg |grep failed
[ 0.456889] Initramfs unpacking failed: Decoding failed
[ 5.838496] thermal thermal_zone2: failed to read out thermal zone (-61)
[ 6.053231] [drm] failed to retrieve link info, disabling eDP

Then issued the following:

$ sudo update-initramfs -u
 It still fails. (sgage) wrote :

I am experiencing this issue as well. I had secure boot turned off - turned it back on, regenerated initramfs, and still have the problem. How does one change the compression method? (sgage) wrote :

I added COMPRESS=gzip to /etc/initramfs-tools/initramfs.conf and ran update-initramfs -u, and did NOT see the fail on the ensuing boot.

I've been experiencing this issue the last couple of days on Ubuntu 20.04 Focal Fossa too. Issuing

$ sudo update-initramfs -u

does nothing for me.
Adding COMPRESS=gzip to /etc/initramfs-tools/initramfs.conf didn't work either.

Paul White (paulw2u) on 2020-03-29
tags: added: focal
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:

tags: added: iso-testing
heynnema (heynnema) wrote :

Your shouldn't be using "sudo update-initramfs -u", you should try "sudo update-initramfs -c".

hasan (hasan-cerit) wrote :

confirmed on eoan (5.3.0-42) after heynnema comments above, that the decoding fail message disappears switching gzip then back to lz4.

editing initramfs.conf and running the command below:

~ $ sudo update-initramfs -c -k all

The result:

~ $ sudo cat /etc/initramfs-tools/initramfs.conf | grep lz4
# COMPRESS: [ gzip | bzip2 | lz4 | lzma | lzop | xz ]
~ $ dmesg | grep fail
~ $

hasan (hasan-cerit) wrote :

another note, just upgraded to latest kernel and the error is back...

~ $ uname -r
~ $ dmesg | grep fail
[ 0.218191] Initramfs unpacking failed: Decoding failed

Also on Focal:
corrado@corrado-x5-ff-0329:~$ dmesg | grep fail
[ 0.288574] Initramfs unpacking failed: Decoding failed
corrado@corrado-x5-ff-0329:~$ uname -a
Linux corrado-x5-ff-0329 5.4.0-21-generic #25-Ubuntu SMP Sat Mar 28 13:10:28 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Brian Murray (brian-murray) wrote :

@vmclark - Does this affect your ability to install or use the system at all?

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

I added the fix in comment #33 on two computers and this fixed the initramfs problem.

Dimitri John Ledkov (xnox) wrote :

I see that init/initramfs.c in the kernel tries to unpack our initrd as rootfs image, which is well, not going to happen, as it is not rootfs image but early,early2,main(lz4 compat) initramfs.

I wonder if kernel is tripping up on such mixed compression initrd.

However, it still boots fine. So this error is a bit bogus.

Not sure if we should improve how we generate our initrds, or fix kernel to cope with our initrds which have two early uncompressed ones, followed by lz4 compatible one.

Changed in initramfs-tools (Ubuntu):
status: New → Confirmed
importance: Undecided → High
Changed in linux (Ubuntu):
importance: Undecided → High
tags: added: rls-ff-incoming
removed: rls-ee-incoming
Ayyappan (kaysun) wrote :

Edit initramfs.conf as su.

Rem out COMPRESS-lz4 line

Run update-initramfs -u - System will return with "COMPRESS parameter not set".

Now edit initramfs.conf again. Remove the # on COMPRESS=lz4, run again update-initramfs -u.

It will close without any error. Reboot.

I just did and no more failed message.

Ayyappan (kaysun) wrote :

Follow-up on my previous post - Unpacking failed, Decoding failed is back on second boot. Please do not waste your time trying the above. Sorry.

Md Ayquassar (mdayquassar) wrote :

Same message for me. The grub menu waits for at least 6 seconds, I think, instead of 0. I won't try anything crazy out before new package version(s) appears, as it is a production system, and I can't repair it in case booting fails. Attachment: the initial part of the dmesg log.

Md Ayquassar (mdayquassar) wrote :

After "update-grub; update-initramfs -c -k all; update-grub" and a reboot, the message disappeared on the boot after the reboot. We'll see what happens next.

Saroumane (saroumane) wrote :

I had also the same message in dmesg. (I don't remember when it started)
Here : Ubuntu 19.10 booting a manually installed kernel (5.5.2-050502-generic)

I followed previous advices :

Adding COMPRESS=gzip to /etc/initramfs-tools/initramfs.conf (instead of lz4) then :
$ sudo update-grub;sudo update-initramfs -c -k all;sudo update-grub
No more error message, and systemd-analyse says :
Startup finished in 15.790s (firmware) + 3.112s (loader) + 9.986s (kernel) + 9.605s (userspace) = 38.495s reached after 9.595s in userspace

I restored COMPRESS=lz4 then
$ sudo update-grub;sudo update-initramfs -c -k all;sudo update-grub
Reboot : still no error message, and systemd-analyse says :
Startup finished in 15.793s (firmware) + 3.188s (loader) + 8.962s (kernel) + 11.645s (userspace) = 39.589s reached after 11.635s in userspace
(Yes it's slower but it might be me : I have to choose in grub menu selection and type full disk encryption password)

I rebooted a 3rd time : no change, still no more Decoding errors.

Dimitri John Ledkov (xnox) wrote :

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.

Changed in initramfs-tools (Ubuntu):
status: Confirmed → Invalid
description: updated
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers