#2727 Issue closed: MODULES=( 'loaded_modules' ) only loading loaded but no additional modules¶
Labels: enhancement, needs sponsorship, no-issue-activity
DEvil0000 opened issue at 2021-12-15 10:28:¶
- Description:
MODULES=( 'loaded_modules' 'other_module' )causes only loaded modules to get included as soon asloaded_modulesis in the array. I think it would be more usefull to have a mode for including loaded modules and some other modules in addition.
For example loaded modules normally guarantee the system is working on the same machine if it was working before. On recover however you may need to configure network interfaces a bit different e.g. with a vlan. Then you need a additional module for the vlan.
I suggest introducing a new key like loaded_modules_plus for this
functionallity so old config does not get broken. In case breaking is
okay I suggest to change the current loaded_modules to this behaviour
and add loaded_modules_only in addition.
see build/GNU/Linux/400_copy_modules.sh
- Workaround, if any:
MODULES=( 'all_modules' )
jsmeix commented at 2021-12-15 11:55:¶
@DEvil0000
could you describe why the default MODULES=( 'all_modules' )
does not work for your specific use case?
The reasoning for the default MODULES=( 'all_modules' )
is explained in default.conf - currently online at
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L1440
with links to issues that show some more details and examples
why MODULES=( 'all_modules' ) is basically the only reliably working
way
when migrating to different hardware.
An exception is when one does manual tests in advance
what exact kernel modules are needed on each kind of different
hardware
so that one has exact lists of kernel modules that one can specify as
MODULES=( 'moduleX' 'moduleY' ... )
Because currently MODULES=( 'loaded_modules' ) also adds
those in MODULES_LOAD another workaround could be
to specify additionally needed kernel modules via MODULES_LOAD
but then those kernel modules would get loaded during
recovery system startup in any case.
By the way regarding different networking hardware:
Some NICs require firmware upload so one may have to
also care about FIRMWARE_FILES when one does not
use the default here.
jsmeix commented at 2021-12-15 11:59:¶
When I understand why the default MODULES=( 'all_modules' )
is not sufficient for this or that specific use cases,
I would prefer to enhance it so that
MODULES=( 'moduleX' 'loaded_modules' 'moduleY' )
includes all loaded modules plus moduleX and moduleY.
jsmeix commented at 2021-12-15 12:10:¶
Hmmm...
default.conf reads (excerpts)
# An empty MODULES=() setting means that the currently loaded
# kernel modules get included in the recovery system
...
# MODULES=( 'moduleX' 'moduleY' ) where additional kernel modules
# can be specified to be included in the recovery system
# in addition to the ones via an empty MODULES=() setting.
but as far as I see from plain looking at the code in
400_copy_modules.sh
neither MODULES=() nor MODULES=( 'moduleX' 'moduleY' )
includes the currently loaded kernel modules
so it seems we have a bug here...
jsmeix commented at 2021-12-15 12:30:¶
@DEvil0000
https://github.com/rear/rear/pull/2728
is an untested quick attempt to fix it.
DEvil0000 commented at 2021-12-15 14:47:¶
MODULES=( 'all_modules' ) just increases the size quite a bit (which
increases creatin time, storage needed, bandwidth used and boot time -
especially over a slow network with pxe boot) this is why I am looking
into this.
MODULES=( 'loaded_modules' ) may not include some modules which may
still be needed later like the vlan module.
MODULES=( 'moduleX' 'moduleY' ) maintaining a long list is a option
but not exactly readable and a lot of work. So my idea was to use
something like this MODULES=( 'moduleX' 'loaded_modules' 'moduleY' )
as a good path in between.
I am aware of the firmware 'issue' but I know that I only need one specific rtl firmware and nothing else so I maintain a list for those. I can recommend https://serverfault.com/questions/1026598/know-which-firmware-my-linux-kernel-has-loaded-since-booting
having a look at the PR now.
github-actions commented at 2022-02-14 02:07:¶
Stale issue message
github-actions commented at 2022-04-16 02:42:¶
Stale issue message
hpannenb commented at 2022-04-18 07:20:¶
Hello bot. Do not steal interesting issues... :-)
jsmeix commented at 2022-04-20 08:08:¶
Huh!
I thought that "blocker" issues won't get touched by this bot?
Cf. exemptLabels: ...blocker in
https://github.com/rear/rear/blob/master/.github/stale.yml
(but I do not really understand the syntax in that file).
jsmeix commented at 2022-05-16 10:30:¶
The blocker issue is
https://github.com/rear/rear/pull/2728
which was triggered by this issue here at
https://github.com/rear/rear/issues/2727#issuecomment-994731345
The initial request in this issue here is its title
[MODULES=( 'loaded_modules' ) only loading loaded but no additional modules
asks for an enhancement.
That current behaviour is documented in default.conf
# The setting MODULES=( 'loaded_modules' ) results that
# only those kernel modules that are currently loaded
# get included in the recovery system.
Note the 'only' therein.
jsmeix commented at 2022-05-16 10:44:¶
With
https://github.com/rear/rear/commit/8b996de907477228904cfc097a854f60f5565e0b
it is now explicit in default.conf that
MODULES=( 'loaded_modules' 'additional_module' )
is not supported.
DEvil0000 commented at 2022-05-17 14:30:¶
Not sure how I should understand your documentation change and comment.
Do you want to implement this at some later point?
I would still like to have this feature. Loaded modules would not work
reliably for me since some modules may not be loaded all the time.
jsmeix commented at 2022-05-18 08:38:¶
In current ReaR it is now explicit in default.conf that
MODULES=( 'loaded_modules' 'additional_module' )
is not supported.
This issue is an enhancement request
for a future ReaR version after the
upcoming ReaR 2.7 release.
jsmeix commented at 2022-05-19 09:59:¶
@DEvil0000
I think there could be a (currently untested) workaround for
MODULES=( 'loaded_modules' 'additional_module' )
because also for MODULES=( 'loaded_modules' )
the kernel modules that should be loaded
during recovery system startup
i.e. the ones in MODULES_LOAD
get copied into the recovery system.
So instead of the unsupported
MODULES=( 'loaded_modules' 'moduleX' 'moduleY' )
you may use
MODULES=( 'loaded_modules' )
MODULES_LOAD+= ( 'moduleX' 'moduleY' )
But then 'moduleX' and 'moduleY'
are not only copied into the recovery system but also
explicitly loaded during recovery system startup via
/etc/modules in the recovery system and the startup script
skel/default/etc/scripts/system-setup.d/40-start-udev-or-load-modules.sh
which is /etc/scripts/system-setup.d/40-start-udev-or-load-modules.sh
inside the recovery system.
So this workaround would not help if those additional modules
should not be loaded during recovery system startup
but then I wonder why they are added when they are not needed?
See also the MODULES_LOAD description in default.conf
jsmeix commented at 2022-05-31 10:46:¶
Stupid me!
A nice example how a specific question could narrow my mind
thinking about a specific solution for the specific problem
while an existing generic solution does not come to my mind.
We do have generic methods in ReaR
how to include arbitrary things in the recovery system and
how to exclude arbitrary things from the recovery system:
COPY_AS_IS+=( ... )
COPY_AS_IS_EXCLUDE+=( ... )
This is also a solution for special cases like this one.
For example to include the kernel modules in
/lib/modules/.../kernel/drivers/net/wireless/realtek/rtlwifi
except the kernel modules that match
lib/modules/.../kernel/drivers/net/wireless/realtek/rtlwifi/rtl81*
one can use in etc/rear/local.conf
COPY_AS_IS+=( /lib/modules/$KERNEL_VERSION/kernel/drivers/net/wireless/realtek/rtlwifi )
COPY_AS_IS_EXCLUDE+=( lib/modules/$KERNEL_VERSION/kernel/drivers/net/wireless/realtek/rtlwifi/rtl81\* )
This is only a theoretical example.
I tested that the thereby specified modules are in the recovery system
but I did not test if only those thereby specified modules are
sufficient to make that kind of hardware work in practice, cf.
https://github.com/rear/rear/issues/1355
jsmeix commented at 2022-05-31 11:18:¶
Via
https://github.com/rear/rear/commit/decd4655f084688640283184472dd2399bae6297
I described in default.conf that one can use the generic
COPY_AS_IS method to include certain modules
in addition to the currently loaded modules when
MODULES=( 'loaded_modules' ) is specified.
jsmeix commented at 2022-05-31 11:21:¶
I myself will not implement support for
MODULES=( 'loaded_modules' 'additional_module' )
but when a sufficiently well made pull request is contributed
this functionality could be added to ReaR.
DEvil0000 commented at 2022-06-01 14:50:¶
when a sufficiently well made pull request is contributed
maybe I will find some time in a few month from now
github-actions commented at 2022-08-01 03:52:¶
Stale issue message
[Export of Github issue for rear/rear.]