New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot install oracle-java8-installer with jdk1.8.0_111 #1321

Closed
mattpodwysocki opened this Issue Nov 4, 2016 · 17 comments

Comments

Projects
None yet
@mattpodwysocki

mattpodwysocki commented Nov 4, 2016

Installing the Oracle Java 8 JDK update 111 no longer works on WSL since the change from update 101 to 111. It seems that dmesg is necessary, but not supported on WSL.

This is the truncated result once the JDK was downloaded from Oracle:

Download done.
Removing outdated cached downloads...
mv: cannot move 'jdk1.8.0_111' to 'java-8-oracle': Permission denied
dpkg: error processing package oracle-java8-installer (--configure):
 subprocess installed post-installation script returned error exit status 1
Setting up gsfonts (1:8.11+urwcyr1.0.7~pre44-4.2ubuntu1) ...
dmesg: read kernel buffer failed: Function not implemented
                                                          /bin/df: /proc/sys/fs/binfmt_misc: Operation not permitted
                                                                                                                    Setting up x11-common (1:7.7+13ubuntu3) ...
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
invoke-rc.d: could not determine current runlevel
invoke-rc.d: policy-rc.d denied execution of start.
Setting up xfonts-encodings (1:1.0.4-2) ...
Setting up xfonts-utils (1:7.7+3) ...
Setting up gsfonts-x11 (0.24) ...
dpkg: dependency problems prevent configuration of oracle-java8-set-default:
 oracle-java8-set-default depends on oracle-java8-installer; however:
  Package oracle-java8-installer is not configured yet.

dpkg: error processing package oracle-java8-set-default (--configure):
 dependency problems - leaving unconfigured
Processing triggers for libc-bin (2.23-0ubuntu3) ...
No apport report written because the error message indicates its a followup error from a previous failure.
                                                                                                          Processing triggers for systemd (229-4ubuntu8) ...
Processing triggers for ureadahead (0.100.0-19) ...
Errors were encountered while processing:
 oracle-java8-installer
 oracle-java8-set-default
E: Sub-process /usr/bin/dpkg returned an error code (1)

Windows Build: Windows 10 Build 14959

Reproduction steps:

$ sudo add-apt-repository ppa:webupd8team/java
$ sudo apt-get update
$ sudo apt-get install -y oracle-java8-installer
@therealkenc

This comment has been minimized.

Collaborator

therealkenc commented Nov 4, 2016

Setting aside a permissions problem on /dev/kmsg, relevant strace looks like:

open("/dev/kmsg", O_RDONLY|O_NONBLOCK)  = 3
lseek(3, 0, SEEK_DATA)                  = -1 EINVAL (Invalid argument)
read(3, 0x60c3e0, 8191)                 = -1 EAGAIN (Resource temporarily unavailable)
close(3)                                = 0

This is one of those (many) cases where stubbing functionality in WSL would go a long way. Even if all WSL's /dev/kmesg contained was the following string it would be a start, and we could see what Oracle was grepping for.

5,0,0,-;Linux version 3.4.0-Microsoft (Microsoft@Microsoft.com) (gcc version 4.7 (GCC) ) #1 SMP PREEMPT Wed Dec 31 14:42:53 PST 2014
@benhillis

This comment has been minimized.

Member

benhillis commented Nov 4, 2016

On an internal build I was able to follow the reproduction steps without any install failures... Interesting.

@therealkenc - I like your idea of adding something to /dev/kmsg's buffer so it's not empty. I'll take a look at that since it's probably a strange case for it to be completely empty as it usually is on WSL.

@therealkenc

This comment has been minimized.

Collaborator

therealkenc commented Nov 5, 2016

I didn't do an Oracle install, but sudo dmesg definitely fails with the dmesg: read kernel buffer failed: Function not implemented for me.

@benhillis

This comment has been minimized.

Member

benhillis commented Nov 5, 2016

@therealkenc - Awesome thanks for the clarification. I really like your idea of prepopulating the /dev/kmsg buffer with something (since usually init and other deamons would have written a bunch of stuff to it).

@therealkenc

This comment has been minimized.

Collaborator

therealkenc commented Nov 5, 2016

Awesome. Please note the perms while you're there. Should be 644.

@hdave

This comment has been minimized.

hdave commented Nov 23, 2016

Your repro steps worked for me on Win10 build 14965 prerelease 161104-1700.

