Description of problem: running rear -v mkbackup fails, it detects what it thinks are modules in the kernel but they are actually built in to the kernel. Version-Release number of selected component (if applicable): How reproducible: see above Steps to Reproduce: 1. see above 2. 3. Actual results: script aborts with error Expected results: backup would be created Additional info:
What is the error message? Do you have logs? What modules specifically does it complain about? Is there an issue upstream for this?
is it https://github.com/rear/rear/issues/2414 ?
I'm also hit by this option, which is as documented in https://github.com/rear/rear/issues/2414 The error in the logs is: 2020-06-14 01:31:31.745870432 Including build/GNU/Linux/400_copy_modules.sh 2020-06-14 01:31:31.759751083 Copying kernel modules /usr/share/rear/build/GNU/Linux/400_copy_modules.sh: line 41: test: nls_cp437: binary operator expected /usr/share/rear/build/GNU/Linux/400_copy_modules.sh: line 45: test: nls_cp437: binary operator expected 2020-06-14 01:31:31.790288302 ERROR: nls_cp437 exists but no module file? ==== Stack trace ==== Trace 0: /usr/sbin/rear:543 main Trace 1: /usr/share/rear/lib/mkrescue-workflow.sh:18 WORKFLOW_mkrescue Trace 2: /usr/share/rear/lib/framework-functions.sh:101 SourceStage Trace 3: /usr/share/rear/lib/framework-functions.sh:49 Source Trace 4: /usr/share/rear/build/GNU/Linux/400_copy_modules.sh:126 source Message: nls_cp437 exists but no module file? == End stack trace == The issue in 400_copy_modules.sh is if ! test $module_filename ; then test "$KERNEL_VERSION" = "$( uname -r )" || Error "modinfo_filename failed because KERNEL_VERSION does not match 'uname -r'" module_filename=$( modinfo -F filename $module_name ) fi and looks to be an issue that modinfo format has changed. For built in "modules" now returns: [frank@agc rear]$ modinfo -k 5.6.16 -F filename nls_cp437 2> /dev/null name: nls_cp437 (builtin) Preiously it just returned an error. Also, this is fixed in later versions of rear by totally rewriting this module.
I no longer wish to work on this bug.
In order to workaround that would be enough to follow this comment: https://github.com/rear/rear/issues/2414#issuecomment-668632798
This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component.
FEDORA-2020-c8bcabe321 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-c8bcabe321
FEDORA-2020-9c98e80328 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-9c98e80328
FEDORA-2020-c8bcabe321 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-c8bcabe321` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-c8bcabe321 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-9c98e80328 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-9c98e80328` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-9c98e80328 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-c8bcabe321 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-9c98e80328 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.