Skip to content
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

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

Closed
Abhinickz opened this issue Mar 8, 2017 · 62 comments
Closed

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

Abhinickz opened this issue Mar 8, 2017 · 62 comments

Comments

@Abhinickz
Copy link

  • A brief description
    apt get install/upgrade giving some errors and warning for some packages, I have been able to replicate this issue many times.

  • Expected results

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 ...
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) ...
Processing triggers for libc-bin (2.23-0ubuntu5) ...
Processing triggers for initramfs-tools (0.122ubuntu8.8) ...
  • Actual results (with terminal output if applicable)
    Removed some lines here........
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) ...
  • Your Windows build number
    Microsoft Windows [Version 10.0.15042]

  • Steps / All commands required to reproduce the error from a brand new installation

sudo apt-get upgrade
sudo apt-get install some_packages_name
  • Required packages and commands to install
    Got error in upgrading these below packages:
    imagemagick-common libimage-magick-perl libimage-magick-q16-perl libmagickcore-6.q16-2 linux-libc-dev mdadm
@fpqc
Copy link

fpqc commented Mar 8, 2017

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
Copy link
Collaborator

therealkenc commented Mar 8, 2017

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
Copy link

Had the same issue. No changes on this?

@mix3d
Copy link

mix3d commented Nov 30, 2017

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

@josh-yoder-vive
Copy link

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

@benhillis
Copy link
Member

@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
Copy link
Collaborator

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
Copy link

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
Copy link

TheDan64 commented Apr 11, 2018

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
Copy link

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
Copy link

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
Copy link

fpqc commented May 22, 2018

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
Copy link

@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
Copy link

fpqc commented May 22, 2018

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
Copy link

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
Copy link
Collaborator

therealkenc commented May 22, 2018

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
Copy link

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
Copy link

marchom commented May 28, 2018

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
Copy link

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
Copy link

CeruleanSky commented May 28, 2018

About the same time as noelbundick and marchom found a solution, I used an alternative fix from #143 (comment) 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
Copy link

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
Copy link

SneWs commented May 30, 2018

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

  • 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)`

@sirredbeard
Copy link
Contributor

sirredbeard commented May 30, 2018

@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
Copy link
Contributor

sirredbeard commented May 30, 2018

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
Copy link

@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
Copy link
Contributor

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

@marchom
Copy link

marchom commented Jun 1, 2018

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
Copy link
Collaborator

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
Copy link

DzeryCZ commented Jun 14, 2018

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
Copy link

binkley commented Jul 15, 2018

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

  • Node for UI (with all the trappings)
  • Spring Boot for the API server
  • Postgres for the database

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
Copy link

Another way, please see #2288

@jcklpe
Copy link

jcklpe commented Sep 12, 2018

@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
Copy link

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
Copy link

yairEO commented Mar 28, 2019

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
Copy link

JulioV commented Apr 11, 2019

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

@ktmn
Copy link

ktmn commented May 7, 2019

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

@eternaldoctorwho
Copy link

@caseyallen386's solution also worked for me with reinstalling docker:

sudo su
apt-get remove --purge docker-ce docker-ce-cli containerd.io
apt-get autoremove
apt-get autoclean
rm -rf /etc/docker /var/lib/docker
apt-get install docker-ce docker-ce-cli containerd.io

@edwinhuish
Copy link

edwinhuish commented Jul 5, 2019

same problem happen when apt-get install or apt-get remove anything....

And the solutions above can not fix the problem...

@jung-youjin
Copy link

Having same issue as @yairEO and tried out his solution BUT could not fix anything. Still getting the same invoke-rc.d: could not determine current runlevel issue! 😭

@mikelukins
Copy link

Same issue with me. Unable to install mysql-server or mariadb-server on wsl 2 ubuntu or debian. Have tried multiple times.

@sabl0r
Copy link

sabl0r commented May 14, 2020

See #1332 (comment)

@bobsyourmom
Copy link

Problem could be because your script is trying to use invoke-rc.d (which doesn't work because there are no runlevels in a docker container) before trying the service command (which will work).
So change the if conditions in the script or the lazy way is make it look for a non-existent path so it will use the service command. eg:
if [ -x /xxxusr/sbin/invoke-rc.d ]; then
/usr/sbin/invoke-rc.d $OMSAGENT_WS start
elif [ -x /sbin/service ]; then
/sbin/service $OMSAGENT_WS start

@Lcchy
Copy link

Lcchy commented May 21, 2020

Hello everyone,

For me enabling systemd on WSL2 has resolved the issue. There is even a wrapped up version of the manipulation.
Thanks to the author.

@aamcintosh
Copy link

I had a healthy system on which
$ ls -l /sbin/runlevel
lrwxrwxrwx 1 root root 14 Apr 28 09:03 /sbin/runlevel -> /bin/systemctl
I had a broken system where apt upgrade of mysql complained about being unable to determine the current runlevel because /sbin/runlevel was missing:
/usr/sbin/invoke-rc.d: 1: /usr/sbin/invoke-rc.d: /sbin/runlevel: not found
Providing the symlink made the problem go away.
YMMV.

@wyattfry
Copy link

wyattfry commented Oct 22, 2020

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

`

This worked for me on WSL2 / Ubuntu 16.04.7 LTS Xenial Xerus, thanks! It did prompt for setting a db password for the user root about 4 times, i just hit enter, not sure if that was a good idea....

@13steinj
Copy link

13steinj commented Nov 1, 2020

What's the current status of this issue? Because the last time I was here I was basically told "no it's not a WSL issue, it has to be changed in the relevant upstream package repo".

But it seems as more and more packages are having this same issue.

@therealkenc
Copy link
Collaborator

The current status of this issue ("invoke-rc.d: could not determine current runlevel") is it is closed duplicative #573.

@zehawki
Copy link

zehawki commented Feb 26, 2023

Had the same issue with couchdb. Tried everything - remove, purge, etc and kept hitting invoke-rc.d: could not determine current runlevel

The only thing that worked perfectly is @marchom's #1761 (comment)

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

No branches or pull requests