RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1392589 - Failed to create a CFME image with RHEL 7.3 using kickstart
Summary: Failed to create a CFME image with RHEL 7.3 using kickstart
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks: 1412305
TreeView+ depends on / blocked
 
Reported: 2016-11-07 20:37 UTC by Satoe Imaishi
Modified: 2021-01-15 07:28 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1412305 (view as bug list)
Environment:
Last Closed: 2021-01-15 07:28:27 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
anaconda_1.log (8.77 KB, text/plain)
2016-11-08 00:05 UTC, Satoe Imaishi
no flags Details
packaging_1.log (238.25 KB, text/plain)
2016-11-08 00:06 UTC, Satoe Imaishi
no flags Details
program_1.log (50.83 KB, text/plain)
2016-11-08 00:06 UTC, Satoe Imaishi
no flags Details
storage_1.log (125.14 KB, text/plain)
2016-11-08 00:07 UTC, Satoe Imaishi
no flags Details
syslog_1 (514.92 KB, text/plain)
2016-11-08 00:07 UTC, Satoe Imaishi
no flags Details
ifcfg_1.log (1.11 KB, text/plain)
2016-11-08 00:07 UTC, Satoe Imaishi
no flags Details
ks_1.cfg (11.47 KB, text/plain)
2016-11-08 00:10 UTC, Satoe Imaishi
no flags Details

Comment 2 David Cantrell 2016-11-07 21:05:20 UTC
The installer team is investigating this bug, and will post questions here if we need more information.

Comment 3 Brian Lane 2016-11-07 22:38:47 UTC
We need the full set of logs from Oz (looks like this is an image creation task using Oz running the installer).

At this point in the install the grub2-install process is run in the context of the installed system, so the missing library could mean one of these things happened:

1. It didn't get installed for some reason. Check the packages.log for elfutils-libs which is the owner of the file.

2. It got installed but removed by something else. This shouldn't happen, and I have no good way to find out if it did happen.

3. The installation didn't actually finish. If there was an error installing a package, or it ran out of space. It should report an error if this happens, which may be in any one of the log files, but normally in anaconda.log or packaging.log

So please attach all the logs from /tmp/*log as individual text/plain attachments.

Comment 4 Satoe Imaishi 2016-11-08 00:05:56 UTC
Created attachment 1218302 [details]
anaconda_1.log

Comment 5 Satoe Imaishi 2016-11-08 00:06:28 UTC
Created attachment 1218303 [details]
packaging_1.log

Comment 6 Satoe Imaishi 2016-11-08 00:06:48 UTC
Created attachment 1218304 [details]
program_1.log

Comment 7 Satoe Imaishi 2016-11-08 00:07:03 UTC
Created attachment 1218305 [details]
storage_1.log

Comment 8 Satoe Imaishi 2016-11-08 00:07:21 UTC
Created attachment 1218306 [details]
syslog_1

Comment 9 Satoe Imaishi 2016-11-08 00:07:36 UTC
Created attachment 1218307 [details]
ifcfg_1.log

Comment 10 Satoe Imaishi 2016-11-08 00:10:33 UTC
Created attachment 1218308 [details]
ks_1.cfg

Comment 11 Satoe Imaishi 2016-11-08 00:11:43 UTC
Attached all *.log from /tmp directory (as *_1.log) as well as kickstart file used (ks_1.cfg) - they're all from my local kickstart installation which shows the exact same problem.

Comment 12 Brian Lane 2016-11-08 00:37:54 UTC
That's good you can reproduce it locally. It looks like elfutils-libs and devtoolset-3-elfutils-libs are both getting installed. I don't think that should be an issue since they're different paths.

Can you take a look at your local system when it fails and see if /mnt/sysimage/usr/lib64/libdw.* exists at all?


chroot /mnt/sysimage and see if:

run 'grub2-install --help' and see if it returns the same error?

run 'rpm -ql elfutils-libs' and see if it lists /usr/lib64/libdw.*

The last thing to try is to drop the repo with the devtoolset-* packages in it and see if the installation works without installing them. devtoolset-3-elfutils-libelf is the only use of devtoolset in the package list so I suspect it is somehow clobbering the system package's files.

Comment 13 Satoe Imaishi 2016-11-08 00:51:06 UTC
(In reply to Brian Lane from comment #12)
> That's good you can reproduce it locally. It looks like elfutils-libs and
> devtoolset-3-elfutils-libs are both getting installed. I don't think that
> should be an issue since they're different paths.
> 
> Can you take a look at your local system when it fails and see if
> /mnt/sysimage/usr/lib64/libdw.* exists at all?

No, /mnt/sysimage/usr/lib64/libdw.* do not exist at all

> 
> chroot /mnt/sysimage and see if:
> 
> run 'grub2-install --help' and see if it returns the same error?

Yes, this returned the same error about libdw.so.1


> run 'rpm -ql elfutils-libs' and see if it lists /usr/lib64/libdw.*

It looks like elfutils-libs is not installed. Running rpm -ql returns:

package elfutils-libs is not installed

Running 'rpm -qa |grep elfutils-libs' returns just devtoolset-3-elfutils-libs


> The last thing to try is to drop the repo with the devtoolset-* packages in
> it and see if the installation works without installing them.
> devtoolset-3-elfutils-libelf is the only use of devtoolset in the package
> list so I suspect it is somehow clobbering the system package's files.

I'll give it a try!

Comment 14 Satoe Imaishi 2016-11-08 02:33:25 UTC
Confirmed the installation goes through fine when I disable the SCL repo where devtoolset-3-elfutils-libs is coming from.  When I disable the repo, 'elfutils-libs' gets installed on the machine instead.

So it does look like devtoolset-3-elfutils-libs is winning over elfutils-libs to meet libdw.so.1 requirement when both are available.

CFME appliance that was built with RHEL 7.2 has elfutils-libs installed (even with SCL repo, as CFME requires SCL).  So it seems something changed in RHEL 7.3..

Comment 16 Satoe Imaishi 2016-11-08 12:55:13 UTC
The workaround seems to be to add elfutils-libs in kickstart %packages section.

Comment 17 Brian Lane 2016-11-08 17:03:22 UTC
Another workaround may be to add --excludepkgs=devtoolset-3-elfutils-libs to the kickstart repo line for the scl repo. That should prevent it from using the wrong one.

Comment 18 Peter Jones 2016-11-08 18:37:32 UTC
So it looks like devtoolset-3-elfutils-libs is has an RPM "provides:" for libdw.so.1()(64bit), but it's not providing /usr/lib64/libdw.so.1 .  Because of that, the rpm dependency during installation is satisfied, but the binaries can't actually load.

The SCL needs to either a) provide the files in the right directory, b) provide an ld.so.conf.d config file that adds its stuff to the search path, or c) namespace those rpm requirements and make it so binaries that link against those target packages know about the SCL's library search dir.

Comment 28 RHEL Program Management 2021-01-15 07:28:27 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.


Note You need to log in before you can comment on or make changes to this bug.