#2869 Issue closed: Unable to boot ISO because of initrd size

Labels: support / question, no-issue-activity

anarayancv1 opened issue at 2022-09-27 23:25:

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"):

  • OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
    Red Hat Enterprise Linux Server 7.7 (Maipo)

  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):

COPY_AS_IS_COMMVAULT=( /opt/commvault /etc/CommVaultRegistry/Galaxy/Instance001 /etc/init.d/Galaxy /usr/bin/commvault )
COPY_AS_IS_EXCLUDE_COMMVAULT=( /opt/commvault/iDataAgent32/jobResults/\* /opt/commvault/iDataAgent64/jobResults/\* /opt/commvault/Base32/Temp/\* /opt/commvault/Base64/Temp/\* )
  • Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):

  • 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):

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


NAME                      KNAME      PKNAME    TRAN TYPE FSTYPE      LABEL           SIZE MOUNTPOINT
/dev/sda                  /dev/sda                  disk                              90G
|-/dev/sda1               /dev/sda1  /dev/sda       part                               4M
|-/dev/sda2               /dev/sda2  /dev/sda       part xfs                           1G /boot
`-/dev/sda3               /dev/sda3  /dev/sda       part LVM2_member                  89G
  |-/dev/mapper/rhel-root /dev/dm-0  /dev/sda3      lvm  xfs                          50G /
  |-/dev/mapper/rhel-swap /dev/dm-1  /dev/sda3      lvm  swap                          4G [SWAP]
  `-/dev/mapper/rhel-home /dev/dm-2  /dev/sda3      lvm  xfs                          35G /home
  • Description of the issue (ideally so that others can reproduce it):

We pack commvault (Galaxy) software into the initrd
because of which the ISO fails to boot.
Is there an option in the default.conf to copy
the commvault binaries outside the initrd
as part of ISO creation?

  • Workaround, if any:

Mount ISO; unpack the initrd;
mv the software outside initrd;
repack initrd;
recreate ISO

Boot ISO;
mv back the software back to the original folders and proceed with recovery

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

To paste verbatim text like command output or file content,
include it between a leading and a closing line of three backticks like

verbatim content

jsmeix commented at 2022-09-28 06:09:

I cannot find COMMVAULT in our current ReaR upstream sources,
in particular no variable names with COMMVAULT or CV_...
so I am wondering what ReaR you use - it seems you don't use
our ReaR but something else from somewhere else?

Regardless what ReaR you use regarding your actual question:

Is there an option in the default.conf
to copy ... binaries outside the initrd
as part of ISO creation?

There is no such config option in default.conf
that does what you exactly ask for.

The reason is that the initrd contains the files
of the whole ReaR recovery system - i.e. the system that is
running (from a ramdisk) after you booted from the ReaR ISO.
Not including files that belong to the ReaR recovery system
in the initrd contradicts the basic idea behind
what the initrd is meant to contain.

But there is a config option in default.conf
that should help to automate what you do as workaround,
in particular the workaround part during "rear recover":


See its description in the section

Relax-and-Recover recovery system update during "rear recover"

your default.conf which (hopefully) matches
your (apparently modified) ReaR that you use,
or see our ReaR upstream default.conf currently starting at

pcahyna commented at 2022-09-29 09:42:

Regarding the backup method, the manual page has this:

       Use CommVault Galaxy 5 to restore the data.

       Use CommVault Galaxy 7 to restore the data.

       Use CommVault Galaxy 10 (or Simpana 10) to restore the data.

so I am a bit surprised to see BACKUP=COMMVAULT instead of BACKUP=GALAXYsomething.

Anyway, concerning the underlying problem with the ISO failing to boot: do you get an error message? How do you know that it is because of the initrd size? It is probably a reasonable assumption, but I am curious if you have anything specific that indicates this (like a kernel error of GRUB error).

pcahyna commented at 2022-09-29 09:43:

I forgot to ask: what is actually the "bad" initrd size (when it fails to boot) and "good" size (when it boots)?

DEvil0000 commented at 2022-10-19 14:08:

excluding kernel modules you do not need may be the best way to reduce the size.

jsmeix commented at 2022-10-20 07:46:

From my experience the kernel firmware files
need much more space than the kernel modules, see
that reads (excerpt)

... I get about 200M for the bare ReaR recovery system
plus about 250M for all kernel modules
plus about 500M for the firmware files

So excluding kernel firmware files one does not need
is the most effective way to reduce ReaR's initrd size
(see FIRMWARE_FILES in default.conf)
and excluding kernel module files one does not need
is the second most effective way to reduce the initrd size
(see MODULES in default.conf)
but excluding kernel modules could become tricky because
of unexpected/obscure kernel module dependencies,
see https://github.com/rear/rear/issues/1355
and https://github.com/rear/rear/issues/2041
so in the end excluding kernel firmware files one does not need
is the simplest and most effective way to reduce initrd size.

jsmeix commented at 2022-10-20 07:52:

See also

DEvil0000 commented at 2022-11-03 13:15:

also keep in mind that your RAM size also limits the max ISO size you can boot. Just in case this is a limiting factor here.

DEvil0000 commented at 2022-12-13 15:47:

I just remembered there is also a config option for the partition size so a larger iso will fit - in case this was the issue.

github-actions commented at 2023-02-12 02:37:

Stale issue message

[Export of Github issue for rear/rear.]