search

microsoft / WSL

Issues found on WSL
https://docs.microsoft.com/windows/wsl
MIT License
17.41k stars 821 forks source link

invoke-rc.d: could not determine current runlevel #1761

Closed Abhinickz closed 6 years ago

Abhinickz commented 7 years ago 
Fetched 3017 kB in 31s (95.7 kB/s)
Preconfiguring packages ...
(Reading database ... 56704 files and directories currently installed.)
Preparing to unpack .../libmagickcore-6.q16-2_8%3a6.8.9.9-7ubuntu5.5_amd64.deb ...
Unpacking libmagickcore-6.q16-2:amd64 (8:6.8.9.9-7ubuntu5.5) over (8:6.8.9.9-7ubuntu5.4) ...
Preparing to unpack .../imagemagick-common_8%3a6.8.9.9-7ubuntu5.5_all.deb ...
Unpacking imagemagick-common (8:6.8.9.9-7ubuntu5.5) over (8:6.8.9.9-7ubuntu5.4) ...
Preparing to unpack .../libimage-magick-q16-perl_8%3a6.8.9.9-7ubuntu5.5_amd64.deb ...
Unpacking libimage-magick-q16-perl (8:6.8.9.9-7ubuntu5.5) over (8:6.8.9.9-7ubuntu5.4) ...
Preparing to unpack .../libimage-magick-perl_8%3a6.8.9.9-7ubuntu5.5_all.deb ...
Unpacking libimage-magick-perl (8:6.8.9.9-7ubuntu5.5) over (8:6.8.9.9-7ubuntu5.4) ...
Preparing to unpack .../linux-libc-dev_4.4.0-66.87_amd64.deb ...
Unpacking linux-libc-dev:amd64 (4.4.0-66.87) over (4.4.0-64.85) ...
Preparing to unpack .../mdadm_3.3-2ubuntu7.2_amd64.deb ...
invoke-rc.d: could not determine current runlevel
Unpacking mdadm (3.3-2ubuntu7.2) over (3.3-2ubuntu7.1) ...
Processing triggers for libc-bin (2.23-0ubuntu5) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for systemd (229-4ubuntu16) ...
Processing triggers for ureadahead (0.100.0-19) ...
Setting up imagemagick-common (8:6.8.9.9-7ubuntu5.5) ...
Setting up libmagickcore-6.q16-2:amd64 (8:6.8.9.9-7ubuntu5.5) ...
Setting up libimage-magick-q16-perl (8:6.8.9.9-7ubuntu5.5) ...
Setting up libimage-magick-perl (8:6.8.9.9-7ubuntu5.5) ...
Setting up linux-libc-dev:amd64 (4.4.0-66.87) ...
Setting up mdadm (3.3-2ubuntu7.2) ...
W: mdadm: failed to load MD subsystem.
update-initramfs: deferring update (trigger activated)
invoke-rc.d: could not determine current runlevel
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Processing triggers for libc-bin (2.23-0ubuntu5) ...
Processing triggers for initramfs-tools (0.122ubuntu8.8) ...
fpqc commented 7 years ago

The current init system is not at all sophisticated and doesn't use runlevels. Systemd also doesn't use runlevels, but iirc Ubuntu 16.04 does for compatibility reasons.

therealkenc commented 7 years ago

Try this:

sudo su
export RUNLEVEL=1
apt-get <whatever>

You are going to have no joy with mdadm though, for reasons that go beyond runlevels.

concatime commented 7 years ago

Had the same issue. No changes on this?

mix3d commented 6 years ago

Still having the problem. Exporting RUNLEVEL didn't make a difference.

josh-yoder-vive commented 6 years ago

This is still an issue. Can we get some sort of a resolution? This particular issue has been open for a year now.

benhillis commented 6 years ago

@josh-yoder-vive - It is my understanding that this isn't causing any issues beyond a warning when running apt commands. Is that not the case?

therealkenc commented 6 years ago

Just warnings, along the lines of this.

The RUNLEVEL environment hack (which gets picked up by /sbin/runlevel) doesn't work because current versions of apt clobber the environment and don't actually run as root. There's probably some way to force the RUNLEVEL variable down apt's throat but I didn't take the time to look. People who feel strongly about it can do:

sudo bash -c "echo '[1] [00049] [~~  ] [runlevel] [~           ] [4.4.0-17115-Micoroso] [0.0.0.0        ] [Wed Feb 28 13:27:14 2018 STD]' | utmpdump -r > /var/run/utmp"

That will kill the runlevel warning. You'll still get "start and stop actions are no longer supported". Because they aren't. Some people can't be pleased.

caseyallen386 commented 6 years ago

I had this issue when updating mysql-server. I resolved my issue like this ` sudo su apt-get remove --purge 'mysql*' apt-get autoremove apt-get autoclean rm -f /etc/mysql /var/lib/mysql apt-get install mysql-server

`

TheDan64 commented 6 years ago

I'm seeing this issue with ebtables:

