#2688 Issue closed: Ubuntu 20.04 initrd "decoding failed" - needs special command to make initrd

Labels: support / question, no-issue-activity

will-code-for-pizza opened issue at 2021-09-30 14:34:

Relax-and-Recover (ReaR) Issue Template

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

  • ReaR version ("/usr/sbin/rear -V"):
    Relax-and-Recover 2.5 / Git (Ubuntu 20.04 distro package)

  • OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):

VERSION="20.04.3 LTS (Focal Fossa)"
PRETTY_NAME="Ubuntu 20.04.3 LTS"
  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):


BACKUP_PROG_EXCLUDE=( '/media/*' '/mnt/*' '/BACKUP/*' '/cache/*' '/tmp/*' '/dev/shm/*' $VAR_DIR/output/\* )


EXCLUDE_COMPONENTS=( 'swap:/dev/mapper/rootvg-swaplv' 'fs:/tmp' 'fs:/var/cache' )
REQUIRED_PROGS+=( 'ifenslave' )
GRUB2_MODULES_LOAD+=( 'bonding' )
  • Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):

HPe Proliant DL580 Gen8

  • System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):


  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):

Legacy BIOS activated, GRUB

  • Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):

local disks (HDD and SSD)

NAME                            KNAME      PKNAME    TRAN TYPE FSTYPE        SIZE MOUNTPOINT
/dev/loop0                      /dev/loop0                loop squashfs     61.8M /snap/core20/1081
/dev/loop1                      /dev/loop1                loop squashfs     55.5M /snap/core18/2074
/dev/loop2                      /dev/loop2                loop squashfs     67.6M /snap/lxd/20326
/dev/loop3                      /dev/loop3                loop squashfs     67.3M /snap/lxd/21545
/dev/loop4                      /dev/loop4                loop squashfs     32.3M /snap/snapd/12883
/dev/loop6                      /dev/loop6                loop squashfs     55.4M /snap/core18/2128
/dev/loop7                      /dev/loop7                loop squashfs     32.3M /snap/snapd/13170
/dev/sda                        /dev/sda             sas  disk             558.7G
|-/dev/sda1                     /dev/sda1  /dev/sda       part                 1M
|-/dev/sda2                     /dev/sda2  /dev/sda       part ext4            2G /boot
`-/dev/sda3                     /dev/sda3  /dev/sda       part LVM2_member 556.7G
  |-/dev/mapper/rootvg-rootlv   /dev/dm-2  /dev/sda3      lvm  ext4            4G /
  |-/dev/mapper/rootvg-swaplv   /dev/dm-3  /dev/sda3      lvm  swap            4G [SWAP]
  |-/dev/mapper/rootvg-tmplv    /dev/dm-4  /dev/sda3      lvm  ext4            4G /tmp
  |-/dev/mapper/rootvg-varlv    /dev/dm-5  /dev/sda3      lvm  ext4            6G /var
  |-/dev/mapper/rootvg-varloglv /dev/dm-6  /dev/sda3      lvm  ext4            2G /var/log
  |-/dev/mapper/rootvg-homelv   /dev/dm-7  /dev/sda3      lvm  ext4            8G /home
  |-/dev/mapper/rootvg-usrlv    /dev/dm-8  /dev/sda3      lvm  ext4            4G /usr
  `-/dev/mapper/rootvg-optlv    /dev/dm-9  /dev/sda3      lvm  ext4            2G /opt
