Description of problem: Pulled a yum update and java no longer worked. Upon investigation found that the softlinks in /etc/alternatives were not updated. Causing java to be inoperable. Version-Release number of selected component (if applicable): java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20 How reproducible: Unknown - yum reinstall fails on my machine. Steps to Reproduce: 1. yum update 2. java -version Actual results: bash: java: command not found... Expected results: java version "1.7.0_51" OpenJDK Runtime Environment (fedora-2.4.4.1.fc20-x86_64 u51-b02) OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode) Additional info: $ ls -la java lrwxrwxrwx. 1 root root 73 Jan 17 08:24 java -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64/jre/bin/java ^ Pointing to the old version ? (no fail on reinstall) $ ls -la javac lrwxrwxrwx. 1 root root 70 Jan 21 10:14 javac -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64/bin/javac
related: https://bugzilla.redhat.com/show_bug.cgi?id=1054350
Notes: yum downgrade is almost impossible, it was easier for me to simply update the broken soft-links. FWIW not all soft-links we broken, and I updated the following: sudo ln -sf /usr/share/man/man1/java-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64.1.gz sudo ln -sf /usr/share/man/man1/java-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64.1.gz java.1.gz sudo ln -sf /usr/share/javadoc/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20/api javadocdir sudo ln -sf /usr/lib/jvm-exports/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64 java_sdk_1.7.0_openjdk_exports sudo ln -sf /usr/lib/jvm-exports/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64 jre_1.7.0_exports sudo ln -sf /usr/lib/jvm/jre-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64 jre_1.7.0_openjdk sudo ln -sf /usr/lib/jvm-exports/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64 jre_1.7.0_openjdk_exports sudo ln -sf /usr/lib/jvm-exports/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64 jre_exports sudo ln -sf /usr/lib/jvm-exports/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64 jre_openjdk_exports sudo ln -sf /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64/jre/bin/keytool . sudo ln -sf /usr/share/man/man1/keytool-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64.1.gz keytool.1.gz sudo ln -sf /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64/jre/bin/orbd sudo ln -sf /usr/share/man/man1/orbd-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64.1.gz orbd.1.gz sudo ln -sf /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64/jre/bin/pack200 . sudo ln -sf /usr/share/man/man1/pack200-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64.1.gz pack200.1.gz sudo ln -sf /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64/jre/bin/rmid . sudo ln -sf /usr/share/man/man1/rmid-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64.1.gz rmid.1.gz sudo ln -sf /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64/jre/bin/rmiregistry . sudo ln -sf /usr/share/man/man1/rmiregistry-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64.1.gz rmiregistry.1.gz sudo ln -sf /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64/jre/bin/servertool sudo ln -sf /usr/share/man/man1/servertool-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64.1.gz servertool.1.gz sudo ln -sf /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64/jre/bin/tnameserv . sudo ln -sf /usr/share/man/man1/tnameserv-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64.1.gz tnameserv.1.gz sudo ln -sf /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64/jre/bin/unpack200 . sudo ln -sf /usr/share/man/man1/unpack200-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64.1.gz unpack200.1.gz sudo ln -sf /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc20.x86_64/jre/bin/rmiregistry .
I have the same issue. Should I apply all this links? I would prefer to you "alternatives" but how to say
Somebody at fedoraforum.org has run into it too due to the recent selinux-policy bug, which has broken the package scriptlets. But even without being affected by that bug, there's something odd in the java-1.7.0-openjdk packaging: # rpm -qf /usr/lib/jvm/java-1.7.0-openjdk* file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64 is not owned by any package java-1.7.0-openjdk-headless-1.7.0.60-2.4.4.1.fc20.x86_64 # find /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64 /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64 /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64/jre /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64/jre/lib /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64/jre/lib/amd64 /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64/jre/lib/amd64/xawt Are those normal "unowned directories" ( https://fedoraproject.org/wiki/Packaging:UnownedDirectories ) or the result of some bug in a scriptlet?
why did java stop working?
It looks very much like the same bug, but I'm having a similar issue with the update I've done this morning (to openjdk 1.7.0.60-2.4.4.1, from 1.7.0.60-2.4.4.0). Similarly to what is suggested in comment #2, I found that doing the following fixed the issue for me: cd /etc/alternatives oldversion="java-1.7.0-openjdk-1.7.0.60-2.4.4.0" newversion="java-1.7.0-openjdk-1.7.0.60-2.4.4.1" ls -l | sed -n "s/.*[0-9][0-9]:[0-9][0-9] \(.*\) -> \(.*$oldversion.*\)/sudo rm \1 \&\& sudo ln -s \2 \1/p" | sed "s/$oldversion/$newversion/p" | /bin/bash -e eclipse and azureus are now working fine again. Hope it helps someone else.
The unowned directory are not the result of a bug in the scriptlet, I was not affected by the selinux issue and I see that as well
yum reinstall java-1.7.0-openjdk-headless follow by alternatives --config java (and choosing the new one as default) and alternatives --remove java /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64/jre/bin/java is solving the issue
I'm almost certain it's a result of SELinux policy update. (https://bugzilla.redhat.com/show_bug.cgi?id=1054350) However, post policy update, a reinstall should work, and it does not.
> yum reinstall java-1.7.0-openjdk-headless follow by > alternatives --config java (and choosing the new one as default) > alternatives --remove java > /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64/jre/bin/java > is solving the issue thanks a lot; I confirm this works nicely.
Created attachment 860929 [details] ls /etc/alternatives In fact I still have plenty of links pointing to java-1.7.0-openjdk-1.7.0.60-2.4.4.0 in /etc/alternatives (see attached file). Should I remove them or make them point to another location?
Hm. Odd. Those should be gone with 2.4.4.0 removal. May you please copy just master links here? (== output of alternatives --config java)/javac
$ LC_ALL=C alternatives --config java There are 3 programs which provide 'java'. Selection Command ----------------------------------------------- 1 /usr/java/jdk1.7.0_17/jre/bin/java 2 /usr/lib/jvm/jre-1.5.0-gcj/bin/java *+ 3 /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.5.1.fc20.x86_64/jre/bin/java $ LC_ALL=C alternatives --config javac There are 2 programs which provide 'javac'. Selection Command ----------------------------------------------- *+ 1 /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64/bin/javac 2 /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.5.1.fc20.x86_64/bin/javac I see, I have to also change javac.
So this what I did: $ alternatives --config javac then chose /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.5.1.fc20.x86_64/bin/javac then remove the old one: $ alternatives --remove javac /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64/bin/javac But I still have some 2.4.4 links: java_sdk_1.7.0 -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64 java_sdk_1.7.0_exports -> /usr/lib/jvm-exports/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64 java_sdk_1.7.0_openjdk -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64 java_sdk_1.7.0_openjdk_exports -> /usr/lib/jvm-exports/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64 java_sdk_openjdk -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64 java_sdk_openjdk_exports -> /usr/lib/jvm-exports/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64 jre_1.7.0 -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64/jre jre_1.7.0_exports -> /usr/lib/jvm-exports/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64 jre_1.7.0_openjdk_exports -> /usr/lib/jvm-exports/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64 jre_openjdk -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64/jre jre_openjdk_exports -> /usr/lib/jvm-exports/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc20.x86_64
*** Bug 1057706 has been marked as a duplicate of this bug. ***
Yes there are also this keys: alternatives --config jre_1.7.0 alternatives --config jre_openjdk alternatives --config jre_1.7.0_openjdk alternatives --config java_sdk_1.7.0_openjdk alternatives --config java_sdk_openjdk alternatives --config java_sdk_1.7.0 You may try to setup them manually to. I belive your issue was cause dbe selinux bug during update, which have left original alternatives records. And the new one were not set, because you had alternatives in manual mode. f20 rpms do not force to set alternatives if tey are in manual mode.
thanks, it worked and /etc/alternatives is now clean.
*** Bug 1072295 has been marked as a duplicate of this bug. ***