$ sudo apt upgrade
Reading package lists... Done
  ebtables
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/79.4 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
(Reading database ... 77805 files and directories currently installed.)
Preparing to unpack .../ebtables_2.0.10.4-3.4ubuntu2_amd64.deb ...
invoke-rc.d: could not determine current runlevel
invoke-rc.d: could not determine current runlevel
Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1)
$ sudo apt remove --purge ebtables
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following package was automatically installed and is no longer required:
  xdelta3
invoke-rc.d: could not determine current runlevel
Removing lxd dnsmasq configuration
Purging configuration files for lxd (2.21-0ubuntu3~16.04.1) ...
Removing ebtables (2.0.10.4-3.4ubuntu1) ...
invoke-rc.d: could not determine current runlevel
 * Error: insufficient privileges to access the ebtables rulesets.
invoke-rc.d: initscript ebtables, action "stop" failed.
dpkg: error processing package ebtables (--purge):
 subprocess installed pre-removal script returned error exit status 1
Processing triggers for man-db (2.7.5-1) ...
Errors were encountered while processing:
 ebtables
E: Sub-process /usr/bin/dpkg returned an error code (1)

autoremove/autoclean/install -f seems to make no difference.

georgique commented 6 years ago

I tried to purge MySQL directories and reinstall it, however when I do the re-install, I get the following: mysqld: Can't read dir of '/etc/mysql/conf.d/' (Errcode: 2 - No such file or directory) mysqld: [ERROR] Fatal error in defaults handling. Program aborted! mysqld: Can't read dir of '/etc/mysql/conf.d/' (Errcode: 2 - No such file or directory) mysqld: [ERROR] Fatal error in defaults handling. Program aborted!

13steinj commented 6 years ago

Clean enabling of the WSL and install of Ubuntu (16.04 as from the Microsoft Store's "Run Linux on Windows" page), Windows Version 1803, Build 17134.48.

Got this issue for uuid-runtime, lxd, lxcfs, mdadm, apport seems to have a related issue because it didn't have permission to create a required file the first time invoke-rc.d failed.

Other packages (any using invoke-rc.d, really) may have failed in this manner. Unsure if error or mere warning.

From my understanding this is due to an underlying issue in the runlevel system, as only Unix systems have runlevels. Can it get some love? It's been a year since the original issue has been filed and the runlevel is important for automatic jobs (on levels 1-5) and cleanup tasks (on levels 0 and 6). I understand that runlevel 5 may be difficult to implement due to it being 3 + a display manager, but the WSL already doesn't support GUI apps so I think not supporting runlevel 5 would be fine.

fpqc commented 6 years ago

Runlevels are deprecated, so no, they won't be implemented or even stubbed out.

We're more likely to see a transition from WSL-init to systemd.

13steinj commented 6 years ago

@fpqc What? Where'd you get that from/can you elaborate? systemd can still act on runlevels, exposed via "targets". Unless I am fundamentally mistaken.

Not to mention invoke-rc.d, of Ubuntu 16.04 (which is supported until April 2021), apparently requires them. As well as potentially other cli packages.

Even if they are deprecated completely as of 18.04 (I am unaware, haven't seen such and haven't tried 18.04 out), are we supposed to just wait until 2021 when 16.04 is EOL for third parties and us to play catchup?

fpqc commented 6 years ago

No, the current package on the Windows Store offered by Canonical is iirc 18.04. Also, systemd-runlevel support is through the sysvcompat module of systemd. It works OOB as long as systemd is running.

Classic runlevels are managed by the init system, so the easy answer is to support systemd.

13steinj commented 6 years ago

When searching "Ubuntu" on the appstore I get the recommended "Run linux on windows". Those 5 recommended packages are Ubuntu (16.04.04 LTS as reported from lsb_release -a, openSUSE Leap 42, SUSE Linux Enterprise Server 12, Debian GNU / Linux, and Kali Linux. I am unaware of the versions of the other packages as I do not have them installed nor are they listed from that page.

Regardless, 16.04 is meant to have support until 2021. My Ubuntu 16.04 VM through VMWare uses systemd, and has access to runlevels.

Furthermore systemd still manages and has access to runlevels out of the box. They are renamed to their intentions (ex graphical.target for 5) and aliased via runlevel#.target.

The concept of a runlevel is not limited to any one init system. Rather they are Linux/Unix concept which every linux system uses. 0, 1, and 6 are the standard runlevels. 2-5 vary per linux distribution, but generally contain a single user mode, a multi user mode, and multi user mode + concept(s) (ex networking, a display manager). The user's init system uses runlevels to determine what jobs to start, among other tasks.

Again, runlevels are a fundamental concept to linux, and I have seen no deprecation as you claim. Again, I haven't checker on an 18.04 VM nor any other OS, but as 16.04 is meant to be supported until 2021, so should runlevels, on 16.04 at minimum (again, haven't checked 18.04/other systems for the depreciation of runlevels, but I've seen no such report).

therealkenc commented 6 years ago

Rather they are Linux/Unix concept which every linux system uses

That's plain incorrect, for what it is worth. The Linux kernel does not know or care about runlevels. The LG Smart TV I picked up at Costco last week, which runs Linux, doesn't have a /var/run/utmp. Because why would it.

Ubuntu's systemd does update /var/run/utmp on startup for the benefit of some packages. WSL's /init does not. Doing so would be trivial to add as a feature (for those that are of the opinion a #2530 death march is a good idea). Or, as @fpqc already implied, your ask is dupe #994. Or you can just update /var/run/utmp yourself. Bonne chance.

13steinj commented 6 years ago

Fine, redacted-- most, standard linux systems use. Ya know, not TVs and the like. Sue me^(pls don't).

Then I am in support for both issues you linked.

And yeah, I can definitely update the runlevel myself but I'd like something so fundamental to "most standard" linux distros (and by your words, trivial to add, haven't taken a look at the source) to be done for me.

marchom commented 6 years ago

The way I fixed this:

/etc/init.d/ebtables has

case "$1" in
    start)
        [ "$EBTABLES_LOAD_ON_START" = "yes" ] && load
        ;;
    stop)
        [ "$EBTABLES_SAVE_ON_STOP" = "yes" ] && save
        clear
        ;;

Just comment out the actions taken by stop) e.g.:

