Unable to Install JDK 7u80 on Rocky Linux 9 Due to Missing /bin/* Dependencies

Rocky Linux Help & Support
1

Description:

I am trying to install Oracle JDK 7u80 (jdk-7u80-linux-x64.rpm) on Rocky Linux 9, but the installation fails with dependency issues. The error message suggests missing /bin/* utilities, such as /bin/basename, /bin/cp, /bin/ls, /bin/mkdir, etc.

However, these utilities exist under /usr/bin/, and Rocky Linux 9 uses a unified /usr structure.

System Information:

  • OS: Rocky Linux 9
  • Kernel Version: 5.14.0-503.19.1.el9_5.cloud.1.0.x86_64
  • JDK Package: jdk-7u80-linux-x64.rpm
  • Installation Command:
    yum install -d10 jdk-7u80-linux-x64.rpm
    Error Output:
[root@vadi-rocky-linux9-testing ~]# yum install -d10 jdk-7u80-linux-x64.rpm
timer: config: 2 ms
Loaded plugins: builddep, changelog, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, groups-manager, needs-restarting, playground, repoclosure, repodiff, repograph, repomanage, reposync, system-upgrade
YUM version: 4.14.0
Command: yum install -d10 jdk-7u80-linux-x64.rpm 
Installroot: /
Releasever: 9
cachedir: /var/cache/dnf
Base command: install
Extra commands: ['install', '-d10', 'jdk-7u80-linux-x64.rpm']
User-Agent: constructed: 'libdnf (Rocky Linux 9.5; generic; Linux.x86_64)'
repo: using cache for: cloud-kernel
cloud-kernel: using metadata from Wed 19 Feb 2025 06:48:36 PM UTC.
repo: using cache for: google-compute-engine
google-compute-engine: using metadata from Tue 29 Feb 1972 12:39:03 PM UTC.
repo: using cache for: google-cloud-sdk
google-cloud-sdk: using metadata from Wed 01 Jul 1992 04:30:46 AM UTC.
repo: using cache for: google-cloud-ops-agent
google-cloud-ops-agent: using metadata from Wed 19 Sep 1973 04:13:58 PM UTC.
repo: using cache for: baseos
baseos: using metadata from Thu 20 Mar 2025 03:41:01 AM UTC.
repo: using cache for: appstream
appstream: using metadata from Thu 27 Mar 2025 01:16:26 AM UTC.
repo: using cache for: extras
extras: using metadata from Fri 28 Mar 2025 04:10:56 PM UTC.
Last metadata expiration check: 0:05:09 ago on Mon 31 Mar 2025 11:17:24 AM UTC.
timer: sack setup: 263 ms
Excludes in repo baseos: kernel*
--> Starting dependency resolution
--> Finished dependency resolution
timer: depsolve: 56 ms

Traceback (most recent call last):
  File "/usr/lib/python3.9/site-packages/dnf/cli/main.py", line 130, in cli_run
    ret = resolving(cli, base)
  File "/usr/lib/python3.9/site-packages/dnf/cli/main.py", line 166, in resolving
    base.resolve(cli.demands.allow_erasing)
  File "/usr/lib/python3.9/site-packages/dnf/base.py", line 931, in resolve
    raise exc
dnf.exceptions.DepsolveError: 
 Problem: conflicting requests
  - nothing provides /bin/basename needed by jdk-2000:1.7.0_80-fcs.x86_64 from @commandline
  - nothing provides /bin/cp needed by jdk-2000:1.7.0_80-fcs.x86_64 from @commandline
  - nothing provides /bin/ls needed by jdk-2000:1.7.0_80-fcs.x86_64 from @commandline
  - nothing provides /bin/mkdir needed by jdk-2000:1.7.0_80-fcs.x86_64 from @commandline
  - nothing provides /bin/mv needed by jdk-2000:1.7.0_80-fcs.x86_64 from @commandline
  - nothing provides /bin/pwd needed by jdk-2000:1.7.0_80-fcs.x86_64 from @commandline
  - nothing provides /bin/sort needed by jdk-2000:1.7.0_80-fcs.x86_64 from @commandline
Error: 
 Problem: conflicting requests
  - nothing provides /bin/basename needed by jdk-2000:1.7.0_80-fcs.x86_64 from @commandline
  - nothing provides /bin/cp needed by jdk-2000:1.7.0_80-fcs.x86_64 from @commandline
  - nothing provides /bin/ls needed by jdk-2000:1.7.0_80-fcs.x86_64 from @commandline
  - nothing provides /bin/mkdir needed by jdk-2000:1.7.0_80-fcs.x86_64 from @commandline
  - nothing provides /bin/mv needed by jdk-2000:1.7.0_80-fcs.x86_64 from @commandline
  - nothing provides /bin/pwd needed by jdk-2000:1.7.0_80-fcs.x86_64 from @commandline
  - nothing provides /bin/sort needed by jdk-2000:1.7.0_80-fcs.x86_64 from @commandline
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
Cleaning up.
Plugins were unloaded.
[root@vadi-rocky-linux9-testing ~]#

Troubleshooting Steps Taken:
Commands like /bin/basename already exist, but JDK 7 installer still fails.
Example:

[root@vadi-rocky-linux9-testing ~]# ll /usr/bin/basename /bin/basename
-rwxr-xr-x. 1 root root 36544 Nov  6 16:29 /bin/basename
-rwxr-xr-x. 1 root root 36544 Nov  6 16:29 /usr/bin/basename
[root@vadi-rocky-linux9-testing ~]#

Questions for the Community:

  1. Does Rocky Linux 9 fully support JDK 7u80, or is there a compatibility issue?
  2. Is there a recommended workaround to install JDK 7 on Rocky Linux 9?
  3. Could this be related to Rocky Linux’s /usr unification changes?
    Any guidance would be appreciated! Thanks in advance. :folded_hands:
2

If you look at ls -l / you should see that /bin is a symlink to /usr/bin and thus the /bin “has no files”.

The dnf provides *bin/basename tells that that file comes with package coreutils
and rpm -ql coreutils reveals that the whole path is /usr/bin/basename

Oracle(?) has built the package to require file /bin/basename rather than /usr/bin/basename
That probably fails to install into Oracle Linux 9 as well.

In other words, the package has not been built for Rocky 9. That is not fault of Rocky.

3

Also, Java 7 is EOL since 2022 so no longer supported. Update your application to use a supported version of Java. So there is no wonder Rocky 9 or RHEL9 don’t support it.

4

Subject: Clarification on /bin/basename Symlink Behavior

Thank you for the clarification regarding /bin/basename and its absence in Rocky 9 due to /bin being a symlink to /usr/bin. I understand that the JDK package was built expecting /bin/basename explicitly, which does not exist in Rocky 9.

However, I would like to clarify why the RPM dependency resolver does not follow the symlink (/bin → /usr/bin). Since /bin/basename should effectively resolve to /usr/bin/basename, shouldn’t it be recognized automatically by RPM? Is there a specific limitation within RPM’s dependency resolution that prevents it from following directory symlinks in cases like this?

I appreciate your time and insights. Thanks again for your support.

5

I just wanted know why it is failing? :). Thanks

1 Like
6

It could well be that the JDK version requires a certain version - no doubt the one in Rocky 9 is newer than older versions be it EL8 or EL7, and if the versions don’t match what the rpm requires, then it won’t allow it to install. Also, since the rpm requires dependencies, the dependency could be asking for /bin/basename or others to be satisfied by an rpm that provides it, rather than a symlink which is something else entirely. A very simple test for that is to do:

dnf provides /bin/basename

on Rocky 9 it will always come back with results that give /usr/bin/basename, if you repeat that on Rocky 8, it will actually come back with results that have /bin/basename. The symlink on disk is not enough.

1 Like
7

Sorry, I need to mention that I missed updating this earlier.
Just to close the loop:
I was able to successfully rebuild the RPM using the following command:

rpmrebuild --package --notest-install -e jdk-7u80-linux-x64.rpm

I removed the following Requires lines from the spec:


Requires:      /bin/basename  
Requires:      /bin/cp  
Requires:      /bin/ls  
Requires:      /bin/mkdir  
Requires:      /bin/mv  
Requires:      /bin/pwd  
Requires:      /bin/sort

The newly created RPM installed successfully and is working as expected. Thanks!! everyone :slight_smile:

1 Like