#3585 Issue closed: Lower default ISO_FILE_SIZE_LIMIT for PowerPC Systems¶
Labels: enhancement, won't fix / can't fix / obsolete,
special hardware or VM
abbbi opened issue at 2026-03-16 08:46:¶
hi,
multiple users already filed bugreports about failing to boot the
recovery image
on Powerpc due to initrd size limits (latest one #3332, for example).
I think it would make sense to enforce a lower
ISO_FILE_SIZE_LIMIT
for PowerPC to make the recovery image creation fail directly, instead
of having the users fail
on a later stage during recovery?
Or would it even make sense to have a specifc check for the initrd file created in place?
pcahyna commented at 2026-03-16 08:56:¶
I don't think so, because ISO_FILE_SIZE_LIMIT applies to all files on
the ISO, including for example the backup archive (backup.tar.gz) if
embedded into the image, which is not a problem at all, right?
jsmeix commented at 2026-03-16 10:08:¶
https://github.com/rear/rear/issues/3332
is about ReaR's initrd size on POWER architecture
which is basically a duplicate of
https://github.com/rear/rear/issues/3189
which I (hopefully) fixed via what I listed in
https://github.com/rear/rear/issues/3189#issuecomment-2112897378
and
https://github.com/rear/rear/pull/3233
As @pcahyna told in his
https://github.com/rear/rear/issues/3585#issuecomment-4066087861
changing the ISO_FILE_SIZE_LIMIT default seems to be
not the proper setting for ReaR's initrd on POWER.
I am not a POWER architecture user so I don't know
details there - in particular not with all its
different modes (LPAR vs. other kind of VMs on POWER).
When on POWER architecture it cannot happen
that there is a backup.tar.gz included in the ISO
so on POWER architecture the ReaR's initrd is the
biggest file in the ISO image, then it could make sense
to have a lower default ISO_FILE_SIZE_LIMIT on POWER?
But the current ISO_FILE_SIZE_LIMIT implementation
via the function assert_ISO_FILE_SIZE_LIMIT() in
lib/output-functions.sh would need to be enhanced
to make its current generic Error message
Error "File for ISO $( basename $file_for_iso ) size $file_for_iso_size greater or equal ISO_FILE_SIZE_LIMIT=$ISO_FILE_SIZE_LIMIT"
meaningful for the specific ReaR initrd case on POWER
so users understand why ReaR errors out in this case
as currently the LogPrintError messages tell in
pack/GNU/Linux/900_create_initramfs.sh
see
https://github.com/rear/rear/pull/3233#issuecomment-2128788475
how those current LogPrintError messages look like, e.g.
On POWER architecture booting may fail when the initrd is big (about 120 MiB or even less)
Verify that your ReaR recovery system boots on your replacement hardware.
If it fails to boot consider the following:
REAR_INITRD_COMPRESSION='lzma' for better (but slower) initrd compression
MODULES=('loaded_modules') to include less kernel modules in the initrd
FIRMWARE_FILES=('no') to excludes all firmware files from the initrd
COPY_AS_IS_EXCLUDE_TSM to get a slim TSM client in the initrd
@abbbi
when in your particular case ReaR's initrd is the
biggest file in the ISO image, then you can specify
ISO_FILE_SIZE_LIMIT as it is appropriate
for your particular case.
jsmeix commented at 2026-03-16 10:22:¶
Something like this might look like a possible solution:
IF on POWER and BACKUP_URL is not 'iso://...'
THEN set ISO_FILE_SIZE_LIMIT to 120 MiB
But (at least currently) I have no idea how I could
properly implement that in a ReaR script e.g. like
usr/share/rear/pack/GNU/Linux/900_create_initramfs.sh
ISO_FILE_SIZE_LIMIT is a user config variable and
ReaR must not change user settings in ReaR scripts.
Only in default.conf user config defaults can be set
because then the user can override them as needed.
pcahyna commented at 2026-03-16 10:53:¶
When on POWER architecture it cannot happen
that there is a backup.tar.gz included in the ISO
so on POWER architecture the ReaR's initrd is the
biggest file in the ISO image, then it could make sense
to have a lower default ISO_FILE_SIZE_LIMIT on POWER?
I have been using backup.tar.gz included in the ISO on POWER architecture often.
jsmeix commented at 2026-03-16 11:18:¶
Because of
https://github.com/rear/rear/issues/3585#issuecomment-4066624194
and
https://github.com/rear/rear/issues/3585#issuecomment-4066799723
I close it - at least for now - as "can't fix".
[Export of Github issue for rear/rear.]