Bug 1392589

The installer team is investigating this bug, and will post questions here if we need more information.

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.

Created attachment 1218302 [details]
anaconda_1.log

Created attachment 1218303 [details]
packaging_1.log

Created attachment 1218304 [details]
program_1.log

Created attachment 1218305 [details]
storage_1.log

Created attachment 1218306 [details]
syslog_1

Created attachment 1218307 [details]
ifcfg_1.log

Created attachment 1218308 [details]
ks_1.cfg

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.

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.

(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!

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..

The workaround seems to be to add elfutils-libs in kickstart %packages section.

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.

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.

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.