stop)
    # [ "$EBTABLES_SAVE_ON_STOP" = "yes" ] && save
    # clear
    ;;

and do your

sudo apt upgrade or purge or whatever. Note that after the upgrade the init script will be redeployed so you will face the same issue down the line.

The problem comes from the install/remove scripts trying to do service ebtables stop and failing. You can see this by trying to stop ebtables manually. Or by even just trying to find out the status of the service: sudo service ebtables status

noelbundick commented 6 years ago

edit: @marchom posted a workaround as I was typing this in :)

Hit this one just now when updating packages on Ubuntu 18.04 via Ansible

Relevant playbook task:

- name: Upgrade all packages                                                                                                                     
  apt:
    upgrade: yes
    autoclean: yes
    autoremove: yes

Which calls the following shell command:

sudo /usr/bin/apt-get upgrade --with-new-pkgs --auto-remove

Which fails with:

Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  ebtables
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
5 not fully installed or removed.
Need to get 0 B/79.9 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
(Reading database ... 84358 files and directories currently installed.)
Preparing to unpack .../ebtables_2.0.10.4-3.5ubuntu2.18.04.1_amd64.deb ...
invoke-rc.d: could not determine current runlevel
 * Error: insufficient privileges to access the ebtables rulesets.
invoke-rc.d: initscript ebtables, action "stop" failed.
dpkg: warning: old ebtables package pre-removal script subprocess returned error exit status 1
dpkg: trying script from the new package instead ...
invoke-rc.d: could not determine current runlevel
 * Error: insufficient privileges to access the ebtables rulesets.
invoke-rc.d: initscript ebtables, action "stop" failed.
dpkg: error processing archive /var/cache/apt/archives/ebtables_2.0.10.4-3.5ubuntu2.18.04.1_amd64.deb (--unpack):
 new ebtables package pre-removal script subprocess returned error exit status 1
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
invoke-rc.d: could not determine current runlevel
Errors were encountered while processing:
 /var/cache/apt/archives/ebtables_2.0.10.4-3.5ubuntu2.18.04.1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Looks like ebtables was updated 2 hours ago (https://launchpad.net/ubuntu/+source/ebtables/2.0.10.4-3.5ubuntu2.18.04.1), and this is causing failures in WSL

CeruleanSky commented 6 years ago

About the same time as noelbundick and marchom found a solution, I used an alternative fix from https://github.com/Microsoft/WSL/issues/143#issuecomment-209075558 which I found linked to from a japanese bbs.

echo "Implementing udev workaround (https://github.com/Microsoft/WSL/issues/143#issuecomment-209072634)" >&2
sudo tee /usr/sbin/policy-rc.d > /dev/null <<EOF
#!/bin/sh
exit 101
EOF
sudo chmod +x /usr/sbin/policy-rc.d
sudo dpkg-divert --local --rename --add /sbin/initctl
sudo ln -fs /bin/true /sbin/initctl

There are parts of the script here and in the above linked comment from issue 143 that get around different issues related to this class of problems.

serge-golovanow commented 6 years ago

Hi I just marked ebtables as holded, so apt won't try to update it :

$ sudo apt-mark hold ebtables ebtables set on hold.

SneWs commented 6 years ago

Same here, got hit with this issue doing apt-get update && apt-get upgrade just after finishing installing and setting up Ubuntu 18.04.

`Preparing to unpack .../ebtables_2.0.10.4-3.5ubuntu2.18.04.1_amd64.deb ... invoke-rc.d: could not determine current runlevel

sirredbeard commented 6 years ago

@13steinj Both 16.04 and 18.04 are on the store, but only 16.04 is on the WSL landing page. See #3249.

Edit: There was a previous ebtables upgrade bug that looked similar, but on closer inspection it was from 2014 so I opened a new one.

sirredbeard commented 6 years ago

I was looking at the upgrade apt was attempting:

$ apt-get -V -s upgrade NOTE: This is only a simulation! apt-get needs root privileges for real execution. Keep also in mind that locking is deactivated, so don't depend on the relevance to the real current situation! Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: ebtables (2.0.10.4-3.5ubuntu2 => 2.0.10.4-3.5ubuntu2.18.04.1) 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Inst ebtables [2.0.10.4-3.5ubuntu2] (2.0.10.4-3.5ubuntu2.18.04.1 Ubuntu:18.04/bionic-updates [amd64]) Conf ebtables (2.0.10.4-3.5ubuntu2.18.04.1 Ubuntu:18.04/bionic-updates [amd64])

Here is the Debian changelog showing the 2.0.10.4-3.5 update. Nothing jumps out at me in that changelog.

I have reported the bug upstream in Ubuntu and linked back to here. If you would be so kind as to confirm it there that would get it elevated in the Ubuntu system.

13steinj commented 6 years ago

@sirredbeard all due respect I do not care for that issue. It's minor and...well of no importance to me. My issue is with the fact that WSL doesn't support something as fundamental as runlevels, which is supposedly trivial to support (again, I am unaware how trivial this is, just parroting the claim of another user). That is the underlying cause of ebtables having an issue, many packages in 16.04 having an issue, and can cause it's own slew of problems for custom scripts that are being developed.

sirredbeard commented 6 years ago

@13steinj If you search for Ubuntu 18.04 in the Microsoft Store you can find it that way. There are a lot of things missing from WSL that you would find in a typical Linux distro. If you need a typical Linux distro, there are many excellent ones to chose from. There is also Docker and VirtualBox. WSL was intended to be used for programmers and developers to supplement their Windows workflow, so there was little need for runtime support. As WSL makes it way into Windows Server and SQL Server 2017 runs on Linux, it's possible we will see further development on that. Given how an init system would slow down launching the shell, all the issues that systemd can cause, the lack of support for sysvinit outside niche distros, the abandonment of Upstart, and the relative immaturity of OpenRC, I think going without an init for now was probably a smart move, at least until Microsoft saw what the users actually did with WSL. If possible, please confirm the bug reported upstream on Ubuntu's bug reporter so it will get fixed quicker. Thanks.

13steinj commented 6 years ago

@sirredbeard all of what you said is absolutely true. However one part is paradoxical:

WSL was intended to be used for programmers and developers to supplement their Windows workflow, so there was little need for runtime support.

I am a developer. Who in their development workflow, relies on the init system.

I am undoubtedly not the only one who does this. And many packages rely on it as well.

In this way WSL fails in its goal. It is undoubtedly a great tool, but it is also not one that I can use in its current state. It is worse than the VM I was already using. I was really hoping that WSL will be a proper replacement because that seems to be the goal that it set out to do. However it has failed me.

That said, I can not confirm the ebtables issue at this time, nor will I make a confirmation on the Ubuntu tracker. And the reason I won't is simply this: it's not an ebtables bug! The software is meant to run on Ubuntu and makes perfectly sane assumptions about its environment.

Trying to claim fault on them is like me making a new linux distribution that is supposed to be debian compatible yet only allow it to install RPM packages, and some RPM package fails to work on my distro because it assumes the environment is Red Hat.

If the WSL team decided (and I agree that it was a reasonable decision at the time) to not deal with a proper init system, sure, fine. But their wrong does not get transferred to the Ubuntu team nor should the Ubuntu team have to spend their time finding some strange work around because the WSL does fundamental linux concepts incorrectly. This is up to the WSL team to fix. Even if the ebtables maintainers resolve this issue this time, it is only a matter of time before it happens again.

A proper init system needs to be implemented-- period.

sonnetmia commented 6 years ago

Same problem here. Just marked this package on hold.

fpqc commented 6 years ago

Fellas, I understand the frustration. If you want MS to support systemd (which is what you want), please please vote up the existing uservoice. It only has like 200 votes.

sirredbeard commented 6 years ago

@13steinj

If you need a full init system then WSL is probably not for you at this time. I mentioned several alternatives and the reasons to believe that there may be a solution for you in the future. There are several other key features to implement in WSL as well, Microsoft seems to be adding them fairly quickly and doing a pretty stable job overall. Let's not forget that this is Microsoft implementing Linux on Windows. I don't see Apple implementing native cross-platform apps. Google is just getting around to it on one device which already ran Linux, it's not the technical accomplishment WSL is.

As for the upstream bug report, Ubuntu packages it's distro and officially supports ~8 different containerized platforms with special customizations to run well on each, including Docker, Azure, AWS, and WSL. Microsoft cannot make this change to this package, Canonical has to. Canonical cannot fix this for the WSL image unless they know about the bug. You can be sour Microsoft hasn't implemented an init system yet but in the mean time I am going to try to get this bug fixed by letting Canonical know. Yes, in an ideal world this wouldn't be an issue, but this is an evolving project. If you want boring and tested, I recommend CentOS.

You complained about Ubuntu being confusingly listed Microsoft Store and I pointed out that was an existing bug, #3249. In response you stated "I do not care for that issue. It's minor and...well of no importance to me". Then why did you complain about it on GitHub? I then suggested you help get the bug fixed in the upstream Ubuntu container by clicking a single button, which you similarly dismissed. I have always believed if you want things to happen in open source to you have to write it yourself or be patient, file bug reports, and wait until someone else writes/fixes it. That's the give and take of open source.

solracfirst commented 6 years ago

Same problem here.

13steinj commented 6 years ago

@sirredbeard, it is absolutely true that the WSL does not satisfy my needs at this time. And I am using one of the alternatives you mentioned if you bothered to read my comment. I have no problem with Microsoft and give them full props for the implementation they have thus far. However, this is fundamental to a wide variety of linux distributions. Without an init system, the WSL becomes useless for a wide variety of developers and extremely annoying for package maintainers.

I have seen no such report or blog post or notice that Canonical and the Ubuntu team officially support WSL, nor can I find one. If you link such notice, I will be more than happy to make an upstream confirmation to the bug report. Until then, I do not see this as an issue they have to care about because otherwise they don't have an issue-- WSL does. And that issue, is its lack of a proper init system, and no proper mock/polyfill to the runlevel system.

I did not complain about the confusing listing. All I did was mention that 16.04 was the version touted on the app store. And in my opinion, for good reason. It's still supported and more mature. Lots of developers stay on older versions of language VM runtimes and operating systems for just this reason. Hell, I know some people that are still on Ubuntu 14.04. You are absolutely right anout the give and take of open source, but these are not things I specifically want to happen. I would however like it that all available versions are listed on that page, however I don't really care for that specifically.

solracfirst commented 6 years ago

https://bugs.launchpad.net/ubuntu/+source/ebtables/+bug/1774120

sirredbeard commented 6 years ago

As of this afternoon a patch has been sponsored into Ubuntu's devel release Cosmic and will filter down to Bionic and then get backported to Xenial.

https://bugs.launchpad.net/ubuntu/+source/ebtables/+bug/1774120/comments/8

sirredbeard commented 6 years ago

@therealkenc Can you mark this bug as confirmed and that a patch is on the way? In the mean time we can point people towards @marchom's workaround above.

therealkenc commented 6 years ago

That workaround is narrowly limited to people's woes with 18.04, which is now in people's face, bumping this year old issue. The very rough guidance (if there is such a thing), based only on observation, is stuff that hangs out like this with no tag is nominally by-design or feature+backlog. I don't work at MSFT; whether someone is looking at it or not I haven't the slightest. But given it is now in people's face I would bet a Internet nickle they are.

The correct work-around for this remains setting up /var/run/utmp so WSL thinks it has a runlevel.

sirredbeard commented 6 years ago

@13steinj

Canonical supports Ubuntu on WSL similar to their support for Ubuntu on other container platforms, like Docker. Canonical partnered with Microsoft to bring Ubuntu to WSL. * Canonical are the ones who submit container images to the Microsoft Store using the reference template. It's not like Microsoft just downloads the ISO and puts it in the store themselves. Canonical also have published documentation on their site for WSL. * * Ubuntu and Microsoft are official corporate partners, not just on WSL but on Azure as well. * If you want to learn more about how Canonical's teams supports images of Ubuntu for several different platforms, I recommend s11e08 of the Ubuntu podcast.

By the way, from the bug report discussion it appears the actual bug is in how ebtables, called by ebtables.init, needlessly returns an error message. *. WSL fully supports EPROTONOSUPPORT socket() calls but ebtables still returns a permission error. This causes the error to be returned when the stop script is called as part of the package upgrade. *. The patch is to fix the script's handling of the permission error. * The actual long-term solution is to patch communications.c in ebtables.

So turns out lack of a init wasn't the issue and we could only find that out by filing a bug report and working together. Hooray open source.

sirredbeard commented 6 years ago

EPROTONOSUPPORT has been supported in WSL since last year. * and appears to work well in other programs. So I have filed a bug report upstream with the netfilter team, who inherited ebtables, regarding the handling of EPROTONOSUPPORT errors in ebtables. Contrary to the error message, I do not believe it's a permissions error because I can reproduce the error as root. The patches to the upgrade script (to disregard the error) by Canonical to Ubuntu Cosmic will trickle down to Bionic long before any patch by the netfilter team gets pushed to Debian then to Cosmic then Bionic, but we now have several viable short-term work arounds for WSL above, a medium-term workaround coming down from Ubuntu, and a long-term solution started.

marchom commented 6 years ago

Dan Streetman's investigation in the ubuntu bug showed that the problem is that on WSL, it appears creating a raw socket is failing:

sockfd = socket(AF_INET, SOCK_RAW, PF_INET);
if (sockfd < 0) {
    ebt_print_error("Problem getting a socket, "
                            "you probably don't have the right "
                            "permissions");
     ret = -1;

This MS post describes how to open sockets on WSL and it seems they added the functionality rather recently. As I understand it, there is the possibility that additional steps must be taken on the Windows side in order for a socket to be accessible by WSL. I have not tested this but it should be trivial for someone to create a POC by reading the ebtables code and trying to open a socket in a similar fashion.

therealkenc commented 6 years ago

sockfd = socket(AF_INET, SOCK_RAW, PF_INET);

Yeah I should have stated that explicitly in my last message. We have two unrelated fails in Daniel's original follow-up post and that is wreaking havoc on this issue topic. Almost to the point it may not recover.

...
invoke-rc.d: could not determine current runlevel
...
 * Error: insufficient privileges to access the ebtables rulesets.

socket(AF_INET, SOCK_RAW, ...) is [ed: better ref] #767 and friends. It has nothing to do with blog on AF_UNIX you cite. There is a UserVoice here.

marchom commented 6 years ago

Yes you are right. It is not a general issue with opening sockets, as I assumed, but a specific issue that WSL does not support kernel interfaces Linux iptables. This effectively means that ebtables is currently useless because you can't really do any filtering or bridging on the kernel level.

In that sense I, personally, would probably just sudo apt purge ebtables.

therealkenc commented 6 years ago

In that sense I, personally, would probably just sudo apt purge ebtables.

If that's a workable solution, so much the better. I am not entirely sure why/how etables is being invited to the party in 18.04. There would have been more chatter if it was a common problem previously (19 upvotes on your workaround).

Closing this issue as dupe #573 to try to get the runlevel fail (see issue title) back on track. Thank-you very much @marchom and @sirredbeard for following the etables fail and for the suggested workarounds. If the upstream package gets tweaked to be more tolerant of WSL that's double plus good.

DzeryCZ commented 6 years ago

I solved this issue by this:

sudo mv /var/lib/dpkg/info/{packagename}.* /tmp/
sudo dpkg --remove --force-remove-reinstreq {packagename}
sudo apt-get remove {packagename}
sudo apt-get autoremove && sudo apt-get autoclean

Maybe it'll help somebody.

binkley commented 6 years ago

I work on an extremely straight-forward "Enterprise Java" project. Essentially:

Now, in fact, it works. Bravo! However, it complains about run level with postgres install, and so per team norms, I cannot profer this setup to my other devs. Resolving runlevel would address this.

OnlyBelter commented 6 years ago

Another way, please see https://github.com/Microsoft/WSL/issues/2288

jcklpe commented 6 years ago

@caseyallen386 @georgique

I'm having similar problems. Casey, you basically just purged and reinstalled? Do you know why that fixed the issue but didn't for George? I have tried uninstalling and reinstalling multiple times and mysql keeps not working, and I have several times gotten errors codes like George's. I have just now purged everything as thoroughly as I know how, and then double checked by going through ever major folder at / and rm -r any mysql, php, or apache files I could find, and then I reinstalled, this time using sudo apt install -y lamp-server^ as per this tutorials here: https://hellojason.net/blog/how-to-setup-wordpress-locally-on-windows-subsystem-for-linux/

I'm fixing to test if everything works but while doing the LAMP install I noticed the reoccuring error code so I searched it and found this page.

If either of you know why this is happening or how it can be fixed, either the general difficulties I'm having getting MySQL to work on WSL or the specific issues brought up by this thread and related by George, I would love to know.

symant233 commented 5 years ago

same here using ubuntu wsl 16.04 LTS


mio@MiBookAir:~$ sudo apt-get install blueman 
Reading package lists... Done 
Building dependency tree        
Reading state information... Done
The following NEW packages will be installed: 
  blueman
0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded. 
Need to get 0 B/1,673 kB of archives. 
After this operation, 4,948 kB of additional disk space will be used.
Selecting previously unselected package blueman. 
(Reading database ... 180283 files and directories currently installed.) 
Preparing to unpack .../blueman_2.0.4-1ubuntu2_amd64.deb ...
Unpacking blueman (2.0.4-1ubuntu2) ... 
Processing triggers for dbus (1.10.6-1ubuntu3.3) ... 
Processing triggers for gnome-menus (3.13.3-6ubuntu3.1) ... 
Processing triggers for desktop-file-utils (0.22-1ubuntu5.2) ... 
Processing triggers for mime-support (3.59ubuntu1) ... 
Processing triggers for hicolor-icon-theme (0.15-0ubuntu1.1) ... 
Processing triggers for man-db (2.7.5-1) ... 
Processing triggers for libglib2.0-0:amd64 (2.48.2-0ubuntu4.1) ... 
Setting up blueman (2.0.4-1ubuntu2) ... 
invoke-rc.d: could not determine current runlevel 
 * Reloading system message bus config...                                                                 
Failed to open connection to "system" message bus: Failed to connect to socket /var/run/dbus/system_bus_so
cket: No such file or directory
invoke-rc.d: initscript dbus, action "reload" failed. 
dpkg: error processing package blueman (--configure): 
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing: 
 blueman
E: Sub-process /usr/bin/dpkg returned an error code (1) ```
yairEO commented 5 years ago

Tried everything on this thread multiple times without success:

root@PLIL19008WN:/# apt-get install mysql-server
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libaio1 libcgi-fast-perl libcgi-pm-perl libencode-locale-perl libevent-core-2.1-6 libfcgi-perl libhtml-parser-perl
  libhtml-tagset-perl libhtml-template-perl libhttp-date-perl libhttp-message-perl libio-html-perl liblwp-mediatypes-perl
  libtimedate-perl liburi-perl mysql-client-5.7 mysql-client-core-5.7 mysql-common mysql-server-5.7 mysql-server-core-5.7
Suggested packages:
  libdata-dump-perl libipc-sharedcache-perl libwww-perl mailx tinyca
The following NEW packages will be installed:
  libaio1 libcgi-fast-perl libcgi-pm-perl libencode-locale-perl libevent-core-2.1-6 libfcgi-perl libhtml-parser-perl
  libhtml-tagset-perl libhtml-template-perl libhttp-date-perl libhttp-message-perl libio-html-perl liblwp-mediatypes-perl
  libtimedate-perl liburi-perl mysql-client-5.7 mysql-client-core-5.7 mysql-common mysql-server mysql-server-5.7
  mysql-server-core-5.7
0 upgraded, 21 newly installed, 0 to remove and 172 not upgraded.
Need to get 0 B/21.0 MB of archives.
After this operation, 162 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Preconfiguring packages ...
Selecting previously unselected package mysql-common.
(Reading database ... 29266 files and directories currently installed.)
Preparing to unpack .../0-mysql-common_5.8+1.0.4_all.deb ...
Unpacking mysql-common (5.8+1.0.4) ...
Selecting previously unselected package libaio1:amd64.
Preparing to unpack .../1-libaio1_0.3.110-5_amd64.deb ...
Unpacking libaio1:amd64 (0.3.110-5) ...
Selecting previously unselected package mysql-client-core-5.7.
Preparing to unpack .../2-mysql-client-core-5.7_5.7.25-0ubuntu0.18.04.2_amd64.deb ...
Unpacking mysql-client-core-5.7 (5.7.25-0ubuntu0.18.04.2) ...
Selecting previously unselected package mysql-client-5.7.
Preparing to unpack .../3-mysql-client-5.7_5.7.25-0ubuntu0.18.04.2_amd64.deb ...
Unpacking mysql-client-5.7 (5.7.25-0ubuntu0.18.04.2) ...
Selecting previously unselected package mysql-server-core-5.7.
Preparing to unpack .../4-mysql-server-core-5.7_5.7.25-0ubuntu0.18.04.2_amd64.deb ...
Unpacking mysql-server-core-5.7 (5.7.25-0ubuntu0.18.04.2) ...
Selecting previously unselected package libevent-core-2.1-6:amd64.
Preparing to unpack .../5-libevent-core-2.1-6_2.1.8-stable-4build1_amd64.deb ...
Unpacking libevent-core-2.1-6:amd64 (2.1.8-stable-4build1) ...
Setting up mysql-common (5.8+1.0.4) ...
update-alternatives: using /etc/mysql/my.cnf.fallback to provide /etc/mysql/my.cnf (my.cnf) in auto mode
Selecting previously unselected package mysql-server-5.7.
(Reading database ... 29434 files and directories currently installed.)
Preparing to unpack .../00-mysql-server-5.7_5.7.25-0ubuntu0.18.04.2_amd64.deb ...
Unpacking mysql-server-5.7 (5.7.25-0ubuntu0.18.04.2) ...
Selecting previously unselected package libhtml-tagset-perl.
Preparing to unpack .../01-libhtml-tagset-perl_3.20-3_all.deb ...
Unpacking libhtml-tagset-perl (3.20-3) ...
Selecting previously unselected package liburi-perl.
Preparing to unpack .../02-liburi-perl_1.73-1_all.deb ...
Unpacking liburi-perl (1.73-1) ...
Selecting previously unselected package libhtml-parser-perl.
Preparing to unpack .../03-libhtml-parser-perl_3.72-3build1_amd64.deb ...
Unpacking libhtml-parser-perl (3.72-3build1) ...
Selecting previously unselected package libcgi-pm-perl.
Preparing to unpack .../04-libcgi-pm-perl_4.38-1_all.deb ...
Unpacking libcgi-pm-perl (4.38-1) ...
Selecting previously unselected package libfcgi-perl.
Preparing to unpack .../05-libfcgi-perl_0.78-2build1_amd64.deb ...
Unpacking libfcgi-perl (0.78-2build1) ...
Selecting previously unselected package libcgi-fast-perl.
Preparing to unpack .../06-libcgi-fast-perl_1%3a2.13-1_all.deb ...
Unpacking libcgi-fast-perl (1:2.13-1) ...
Selecting previously unselected package libencode-locale-perl.
Preparing to unpack .../07-libencode-locale-perl_1.05-1_all.deb ...
Unpacking libencode-locale-perl (1.05-1) ...
Selecting previously unselected package libhtml-template-perl.
Preparing to unpack .../08-libhtml-template-perl_2.97-1_all.deb ...
Unpacking libhtml-template-perl (2.97-1) ...
Selecting previously unselected package libtimedate-perl.
Preparing to unpack .../09-libtimedate-perl_2.3000-2_all.deb ...
Unpacking libtimedate-perl (2.3000-2) ...
Selecting previously unselected package libhttp-date-perl.
Preparing to unpack .../10-libhttp-date-perl_6.02-1_all.deb ...
Unpacking libhttp-date-perl (6.02-1) ...
Selecting previously unselected package libio-html-perl.
Preparing to unpack .../11-libio-html-perl_1.001-1_all.deb ...
Unpacking libio-html-perl (1.001-1) ...
Selecting previously unselected package liblwp-mediatypes-perl.
Preparing to unpack .../12-liblwp-mediatypes-perl_6.02-1_all.deb ...
Unpacking liblwp-mediatypes-perl (6.02-1) ...
Selecting previously unselected package libhttp-message-perl.
Preparing to unpack .../13-libhttp-message-perl_6.14-1_all.deb ...
Unpacking libhttp-message-perl (6.14-1) ...
Selecting previously unselected package mysql-server.
Preparing to unpack .../14-mysql-server_5.7.25-0ubuntu0.18.04.2_all.deb ...
Unpacking mysql-server (5.7.25-0ubuntu0.18.04.2) ...
Setting up libhtml-tagset-perl (3.20-3) ...
Setting up libevent-core-2.1-6:amd64 (2.1.8-stable-4build1) ...
Processing triggers for ureadahead (0.100.0-20) ...
Setting up libencode-locale-perl (1.05-1) ...
Setting up libtimedate-perl (2.3000-2) ...
Setting up libio-html-perl (1.001-1) ...
Setting up liblwp-mediatypes-perl (6.02-1) ...
Processing triggers for libc-bin (2.27-3ubuntu1) ...
Setting up libaio1:amd64 (0.3.110-5) ...
Setting up liburi-perl (1.73-1) ...
Processing triggers for systemd (237-3ubuntu10.3) ...
Setting up libhtml-parser-perl (3.72-3build1) ...
Setting up libcgi-pm-perl (4.38-1) ...
Processing triggers for man-db (2.8.3-2) ...
Setting up mysql-client-core-5.7 (5.7.25-0ubuntu0.18.04.2) ...
Setting up libfcgi-perl (0.78-2build1) ...
Setting up libhttp-date-perl (6.02-1) ...
Setting up libhtml-template-perl (2.97-1) ...
Setting up mysql-server-core-5.7 (5.7.25-0ubuntu0.18.04.2) ...
Setting up libcgi-fast-perl (1:2.13-1) ...
Setting up libhttp-message-perl (6.14-1) ...
Setting up mysql-client-5.7 (5.7.25-0ubuntu0.18.04.2) ...
Setting up mysql-server-5.7 (5.7.25-0ubuntu0.18.04.2) ...
invoke-rc.d: could not determine current runlevel
 * Stopping MySQL database server mysqld                                                                                       [ OK ]
update-alternatives: using /etc/mysql/mysql.cnf to provide /etc/mysql/my.cnf (my.cnf) in auto mode
Renaming removed key_buffer and myisam-recover options (if present)
Cannot open /proc/net/unix: No such file or directory
Cannot stat file /proc/1/fd/5: Operation not permitted
Cannot stat file /proc/3/fd/7: Operation not permitted
dpkg: error processing package mysql-server-5.7 (--configure):
 installed mysql-server-5.7 package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of mysql-server:
 mysql-server depends on mysql-server-5.7; however:
  Package mysql-server-5.7 is not configured yet.

dpkg: error processing package mysql-server (--configure):
 dependency problems - leaving unconfigured
Processing triggers for libc-bin (2.27-3ubuntu1) ...
No apport report written because the error message indicates its a followup error from a previous failure.
                                                                                                          Processing triggers for ureadahead (0.100.0-20) ...
Processing triggers for systemd (237-3ubuntu10.3) ...
Errors were encountered while processing:
 mysql-server-5.7
 mysql-server
E: Sub-process /usr/bin/dpkg returned an error code (1)
JulioV commented 5 years ago

I found the same problem as @yairEO, did you find a solution?

ktmn commented 5 years ago

@JulioV: for me @DzeryCZ's solution

sudo mv /var/lib/dpkg/info/{packagename}.* /tmp/
sudo dpkg --remove --force-remove-reinstreq {packagename}
sudo apt-get remove {packagename}
sudo apt-get autoremove && sudo apt-get autoclean

didn't work, just ran into invoke-rc.d: could not determine current runlevel when installing again, but @caseyallen386's solution did work:

sudo su
apt-get remove --purge 'mysql*'
apt-get autoremove
apt-get autoclean
rm -f /etc/mysql /var/lib/mysql
apt-get install mysql-server

In case of mysql-server just make sure to back up (mysqldump -u root -p --all-databases > all_databases.sql) the databases and then restore them afterwards (mysql -u root -p < all_databases.sql). When mysql-server wouldn't start up due to the runlevel error, I just rebooted the PC and then was able to start it and back up the databases.