#913 Issue `closed`: If /boot partition is too small it should exit immediately or give me bigger warning¶

Labels: bug, cleanup, fixed / solved / done

blaskovic opened issue at 2016-07-14 10:24:¶

rear version (/usr/sbin/rear -V):
- Relax-and-Recover 1.17.2 / Git
OS version (cat /etc/rear/os.conf or lsb_release -a):

# cat /etc/rear/os.conf
OS_VENDOR=RedHatEnterpriseServer
OS_VERSION=7

rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):

OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL=file:///mnt/external-drive
GRUB_RESCUE=1

Brief description of the issue
- In case my /boot partition is too small to write iso file here, it just put a small warning, that it is not big enough. So if I run this in cron, I don't know if something went wrong and there is no ISO image in /boot.
- Then if I want to recover totally broken system, I can't because it does not contain recovery image
Work-around, if any
- I don't know it it exists - maybe I can resize /boot before

# rear -v mkbackup
Relax-and-Recover 1.17.2 / Git
Using log file: /var/log/rear/rear-qeos-149.log
mkdir: created directory '/var/lib/rear/output'
Creating disk layout
Excluding component fs:/mnt/rear-trash
Creating root filesystem layout
Copying files and directories
Copying binaries and libraries
Copying kernel modules
Creating initramfs
Making ISO image
Wrote ISO image: /var/lib/rear/output/rear-qeos-149.iso (121M)
WARNING: Not enough disk space available in /boot for GRUB2 rescue image
           Required: 118 MiB / Available: 52 MiB
Copying resulting files to file location
Encrypting disabled
Creating tar archive '/mnt/rear-trash/heyhere/qeos-149/backup.tar.gz'
Archived 814 MiB [avg 3863 KiB/sec]OK
Archived 814 MiB in 217 seconds [avg 3845 KiB/sec]

jsmeix commented at 2016-07-14 12:20:¶

@schlomo
this "WARNING:" is probably something for you to comment
( because I know what you think about warning messages ;-)

I am not al all an expert in this area but from my point of view
it seems having "enough disk space available" is a mandatory
condition to proceed.

In general I think rear should error out if mandatory
conditions to propceed are not fulfilled cf.
https://github.com/rear/rear/wiki/Coding-Style

I will do a pull request...

schlomo commented at 2016-07-14 12:42:¶

I would like to clarify what is happening here:

You are talking about adding the kernel and initrd to the GRUB(2) boot menu, not the ISO image.
This is an add-on feature which is enabled by GRUB_RESCUE=y. You should never rely on this feature for disaster recovery purposes. The main reason for this is to be quickly able to recover a server from soft errors like deleting all of /lib without digging out the rescue boot media.
ATM the code checks for sufficient free disk space before copying files.
If there is not enough space then we print this WARNING and continue. The reason is that the actual rescue media can still be successfully written later on. This means that the main objective of ReaR (create bootable rescue media off-server) was not compromised. This main objective was not compromised by the failure to add ReaR to the local boot configuration. Therefore this should be a WARNING and not an ERROR, IMHO

That said, if you want please submit a pull request that adds a new boolean variable GRUB_RESCUE_REQUIRED which will, when enabled, change the WARNING into an ERROR. For example, you could replace the return statement after the WARNING with a check for this variable and have it die there with a message like "GRUB_RESCUE is required but could not add ReaR". It would be also nice to have the same WARNING/ERROR behavior for other failure cases in this code path.

And please provide code for both GRUB and GRUB2 which are ATM handled in different files.

jsmeix commented at 2016-07-14 13:12:¶

I disagree.

I think when the user has specified in local.conf

GRUB_RESCUE=1

then it should mean that rear must do that
without the need for an additional

GRUB_RESCUE_REQUIRED

confirmation.

I.e. I think that an explicit setting in local.conf
is a mandatory request that rear must do that.

In contrast if the default would be "GRUB_RESCUE=1"
then one could consider that as "do it as far as possible"
depending on how that functionality is described
in usr/share/rear/conf/default.conf

@gdha

What do you think how settings in local.conf
should be meant in general?

jsmeix commented at 2016-07-14 13:19:¶

Perhaps the different points of view are because
in older rear versions the default was

GRUB_RESCUE=y

but nowadays it is changed to

GRUB_RESCUE=n

by git commit 7e098795
but git log only tells about that commit:

    * default.conf: GRUB_RESCUE=n instead of y before (to save space under /boot)

but no GitHub issue number.

jsmeix commented at 2016-07-14 13:29:¶

The initial commit where GRUB_RESCUE was added
was 5b02e4ff5d49aab9d2af8417fc1a6559b9d23dd7
but again no GitHub issue or other further information...

jsmeix commented at 2016-08-17 10:18:¶

The whole GRUB_RESCUE functionality is meanwhile
overhauled and documented in default.conf
via several pull requests (see above).
In particular the initial issue here was fixed
via https://github.com/rear/rear/pull/917

[Export of Github issue for rear/rear.]

#913 Issue closed: If /boot partition is too small it should exit immediately or give me bigger warning¶