Bug 1831311

Summary: "rear" relax-and-recover fails
Product: [Fedora] Fedora Reporter: johnbholland
Component: rearAssignee: Christopher Engelhard <ce>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 32CC: aperotti, bmason, frank, gratien.dhaese, pcahyna, pneedle, vdolezal
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: rear-2.6-3.fc33 rear-2.6-3.fc32 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-09-29 00:15:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description johnbholland 2020-05-04 21:15:31 UTC
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:

Comment 1 Pavel Cahyna 2020-06-11 11:45:29 UTC
What is the error message? Do you have logs? What modules specifically does it complain about? Is there an issue upstream for this?

Comment 2 Pavel Cahyna 2020-06-11 15:43:30 UTC
is it https://github.com/rear/rear/issues/2414 ?

Comment 3 Frank Crawford 2020-06-14 08:08:15 UTC
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.

Comment 4 johnbholland 2020-06-16 10:10:29 UTC
I no longer wish to work on this bug.

Comment 5 Andrea Perotti 2020-09-21 20:49:27 UTC
In order to workaround that would be enough to follow this comment:

https://github.com/rear/rear/issues/2414#issuecomment-668632798

Comment 6 Fedora Admin user for bugzilla script actions 2020-09-22 14:53:43 UTC
This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.

Comment 7 Fedora Update System 2020-09-24 18:00:36 UTC
FEDORA-2020-c8bcabe321 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-c8bcabe321

Comment 8 Fedora Update System 2020-09-24 18:02:35 UTC
FEDORA-2020-9c98e80328 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-9c98e80328

Comment 9 Fedora Update System 2020-09-25 18:11:33 UTC
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.

Comment 10 Fedora Update System 2020-09-25 18:35:13 UTC
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.

Comment 11 Fedora Update System 2020-09-29 00:15:52 UTC
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.

Comment 12 Fedora Update System 2020-10-03 02:01:28 UTC
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.