On another related point -- Maybe I'm coming into this wrong, but I also have installed Oracle Java 8 from within Windows. As an experiment I tried from within WSL to set my JAVA_HOME to that directory added JAVA_HOME/bin to my path and aliased java='java.exe' -- and so far it seems to work. Is there some reason we can't redirect WSL to the Windows installation of Java? Could this be a work-around for some people? I realize that update-alternatives thinks no java is installed....

@stehufntdev

This comment has been minimized.

Collaborator

stehufntdev commented Apr 13, 2017

As a workaround to the dmesg failure, please first write something to /dev/kmsg (e.g. echo foo > /dev/kmsg). As mentioned above, dmesg always expects there to be some data in /dev/kmsg which isn't always the case on WSL.

Marking this as a bug so we can track fixing the behavior difference.

@spoiledsport

This comment has been minimized.

spoiledsport commented Apr 13, 2017

Actually there is no workaround. First of all, after making the change, dmesg doesn't print what is expected of it. Second, this only works for the current window. After you exit bash and start it again, you are back to the same issue.

This worked in previous version of WSL. It actually showed the correct output.

@stehufntdev

This comment has been minimized.

Collaborator

stehufntdev commented Apr 14, 2017

For the workaround you should be able to always write sometime to /dev/kmsg (e.g. put the line above in bash.rc). Init and other components log through /dev/kmsg so something probably changed in the configuration. Realistically dmesg shouldn't fail this case but it probably never happens in practice on native Linux.

This is marked as a bug so we will look at fixing it for insider builds.

@daiconrad

This comment has been minimized.

daiconrad commented Apr 15, 2017

@hdave What do you mean when you say "so far it seems to work"? If I'm in a BoW directory, I get:

$ /mnt/c/Program\ Files/Java/jdk1.8.0_121/bin/java.exe Foo
Unable to translate current working directory. Using C:\WINDOWS\system32
Error: Could not find or load main class Foo

OTOH, it does work in a directory under /mnt/c

@Silver-Fang

This comment has been minimized.

Silver-Fang commented Dec 12, 2017

@stehufntdev sudo echo foo > /dev/kmsg returns -bash: /dev/kmsg: Permission denied

@Brian-Perkins

This comment has been minimized.

Collaborator

Brian-Perkins commented Dec 12, 2017

You can do something like: echo foo > sudo tee /dev/kmsg

@therealkenc

This comment has been minimized.

Collaborator

therealkenc commented Jan 12, 2018

@benhillis in Nov 2016

I really like your idea of prepopulating the /dev/kmsg buffer with something (since usually init and other deamons would have written a bunch of stuff to it).

Pinging because doing so inexplicably seems to work.

@almdrx

This comment has been minimized.

almdrx commented Feb 13, 2018

Here from #1886

Just my 2 cents...

  • won't run dmesg, returns dmesg: read kernel buffer failed: Function not implemented
  • echo foo > /dev/kmsg returns bash: /dev/kmsg: Permission denied

However if passed as a quoted command ...

user@host:/mnt/c $ sudo bash -c "dmesg -w"
[    0.000000] 
user@host:/mnt/c $ sudo bash -c "echo foo > /dev/msg"
user@host:/mnt/c $
@therealkenc

This comment has been minimized.

Collaborator

therealkenc commented Feb 20, 2018

Unfortunately, this doesn't seem to take. You can get over the hard lseek() fail by putting anything in the buffer, but it appears that the WSL device prepends cruft to the output, as opposed to a well formed kmsg:

$ sudo bash -c "echo 'Hello from WSL. Linux version 4.4.0-17101-Microsoft (Microsoft@Microsoft.com) (gcc version 5.4. (GCC) ) #1000-Microsoft Sun Feb 11 10:40:00 PST 2018' >> /dev/kmsg"
$ cat /dev/kmsg
▒''▒▒▒Z4▒;Hello from WSL. Linux version 4.4.0-17101-Microsoft (Microsoft@Microsoft.com) (gcc version 5.4. (GCC) ) #1000-Microsoft Sun Feb 11 10:40:00 PST 2018

This is why dmesg always looks something like this in WSL, even after daemons have written to it:

$ dmesg
[    0.000000]

Same echo test works on Real Linux™, natch.

Given that rsyslogd is also inoperable per #534 (edit,correction: rsyslogd limps, only soft fails remaining), this pretty much blocks the ability for daemons (which give up the terminal) to provide any kind of feedback to the user.

@therealkenc

This comment has been minimized.

Collaborator

therealkenc commented Jul 13, 2018

Support for /dev/kmsg was added in 17655.

@kenorb

This comment has been minimized.

kenorb commented Oct 4, 2018

After upgrading WSL, it seems to work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment