#2041 Issue closed
: Have MODULES=( 'all_modules' ) in default.conf¶
Labels: enhancement
, fixed / solved / done
jsmeix opened issue at 2019-02-13 10:46:¶
I had planned to ask for MODULES=( 'all_modules' )
in default.conf
after the ReaR v2.5 release but in the sprit of
https://github.com/rear/rear/issues/2040
I ask now:
For the ReaR v2.5 release I would like to have in default.conf
MODULES=( 'all_modules' )
instead of the current MODULES=()
.
Reasoning:
Missing kernel modules in the recovery system lead to
arbitrary bad situations where there is no way out, e.g.:
- keyboard not usable in the recovery system
https://github.com/rear/rear/issues/1870
https://github.com/rear/rear/issues/1860 - data on external medium (e.g. iso9660) not readable
https://github.com/rear/rear/issues/1202
The current MODULES=()
relies on 'modprobe --show-depends'
to include dependant modules but that does not work reliably
to really get all actually needed modules included, see
https://github.com/rear/rear/issues/1355
In contrast MODULES=( 'all_modules' )
is simple, straightforward
and works reliably to get a usable recovery system.
Space requirements:
On my SLES15-like openSUSE Leap 15.0 UEFI system
(I always use FIRMWARE_FILES='no'
)
I get the following rear -D mkrescue
output (excerpts):
With MODULES=()
Copying kernel modules
Omit copying files in /lib*/firmware/ (FIRMWARE_FILES='no')
...
Created initrd.cgz with gzip default compression (94486284 bytes)
in 12 seconds
...
Wrote ISO image: /root/rear.github.master/var/lib/rear/output/rear-g243.iso
(137M)
With MODULES=( 'all_modules' )
Copying all kernel modules in /lib/modules/4.12.14-lp150.12.25-default (MODULES contains 'all_modules')
Omit copying files in /lib*/firmware/ (FIRMWARE_FILES='no')
...
Created initrd.cgz with gzip default compression (131624857 bytes)
in 18 seconds
...
Wrote ISO image: /root/rear.github.master/var/lib/rear/output/rear-g243.iso
(172M)
With MODULES=( 'loaded_modules' )
Copying only currently loaded kernel modules (MODULES contains 'loaded_modules')
Omit copying files in /lib*/firmware/ (FIRMWARE_FILES='no')
...
Created initrd.cgz with gzip default compression (72226920 bytes)
in 9 seconds
...
Wrote ISO image: /root/rear.github.master/var/lib/rear/output/rear-g243.iso
(115M)
With MODULES=( 'no_modules' )
Omit copying kernel modules (MODULES contains 'no_modules')
Omit copying files in /lib*/firmware/ (FIRMWARE_FILES='no')
...
Created initrd.cgz with gzip default compression (67826749 bytes)
in 9 seconds
...
Wrote ISO image: /root/rear.github.master/var/lib/rear/output/rear-g243.iso
(111M)
For comparison with our defaults FIRMWARE_FILES=()
and MODULES=()
Copying kernel modules
Copying all files in /lib*/firmware/
...
Created initrd.cgz with gzip default compression (264035881 bytes)
in 26 seconds
...
Wrote ISO image: /root/rear.github.master/var/lib/rear/output/rear-g243.iso
(298M)
versus with FIRMWARE_FILES=()
and MODULES=( 'all_modules' )
Copying all kernel modules in /lib/modules/4.12.14-lp150.12.25-default (MODULES contains 'all_modules')
Copying all files in /lib*/firmware/
...
Created initrd.cgz with gzip default compression (301086749 bytes)
in 32 seconds
...
Wrote ISO image: /root/rear.github.master/var/lib/rear/output/rear-g243.iso
(334M)
jsmeix commented at 2019-02-18 08:57:¶
@rear/contributors
what do you think about it?
Any comments?
jsmeix commented at 2019-02-18 09:06:¶
@schabrolles
having MODULES=( 'all_modules' )
by default would
increase the recovery system ISO by about 35 MiB (in my case).
Could this cause unexpected bad effects on POWER architecture
with its special limits of the recovery system size?
Perhaps on POWER that 35 MiB more may result a too big initrd
which can cause arbitrary other strange issues there, cf.
https://github.com/rear/rear/issues/1724#issuecomment-364070280
That issue was also a reason for the md5sum verification
https://github.com/rear/rear/issues/1859
so that now broken files in the recovery system should be
at least detected.
gozora commented at 2019-02-18 09:10:¶
I personally don't mind having MODULES=( 'all_modules' )
(until I can
set whatever I like in local.conf, which I can).
Do you think it would make sense to wait with such change to ReaR 3.0
?
At least I'm reading release notes more carefully when upgrading between
major versions. So there is a chance, that people administering
thousands of servers will not be surprised when they end up with full
filesystems ;-).
V.
schabrolles commented at 2019-03-02 08:22:¶
@jsmeix, I've tested it on my POWER system, it works even if it add 14MB
extra size on the initrd file.
If problem, we could still add MODULES=( )
in the local.conf, right ?
jsmeix commented at 2019-03-04 11:20:¶
Of course settings in local.conf overwrite those from default.conf
(because local.conf is sourced after default.conf in usr/sbin/rear)
and I verified that right now on my test system to be 100% sure.
jsmeix commented at 2019-03-04 11:52:¶
@rear/contributors
if there are no objections I would like to set tomorrow in default.conf
MODULES=( 'all_modules' )
I consider this change "backward compatible" because
- there is no lost or different functionality (just more functionality)
- it is normal that a new version of whatever software may need some more resources (in this case disk and RAM space)
- the 100% identical old behaviour can still be manually specified
Nevertheless this changes will be described in the
"possibly backward incompatible changes" part in out
Release Notes for Relax-and-Recover version 2.5
https://github.com/rear/rear.github.com/blob/master/documentation/release-notes-2-5.md
jsmeix commented at 2019-03-06 10:42:¶
drumroll...
jsmeix commented at 2019-03-06 15:35:¶
Puh!
Implementing it became more complicated than expected,
see
https://github.com/rear/rear/pull/2069
jsmeix commented at 2019-03-07 12:31:¶
With
https://github.com/rear/rear/pull/2069
merged
I consider this issue to be (hopefully) fixed/solved/done.
If hell breakes loose now I can fix things
or even revert
https://github.com/rear/rear/pull/2069
for ReaR 2.5.
jsmeix commented at 2019-03-07 13:14:¶
It is now documented in the
New features, bigger enhancements, and possibly backward incompatible changes
section of the ReaR 2.5 release notes
https://github.com/rear/rear.github.com/blob/master/documentation/release-notes-2-5.md
[Export of Github issue for rear/rear.]