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

OUTPUT=ISO
BACKUP=COMMVAULT
ISO_DIR=/opt/commvault/iDataAgent/systemrecovery
ISO_PREFIX=CVrearRescue
COMMVAULT_BASE=/opt/commvault/Base
CV_COMMCELL=XXXXXXXX
CV_CLIENTNAME=XXXXXXX
CV_SOURCE_CLIENT=XXXXXXXXXX
CV_BACKUPSET=defaultBackupSet
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):
ppc64le
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
BIOS
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
Local Disk
Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):

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:

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

Recovery:
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:¶

@anarayancv1
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":

RECOVERY_UPDATE_URL

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
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L361

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

Regarding the backup method, the manual page has this:

    BACKUP=GALAXY
       Use CommVault Galaxy 5 to restore the data.

   BACKUP=GALAXY7
       Use CommVault Galaxy 7 to restore the data.

   BACKUP=GALAXY10
       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
https://github.com/rear/rear/discussions/2640#discussioncomment-908335
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.