/dev/sdb                        /dev/sdb             sas  disk LVM2_member   4.6T
|-/dev/mapper/datavg-varliblv   /dev/dm-0  /dev/sdb       lvm  ext4            2G /var/lib
`-/dev/mapper/datavg-srvlv      /dev/dm-1  /dev/sdb       lvm  ext4            2G /srv
  • Description of the issue (ideally so that others can reproduce it):
After 'mkrescue' and 'mkbackuponly' without any errors I tried to restore the machine,
bootin´ with rescue-iso-image.

System loads ISO:

Rescue image kernel 5.4.0-84-generic Thu, 30 Sept 2021 15:35:23 +0200
BACKUP_NETFS OUTPU=ISO BACKUP_URL=nfs://139.1.xxx.xxx/srv/IMAGES/rear/myserver
Loading kernel... ok
Loading initrd.cgz...ok

Decoding failed

--System halted
  • Workaround, if any:

No workaround

  • Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):

No attachements

Thanks in advance !

jsmeix commented at 2021-10-01 10:10:

By googling for initrd "decoding failed" I found e.g.
that both have links to (rather old from 2019)
so it seems the root cause is in Ubuntu and not in ReaR
but I am not a Ubuntu user so I cannot check Ubuntu issues myself.

Specifying an appropriate REAR_INITRD_COMPRESSION (see default.conf)
should help for systems that cannot decompress the ReaR default initrd.

will-code-for-pizza commented at 2021-10-05 13:00:

unfortunatelly none of the compression options worked for me.


All options result in "decoding failed" --- System halted.

Will Code

jsmeix commented at 2021-10-05 14:43:

I think you need to find out what the right command is
that creates an initrd for the specific system you have
so that this initrd can then be decompressed/decoded
by the specific kernel that runs on your particular system.

When you know that command you can modify your
to let it run that command instead of what it currently does.
If it then works to boot the ReaR recovery system in your case
please tell us that exact command that created the initrd for you
so we could have a look what the differences are compared to
what 900_create_initramfs.sh currently does so that we
may finally enhance 900_create_initramfs.sh accordingly.

will-code-for-pizza commented at 2021-10-06 07:20:

Ok, I will do that.
Many thanks for the hint. Give me a few hours, please.

will-code-for-pizza commented at 2021-10-25 12:22:

After some days of searching the internet, I found serveral depending issues.
The command for creating initrd in Ubuntu 20.04 is done in 'mkinitramfs'.


will-code-for-pizza commented at 2021-10-25 12:35:

I think, I found it....

/usr/share/rear/pack/GNU/Linux/900_create_initramfs.sh (ReaR)

cpio -H newc --create --quiet | lz4 -l > "$TMP_DIR/$REAR_INITRD_FILENAME"

cpio -H newc --create --quiet | xz --format=lzma --compress --stdout > "$TMP_DIR/$REAR_INITRD_FILENAME"

cpio -H newc --create --quiet | gzip --fast > "$TMP_DIR/$REAR_INITRD_FILENAME"

cpio -H newc --create --quiet | gzip --best > "$TMP_DIR/$REAR_INITRD_FILENAME"

cpio -H newc --create --quiet | gzip > "$TMP_DIR/$REAR_INITRD_FILENAME"

/usr/sbin/mkinitramfs (Ubuntu 20.04)

cpio --quiet $cpio_owner_root --reproducible -o -H newc | gzip >>"${outfile}"

cpio --quiet $cpio_owner_root --reproducible -o -H newc 4>&-; echo "ec2=$?;" >&4


cpio_owner_root="-R 0:0"

will-code-for-pizza commented at 2021-10-25 12:47:

So I will create a new
(custom) entry in /usr/share/rear/pack/GNU/Linux/900_create_initramfs.sh

cpio -R 0:0 --reproducible -o -H newc | gzip > "$TMP_DIR/$REAR_INITRD_FILENAME"

and try out...

will-code-for-pizza commented at 2021-10-25 17:09:





        # Create initrd.cgz with gzip compression (the UBUNTU way)
        LogPrint "Creating recovery/rescue system initramfs/initrd $REAR_INITRD_FILENAME with gzip the UBUNTU way"
        if find . ! -name "*~" | cpio -R 0:0 --reproducible -o -H newc | gzip > "$TMP_DIR/$REAR_INITRD_FILENAME" ; then
            needed_seconds=$(( $( date +%s ) - start_seconds ))
            LogPrint "Created $REAR_INITRD_FILENAME with gzip the UBUNTU way ($( stat -c%s $TMP_DIR/$REAR_INITRD_FILENAME ) bytes) in $needed_seconds seconds"
            # No need to clean up things (like 'popd') because Error exits directly:
            Error "Failed to create recovery/rescue system $REAR_INITRD_FILENAME"

jsmeix commented at 2021-10-26 08:23:

thank you for your analysis what the root cause is
and for your solution!

I will add your solution to the ReaR code.

will-code-for-pizza commented at 2021-10-27 08:27:

@jsmeix: You´re welcome. This is how OpenSource should work ;-)
Thanks for your support.

will-code-for-pizza commented at 2021-10-27 15:34:

Unfortunatelly, the error occurs again.
I have to investigate deeper.

Booting into "Recover" succeeded most of the time. Booting in "Automatic recover" always failed.


jsmeix commented at 2021-10-28 06:28:

do you mean booting in "Automatic recover" always fails with

Loading kernel... ok
Loading initrd.cgz...ok
Decoding failed

as in your initial https://github.com/rear/rear/issues/2688#issue-1012259248
or does booting in "Automatic recover" fail differently?

I ask because offhandedly I could not imagine
how booting in "Automatic recover" mode
could make a difference about initrd decoding
because one same initrd is used.

jsmeix commented at 2021-11-02 13:32:

what looks a bit strange is that we at ReaR upstream
do not have another same issue report from another user
but I know that there are several users with Ubuntu 20.04
so I wonder how ReaR with Ubuntu 20.04 works for them?

I.e. it could be something special in your environment
why no other ReaR users with Ubuntu 20.04
seem to also have this "Decoding failed" issue?

will-code-for-pizza commented at 2021-11-10 08:31:

Hi @jsmeix and thanks for reply.
Sorry for the late answer from my site.

For me, the problem described in #2688 (comment) often occurs while choosing "Automatic recover".
I have to investigate further to be totally sure and will report my findings here.

Your arguments about Ubuntu 20.04 and a bunch of other users WITHOUT problems seems logical.
Probably it could depend on networking issues.

I´ll be back soon.


DEvil0000 commented at 2021-11-11 21:15:

I am running on ubuntu 20.04 and did not face such a issue. I however never tested auto recover. The command change however is unlikely to make a difference.
I use output=ISO and output=USB normally with backup=borg on HP and other hardware.

did you try with rear 2.6 instead of 2.5? Or with master?
I don't think this is a rear issue at all. Maybe ubuntu but I don't think so. Did you update your HP firmware?
HP firmware tends to have all sorts of crazy bugs.
Thinking a bit more about it this may be bootloader config or kernel commandline options as well. Since systemd the commandline options and startup changed a bit. Not sure how automatic recover is done.

github-actions commented at 2022-01-15 02:23:

Stale issue message

[Export of Github issue for rear/rear.]