#3553 PR `merged`: Automatically include firmware files for the kernel modules in the recovery system¶

Labels: enhancement, fixed / solved / done

jsmeix opened issue at 2026-01-12 17:25:¶

In build/GNU/Linux/420_copy_firmware_files.sh
automatically include firmware files
for the kernel modules in the recovery system
see https://github.com/rear/rear/issues/3551

pcahyna commented at 2026-01-13 13:04:¶

Thanks @jsmeix, this sounds good, but as a user I don't understand the details of how it works. The documentation for FIRMWARE_FILES is here : https://github.com/rear/rear/blob/96aae1e7b504e069d3f07641f05874ed0bb3eaf4/usr/share/rear/conf/default.conf#L1914 , does it need updating? (Has the interpretation of the special values changed? I see you are deleting a comment in the code about the meaning of empty FIRMWARE_FILES ...)

jsmeix commented at 2026-01-13 13:33:¶

Of course default.conf gets adapted accordingly.
I thought I could do this today morning
but "something else" got in my way :-(

jsmeix commented at 2026-01-13 15:07:¶

Yesterday I tested
MODULES=( 'loaded_modules' )
with empty FIRMWARE_FILES
and for me things look good so far.

On my openSUSE Leap 15.6 workstation with AMD graphics
(built-in in CPU "Ryzen 3 4300G with Radeon Graphics")
the amdgpu kernel module is loaded which needs firmware:

# usr/sbin/rear -D mkrescue
...
Using build area: /var/tmp/rear.9vpz6XhzEPiqZGk
...
Copying only currently loaded kernel modules (MODULES contains 'loaded_modules') and those in MODULES_LOAD
Copying firmware files that belong to the copied kernel modules (FIRMWARE_FILES not specified)
...

# du -hs /var/tmp/rear.9vpz6XhzEPiqZGk/rootfs/
246M    /var/tmp/rear.9vpz6XhzEPiqZGk/rootfs/

For comparison with

FIRMWARE_FILES=( 'yes' )
MODULES=( 'loaded_modules' )

what one would normally do when one does not know
which firmware files are needed

# usr/sbin/rear -D mkrescue
...
Using build area: /var/tmp/rear.JB1vAflGYIR1Del
...
Copying only currently loaded kernel modules (MODULES contains 'loaded_modules') and those in MODULES_LOAD
Copying all files in /lib*/firmware/
...

# du -hs /var/tmp/rear.JB1vAflGYIR1Del/rootfs/
784M    /var/tmp/rear.JB1vAflGYIR1Del/rootfs/

and with

FIRMWARE_FILES=( 'no' )
MODULES=( 'loaded_modules' )

what results a recovery system where graphical display may not work
depending on whether or not the used AMD graphics hardware
can work in standard (VGA) modes without firmware:

# usr/sbin/rear -D mkrescue
...
Using build area: /var/tmp/rear.AR44mXniirFRtbv
...
Copying only currently loaded kernel modules (MODULES contains 'loaded_modules') and those in MODULES_LOAD
Omit copying files in /lib*/firmware/ (FIRMWARE_FILES='no')
...

# du -hs /var/tmp/rear.AR44mXniirFRtbv/rootfs/
221M    /var/tmp/rear.AR44mXniirFRtbv/rootfs/

The amdgpu firmware files are not so much:

# du -hs /lib/firmware/amdgpu/
31M     /lib/firmware/amdgpu/

jsmeix commented at 2026-01-13 15:15:¶

It is questionable how far the "modinfo -F firmware" method
actually works reliably in practice because:

On my original system (where "rear mkrescue" is run):

# find /lib/firmware/amdgpu/ | wc -l
639

# modinfo -F firmware amdgpu | wc -l
576

With

FIRMWARE_FILES=( 'yes' )
MODULES=( 'loaded_modules' )

# find /var/tmp/rear.JB1vAflGYIR1Del/rootfs/lib/firmware/amdgpu/ | wc -l
639

versus with

FIRMWARE_FILES=()
MODULES=( 'loaded_modules' )

# find /var/tmp/rear.9vpz6XhzEPiqZGk/rootfs/lib/firmware/amdgpu/ | wc -l
566

pcahyna commented at 2026-01-13 15:43:¶

@jsmeix

It is questionable how far the "modinfo -F firmware" method actually works reliable in practice because: (...)

As I am not familiar with this area, I am curious what problem do you see there. Could you please be more specific?

jsmeix commented at 2026-01-13 15:50:¶

I am also not familiar with this area.
What I am doing here are my first steps in this area.

I mean the non-matching numbers of the firmware files
indicate things could be inconsistent- in particular
needed firmware files could be missing because they
might not be listed by "modinfo -F firmware"?

See also in my initial desctiption
https://github.com/rear/rear/issues/3551#issue-3796994085

... it is normal that some firmware files
which are listed by modinfo
may not exist on the system.

I.e. currently the whole "modinfo -F firmware" stuff
looks somewhat inconsistent/unreliable to me.

Tomorrow I will investigate more (as time permits).

jsmeix commented at 2026-01-16 13:34:¶

With the new DebugPrint when no file is found in /lib*/firmware
that matches the partial firmware filename which is reported
by modinfo for a kernel module
those numbers make more sense to me (at least in my specific case).

I got

# usr/sbin/rear -D mkrescue
...
Using build area: /var/tmp/rear.CIShROSO7xxV54s
...
Copying only currently loaded kernel modules (MODULES contains 'loaded_modules') and those in MODULES_LOAD
Copying firmware files that belong to the copied kernel modules (FIRMWARE_FILES not specified)
No file in /lib*/firmware matching 'amdgpu/cyan_skillfish_gpu_info.bin' (reported by modinfo for 'amdgpu')
No file in /lib*/firmware matching 'amdgpu/ip_discovery.bin' (reported by modinfo for 'amdgpu')
No file in /lib*/firmware matching 'amdgpu/vega10_cap.bin' (reported by modinfo for 'amdgpu')
No file in /lib*/firmware matching 'amdgpu/sienna_cichlid_cap.bin' (reported by modinfo for 'amdgpu')
No file in /lib*/firmware matching 'amdgpu/navi12_cap.bin' (reported by modinfo for 'amdgpu')
No file in /lib*/firmware matching 'amdgpu/aldebaran_cap.bin' (reported by modinfo for 'amdgpu')
No file in /lib*/firmware matching 'amdgpu/gc_11_0_0_toc.bin' (reported by modinfo for 'amdgpu')
No file in /lib*/firmware matching 'amdgpu/sienna_cichlid_mes1.bin' (reported by modinfo for 'amdgpu')
No file in /lib*/firmware matching 'amdgpu/sienna_cichlid_mes.bin' (reported by modinfo for 'amdgpu')
No file in /lib*/firmware matching 'amdgpu/navi10_mes.bin' (reported by modinfo for 'amdgpu')
No file in /lib*/firmware matching 'amdgpu/gc_11_0_3_mes.bin' (reported by modinfo for 'amdgpu')
No file in /lib*/firmware matching 'renesas_usb_fw.mem' (reported by modinfo for 'xhci_pci')

and /var/tmp/rear.CIShROSO7xxV54s/rootfs/lib/firmware/amdgpu
contains all firmware files which are reported by modinfo
in particular for the 'amdgpu' kernel module
except those in the DebugPrint message
i.e. those which do not exist on my system.

jsmeix commented at 2026-01-16 13:39:¶

I think my current implementation is all what I can do
in practice to automatically include firmware files
for the kernel modules in the recovery system
so I would like to merge it in its current state.

@rear/contributors
please have a look (as time permits)
and ideally try it out how it behaves on your systems
in particular with MODULES=( 'loaded_modules' )
and the default empty FIRMWARE_FILES=()
because this is the main case where I would like
to get things automatically working reasonably well.

pcahyna commented at 2026-01-26 13:41:¶

Hi @jsmeix , can you give me a few more days, please? I would like to have a look but have not had time for it lately.

jsmeix commented at 2026-01-26 14:18:¶

@gdha
thank you for testing it!

@pcahyna
yes of course - there is nothing urgent here.
I explicitly requested a review from you now.

pcahyna commented at 2026-02-09 13:13:¶

I found out that the size of firmware and consequently of the initramfs keeps increasing, which makes this kind of improvements more and more valuable. Let me try on RHEL to see the effect...

jsmeix commented at 2026-03-23 12:46:¶

@rear/contributors
I would like to merge it on Thursday afternoon
unless there are objections.

We are still in ReaR 3.0 development phase
so if this changes cause more problems than they solve
we can try to improve things to make things work
or I can simply revert things to what it was before.

In any case the default behaviour did not change
(excerpts from the default.conf description)

The by default empty FIRMWARE_FILES array
together with the default MODULES=( 'all_modules' )
results that normally all files in the /lib*/firmware/
directories get included in the rescue/recovery system.

and the user can explicity specify MODULES and FIRMWARE_FILES
according to what he needs in his particular environment
regardless what our new default behaviour is which is now

When MODULES does not contain 'all_modules'
(e.g. when MODULES=( 'loaded_modules' ) is specified),
then an empty FIRMWARE_FILES array results that
firmware files which belong to those kernel modules
which get included in the rescue/recovery system
get also included in the rescue/recovery system

pcahyna commented at 2026-03-25 19:16:¶

Hello @jsmeix , thank you for the reminder. I researched the topic in detail and found that it is actually quite complicated (as it is often the case). I see two main problems with the current state of the PR:

Regarding what the does: it looks incomplete to me. When MODULES=( 'loaded_modules' ) and FIRMWARE_FILES is empty, we should copy firmware for all loaded modules, but some modules can be built-in and those can also have firmware. (On a RHEL kernel, most of them don't, but I saw at least one having a firmware, and this can change if you build your own kernel and decide that some hardware drivers should be compiled in.) Here's a WIP fix of this issue, using the list /lib/modules/$KERNEL_VERSION/modules.builtin that newer kernels provide, and the ability of sufficiently new modinfo to query even builtin modules:

diff --git a/usr/share/rear/build/GNU/Linux/420_copy_firmware_files.sh b/usr/share/rear/build/GNU/Linux/420_copy_firmware_files.sh
index 462fc7ad3..9b9a9493c 100644
--- a/usr/share/rear/build/GNU/Linux/420_copy_firmware_files.sh
+++ b/usr/share/rear/build/GNU/Linux/420_copy_firmware_files.sh
@@ -61,9 +61,42 @@ fi
 # Automatically also copy the matching firmware files here, see
 # https://github.com/rear/rear/issues/3551
 LogPrint "Copying firmware files that belong to the copied kernel modules (FIRMWARE_FILES not specified)"
-for module in "${COPY_MODULES[@]}" ; do
-    firmware_partial_filenames=$( modinfo -k $KERNEL_VERSION -F firmware "$module" ) || continue
-    for firmware_partial_filename in $firmware_partial_filenames ; do
+local builtin_list="/lib/modules/$KERNEL_VERSION/modules.builtin"
+local firmware_partial_filenames=()
+
+local modinfo_error=0
+if [ -f "$builtin_list" ] ; then
+    local builtin_path
+    local builtin_modules=(
+        $(
+            while read -r builtin_path; do
+                builtin_mod="$(basename "$builtin_path")"
+                # remove the .ko (and possibly other) suffix
+                echo "${builtin_mod%%.*}"
+            done < "$builtin_list"
+        )
+    )
+    for module in "${COPY_MODULES[@]}" "${builtin_modules[@]}" ; do
+        # grep needs to be there as some versions of modinfo print "name: <module name>" for builtin modules
+        # even if not asked for it.
+        if ! firmware_partial_filenames+=( $( modinfo -k $KERNEL_VERSION -F firmware "$module" | grep -v '^[[:alnum:]]*:[[:blank:]]'; exit ${PIPESTATUS[0]} ) ); then
+            # This may happen when $builtin_list is present but
+            # /lib/modules/$KERNEL_VERSION/modules.builtin.modinfo is not.
+            # Only sufficiently new kernels provide modules.builtin.modinfo.
+            # The RHEL 8 kernel, for example, does not.
+            modinfo_error=$?
+            LogPrintError "Error determining firmware files for kernel module $module"
+            LogPrint "The command modinfo -k $KERNEL_VERSION -F firmware $module returned $modinfo_error"
+            break
+        fi
+    done
+else
+    LogPrintError "Unable to determine builtin module list to list firmware in use ($builtin_list not found)"
+    modinfo_error=1
+fi
+
+if [[ "$modinfo_error" == 0 ]] ; then
+    for firmware_partial_filename in "${firmware_partial_filenames[@]}" ; do
         # For example the command "modinfo -F firmware amdgpu" may show
         # amdgpu/cyan_skillfish_gpu_info.bin
         # amdgpu/navi12_gpu_info.bin
@@ -81,4 +114,13 @@ for module in "${COPY_MODULES[@]}" ; do
         fi
         cp $verbose -t $ROOTFS_DIR -p -L --parents $firmware_complete_filename
     done
-done
+else
+    LogPrintError "Defaulting to copy all firmware files - determining firmware in use not possible"
+    # TODO: copy of a block above - unify
+    LogPrint "Copying all files in /lib*/firmware/"
+    # Use a simple 'cp -a' for this case to be safe against possible issues
+    # with the more complicated 'find ... | xargs cp' method below.
+    # The '--parents' is needed to get the '/lib*/' directory in the copy.
+    # It is crucial to append to /dev/$DISPENSABLE_OUTPUT_DEV (cf. 'Print' in lib/_framework-setup-and-functions.sh):
+    cp $verbose -t $ROOTFS_DIR -a --parents /lib*/firmware 2>>/dev/$DISPENSABLE_OUTPUT_DEV 1>&2
+fi

Regarding the interface. The problem with the (by default) empty FIRMWARE_FILES is that the meaning changes according to the value of MODULES. When MODULES=( 'all_modules' ), it means a different thing than if MODULES has any other value. I don't like this kind of long-lange interaction. (Of course I know that there are long-range interactions in the code, expressed for example in global variables, but here I mean the interaction between the value of the variables.) Not only it is inelegant and hard for the user to keep track of (one must be aware of the value of one variable in order to understand the meaning of the value of another variable), it also prevents a valuable use case: copying all the firmware that belongs to any of the available modules (because to copy all the available modules, one uses MODULES=( 'all_modules' ) , but this changes the meaning of FIRMWARE_FILES=() from "copy the firmware of all the modules that get copied", which we would like here, to "copy all firmware files").
Why do I care about this? I believe that copying all the modules (not just the loaded ones) and only the firmware files that belong to these modules (instead of all) is the most valuable use case for these features, actually. It produces an image that can be used on the widest range of hardware, while reducing the initramfs size by omitting the firmware files that are not used by any module, and thus presumably useless.
Now the questions are of course, how to specify it and then how to implement it. Regarding the specification, perhaps a special value would be the best option, something like FIRMWARE_FILES=( 'copied_modules' ) or perhaps a scalar FIRMWARE_FILES='copied_modules'. I don't like special values, especially as array elements, but we have been using it for modules as well. Alternatively, a special scalar variable like ADD_MODULE_FIRMWARE=y/n could be used.
Regarding the implementation, this is of course made difficult by the need of listing all the copied modules, which we don't know if we copy everything. For this, the modules.dep file can be used as it lists all the modules. I started looking at this, but then I got distracted by other things. Gemini suggested this code (would need to be improved, I suppose - see the patch above that implements the part with builtin modules a bit differently):

KERNEL_VER=$(uname -r)
MOD_DIR="/lib/modules/${KERNEL_VER}"

get_all_firmware() {
    # =========================================================
    # PIPELINE 1: Loadable Modules (via modules.dep)
    # =========================================================
    # 1. awk -F: -> Extract the relative path (left side of the colon).
    # 2. sed -> Prepend the base directory to make absolute paths.
    # 3. xargs -> Pass physical files directly to modinfo.

    if [[ -f "${MOD_DIR}/modules.dep" ]]; then
        awk -F: '{print $1}' "${MOD_DIR}/modules.dep" \
            | sed "s|^|${MOD_DIR}/|" \
            | xargs -r modinfo -F firmware 2>/dev/null
    fi

    # =========================================================
    # PIPELINE 2: Built-in Modules (via modules.builtin)
    # =========================================================
    # 1. awk -F/ -> Strip the directory paths.
    # 2. sed -> Strip .ko and compression extensions to get pure names.
    # 3. xargs -> Pass NAMES to modinfo (using -k to force the lookup).

    if [[ -f "${MOD_DIR}/modules.builtin" ]]; then
        awk -F/ '{print $NF}' "${MOD_DIR}/modules.builtin" \
            | sed -E 's/\.ko(\..*)?$//' \
            | xargs -r modinfo -k "${KERNEL_VER}" -F firmware 2>/dev/null
    fi
}

In order to not block the merging for too long, I suggest that we agree on the proper interface of specifying only the copied modules and do the actual implementation of the combination of this with MODULES=( 'all_modules' ) separately (until it is implemented, we can error out when this combination is provided).

jsmeix commented at 2026-03-31 13:11:¶

@pcahyna
I may have a closer look at your above
https://github.com/rear/rear/pull/3553#issuecomment-4129123318
at the earliest after Easter public holidays
(in Germany until including 06. April)
perhaps later as other (non-ReaR) issues may permit.

A question:
Is there something actually wrong
with the changes as this pull request currently is
so it must not be merged in its current state
because this will cause real bugs
(cf. "bug" in https://github.com/rear/rear/labels)
OR
would the current state be acceptable to be merged
as a first step into the right direction
which should be further adaptend and enhanced
as you described in your above
https://github.com/rear/rear/pull/3553#issuecomment-4129123318
?

The thing is:
If the current state would be an acceptable first step
we could move forward step by step as neded and as time permits
because further adaptions and enhancements could be done
via subsequent pull requests as long as we are
in the ReaR 3.0 development phase.
But currently with
https://github.com/rear/rear/pull/3553#issuecomment-4129123318
moving forward within the ReaR 3.0 development phase
is blocked for an unpredictable period of time.

In general:
When something in a pull request is actually wrong
so it must not be merged in its current state,
then the reviewer should set the review state to
Request changes
to make this clear.

jsmeix commented at 2026-04-07 09:12:¶

As usual:
Security issues elsewhere got in my way to proceed here.

codacy-production commented at 2026-08-26 10:01:¶

Up to standards ✅¶

🟢 Issues 0 issues

>
> > **Results:** > `0` new issues > > [View in > Codacy](https://app.codacy.com/gh/rear/rear/pull-requests/3553/issues) >

_{NEW Get contextual insights on your PRs based on Codacy's
metrics, along with PR and Jira context, without leaving GitHub. Enable
AI
reviewer}
_{TIP This summary will be updated as you push new changes.}

jsmeix commented at 2026-08-26 11:15:¶

Regarding item 2. in
https://github.com/rear/rear/pull/3553#issuecomment-4129123318
excerpts

a valuable use case:
copying all the firmware that belongs to any of the available modules
...
I believe that copying all the modules (not just the loaded ones)
and only the firmware files that belong to these modules
(instead of all) is the most valuable use case for these features,
actually.
It produces an image that can be used on the widest range of hardware,
while reducing the initramfs size by omitting the firmware files
that are not used by any module

This means there must be firmware files installed
which are never used by any installed kernel module
or by anything which is built-in into the kernel.

Offhandedly I assume this should normally not happen
because I (perhaps falsely) assume that whatever
is responsible for what gets installed on a system
(e.g. RPM package dependencies or whatever)
ensures to some reasonable extent that
nothing is installed which is absolutely useless.

If something is installed which is absolutely useless
then this is an issue that should not be handled by ReaR
but by whatever (or whoever) is responsible for what is
installed on a system.

My basic reasoning is that the current
MODULES=( 'all_modules' ) automatically means
also "all firmware" i.e. FIRMWARE_FILES=( 'yes' )
to ensure no firmware is missing in the recovery system.

I assume one cannot rely on that
modinfo -F firmware "$module"
will always correctly report all firmware files
(i.e. the transitive closure of firmware files)
which could be ever used by the kernel
(either built-in or via loadable modules).

If it happens in practice relatively often that
a large amount of firmware files is installed
which is absolutely useless, we can discuss
if this needs to be handled in ReaR or if it is
better to leave it to our users to do some
modinfo -F firmware "$module" scripting
to deal with that issue as needed on their own.

I mean:
When a large amount of useless firmware files is installed
on the original system, why not leave it to the users
to fix their original systems?

jsmeix commented at 2026-08-26 12:39:¶

I asked Google AI regarding firmware for built-in kernel stuff:

in Linux "modinfo -F firmware module_name" lists
firmware files that are needed by a kernel module.
How can one find out what firmware files are needed
by stuff that is directly built-in into the kernel?

Google AI replied (excerpts):

You can find firmware needed by built-in drivers by querying the modules.builtin.modinfo file located in /lib/modules/$(uname -r)/

Using modules.builtin.modinfo

Modern Linux kernels generate a database of metadata for
statically built-in drivers right alongside loadable modules.
You can parse this file with grep or strings to extract
required firmware strings.

tr '\0' '\n' < /lib/modules/$(uname -r)/modules.builtin.modinfo | grep '^firmware='

Alternative Methods

Check Kernel Configuration:

Inspect your active kernel config file
(found in /boot/config-$(uname -r) or via /proc/config.gz)
to see which drivers are set to =y (built-in)
rather than =m (module).
You can then cross-reference those driver names
using standard modinfo against an external
module copy if available.

cf.

https://bbs.archlinux.org/viewtopic.php?id=256518

https://stackoverflow.com/questions/9845877/how-to-determine-if-a-specific-module-is-loaded-in-linux-kernel

https://unix.stackexchange.com/questions/805966/how-to-identify-which-modules-are-builtin-the-kernel-and-which-require-external

jsmeix commented at 2026-08-26 13:08:¶

Regarding item 2. in
https://github.com/rear/rear/pull/3553#issuecomment-4129123318
excerpt

The problem with the (by default) empty FIRMWARE_FILES is
that the meaning changes according to the value of MODULES

Yes, and that's intentional.

I introduced FIRMWARE_FILES in March 2017 via
https://github.com/rear/rear/commit/8b7118c976e832a0a402e46b6e8af33e796222ef
from
https://github.com/rear/rear/pull/1256
and
https://github.com/rear/rear/issues/1216

Before we had a hardcoded

COPY_AS_IS=( ... /lib*/firmware ... )

in usr/share/rear/conf/GNU/Linux.conf

At that time FIRMWARE_FILES was separated from MODULES.

Meanwhile things advanced over time so now
MODULES is some kind of main/master variable
and FIRMWARE_FILES behaves as subordinate variable
as long as FIRMWARE_FILES is empty.

This is in compliance with our usual meaning/handling
of empty variables in ReaR, cf. 'default.conf'

Most variables can be set to an empty value VAR=
which means that this setting is off
or set to some automatic mode.

I think you prefer strictly independent variables.

But this is not and never was the case in ReaR.

E.g. since all the time I know about ReaR
"If you do not specify OUTPUT_URL variable
then by default it will be aligned to what was
defined by variable BACKUP_URL" (cf. "man rear").

jsmeix commented at 2026-08-26 13:15:¶

What is really missing here is
https://github.com/rear/rear/pull/3553#issuecomment-4129123318
item 1. (excerpt)

some modules can be built-in and those can also have firmware

i.e. support for

/lib/modules/$KERNEL_VERSION/modules.builtin

I think firmware files for built-in kernel stuff
must get copied into the recovery system in any case
except explicit user request FIRMWARE_FILES=( 'no' )
forbids ReaR to copy firmware files.

jsmeix commented at 2026-08-27 13:07:¶

My last commit
https://github.com/rear/rear/pull/3553/changes/39074e8c09dd6a1e6936d0543f64cdb673745472
is a currently totally untested and blind attempt
that intends to include firmware for built-in drivers
into the ReaR recovery system.

I cannot test it because currently I don't have an
environment where the kernel has built-in drivers
which need firmware so currently I have no idea
whether or not my code could work at all.

@rear/contributors
if you have an environment where the kernel
has built-in drivers which need firmware
I would much appreciate it if you could help me
with testing whether or not my code in
https://github.com/rear/rear/pull/3553/commits/39074e8c09dd6a1e6936d0543f64cdb673745472
could work at all.

On my openSUSE Leap 16.0 system I have

# for module_path in $( cat /lib/modules/$( uname -r )/modules.builtin ) ; \
 do module=$( basename $module_path | cut -s -d '.' -f1 ) ; \
    echo $module ; modinfo -F firmware $module ; \
 done

rapl
amd-uncore
intel-uncore
intel-cstate
iosf_mbi
configs
zbud
zsmalloc
binfmt_script
exportfs
nls_base
utf8data
autofs4
pstore
encrypted-keys
crypto
crypto_algapi
aead
geniv
crypto_skcipher
bpf_crypto_skcipher
seqiv
crypto_hash
akcipher
sig
kpp
hkdf
dh_generic
rsa_generic
ecdsa_generic
crypto_acompress
cryptomgr
hmac
crypto_null
md5
sha1_generic
sha256_generic
sha512_generic
sha3_generic
ecb
cbc
ctr
aes_generic
crc32c_generic
crct10dif_common
crct10dif_generic
crc64_rocksoft_generic
lzo
lzo-rle
rng
drbg
jitterentropy_rng
zstd
ecc
ecdh_generic
public_key
x509_key_parser
x509_selftest
pkcs7_message
kdf_sp800108
bsg
mq-deadline
kyber-iosched
bfq
rational
libcryptoutils
libaes
libaescfb
libaesgcm
gf128mul
libsha1
libsha256
mpi
bitrev

so none of them needs firmware.

jsmeix commented at 2026-08-27 13:48:¶

Regarding
https://github.com/rear/rear/pull/3553#issuecomment-4129123318
item 1. (excerpt)

"Defaulting to copy all firmware files - determining firmware in use not possible"

I am against copying all firmware files as fallback
in the 420_copy_firmware_files.sh script because
this would make ReaR behave against what
is specified in its config variables.

By default the config variables are

MODULES=( 'all_modules' )
FIRMWARE_FILES=()

which results that all kernel modules and all firmware
gets included in the ReaR recovery system.

The new code in 420_copy_firmware_files.sh in this
pull request is meant for the non-default case
i.e. when not all firmware should be copied
in particular for the case

MODULES=( 'loaded_modules' )
FIRMWARE_FILES=()

When it is not possible to automatically include
firmware for built-in drivers my current code
shows a LogPrintError message to inform the user
but it does not automatically work against what
the user had specified.

Perhaps Error instead of LogPrintError could
be better here?

I also need to test the other precondition,
i.e. that modinfo can query even builtin modules.
Tomorrow (as time permits) I will try to implement
something as the modinfo_error code in
https://github.com/rear/rear/pull/3553#issuecomment-4129123318
item 1.

jsmeix commented at 2026-08-28 12:51:¶

Regarding
https://github.com/rear/rear/pull/3553#issuecomment-5425860422

I think firmware files for built-in kernel stuff
must get copied into the recovery system in any case
except explicit user request FIRMWARE_FILES=( 'no' )

and
https://github.com/rear/rear/pull/3553#issuecomment-5440083009

When it is not possible to automatically include
firmware for built-in drivers my current code
shows a LogPrintError message to inform the user
but it does not automatically work against what
the user had specified.

Perhaps Error instead of LogPrintError could
be better here?

I improved error handling via
https://github.com/rear/rear/pull/3553/changes/d722577dae45fdd1a91e0cec17631f8f821715d3

When we cannot determine firmware files for built-in kernel drivers
and when FIRMWARE_FILES are specified,
we inform the user to ensure firmware for built-in drivers
is specified in FIRMWARE_FILES.

When we cannot determine firmware files for built-in kernel drivers
and when FIRMWARE_FILES is empty,
we error out to be on the safe side to avoid missing firmware
for built-in drivers in the recovery system.

jsmeix commented at 2026-09-09 09:06:¶

Added checks that modinfo succeeds.

For firmware for built-in drivers we do now:

When FIRMWARE_FILES are specified
and there was a modinfo failure when determining
firmware files for built-in kernel drivers,
we inform the user to ensure firmware
for built-in drivers is specified in FIRMWARE_FILES
but we cannot know if the user had such firmware
already specified in FIRMWARE_FILES

When FIRMWARE_FILES is empty and
when there was a modinfo failure when determining
firmware files for built-in kernel drivers,
we error out to be on the safe side to avoid missing
firmware for built-in drivers in the recovery system

For firmware for kernel modules we do now:

When FIRMWARE_FILES is empty and
when there was a modinfo failure when determining
firmware files for kernel modules,
we error out to be on the safe side to avoid missing
firmware for kernel modules in the recovery system

What is not implemented is
when FIRMWARE_FILES is specified
that we verify that firmware for kernel modules
in the recovery system is specified in FIRMWARE_FILES
i.e. when the user specified FIRMWARE_FILES
we assume the user specified it properly as needed.

jsmeix commented at 2026-09-09 11:30:¶

I think I addressed the items in
https://github.com/rear/rear/pull/3553#issuecomment-4129123318
except the "Gemini suggested code" item
(I won't find time to overhaul things)
either by above comments where I explained my point of view
or by enhanced existing code and added new code parts.

Intentionally (because I won't find time to overhaul things)
I only enhanced current things following the existing style
which is known to work OK at least in practice.

In particular I kept the two cases
"firmware files that belong to built-in kernel drivers" and
"firmware files that belong to the copied kernel modules"
separated to avoid accidentally messing up the whole thing
(including messing up what is known to work OK in practice
because I tested the kernel modules case but I don't know
how to test the built-in kernel drivers - I don't have
built-in kernel drivers which need firmware)
and because I want different debug and error messages
for the two different cases.

In general I want all message texts unique
so that from a message text it is clear
what exact code place it comes from
because rather often users report issues only with
a single (error) message and if the message text is
used at several places in ReaR it becomes needlessly hard
for us to find out what exact code place matches.

Furthermore unique message texts can be made
more specific for each case like

modinfo failed to determine firmware for kernel module 'XXX'

and

modinfo failed to determine firmware for built-in kernel driver 'YYY'

versus a less specific text used for both cases

modinfo failed to determine firmware for 'ZZZ'

versus rather poor (not really helpful) text

modinfo failed

jsmeix commented at 2026-09-09 11:42:¶

@rear/contributors
I would like to merge it on Friday (11. Sept.) afternoon
unless there are objections.
Please have a look (as time permits).

[Export of Github issue for rear/rear.]

#3553 PR merged: Automatically include firmware files for the kernel modules in the recovery system¶