invoke-rc.d: could not determine current runlevel #1761
Comments
|
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. |
|
Try this: You are going to have no joy with |
|
Had the same issue. No changes on this? |
|
Still having the problem. Exporting |
|
This is still an issue. Can we get some sort of a resolution? This particular issue has been open for a year now. |
|
@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? |
|
Just warnings, along the lines of this. The That will kill the runlevel warning. You'll still get " |
|
I had this issue when updating mysql-server. I resolved my issue like this ` |
|
I'm seeing this issue with ebtables: autoremove/autoclean/install -f seems to make no difference. |
|
I tried to purge MySQL directories and reinstall it, however when I do the re-install, I get the following: |
|
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. |
|
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. |
|
@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? |
|
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. |
|
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 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). |
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 Ubuntu's |
|
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. |
|
The way I fixed this:
Just comment out the actions taken by stop) e.g.: and do your
The problem comes from the install/remove scripts trying to do |
|
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: yesWhich calls the following shell command: sudo /usr/bin/apt-get upgrade --with-new-pkgs --auto-remove Which fails with: Looks like |
|
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. 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. |
|
Hi
|
|
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 ...
|
|
I was looking at the upgrade apt was attempting:
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. |
|
@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. |
|
@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. |
|
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 |
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. |
|
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 autocleanMaybe it'll help somebody. |
|
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. |
|
Another way, please see #2288 |
|
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 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. |
|
same here using ubuntu wsl 16.04 LTS |
Tried everything on this thread multiple times without success: |
|
I found the same problem as @yairEO, did you find a solution? |
|
@JulioV: for me @DzeryCZ's solution didn't work, just ran into In case of |
|
@caseyallen386's solution also worked for me with reinstalling docker: |
|
same problem happen when And the solutions above can not fix the problem... |
|
Having same issue as @yairEO and tried out his solution BUT could not fix anything. Still getting the same |
|
Same issue with me. Unable to install mysql-server or mariadb-server on wsl 2 ubuntu or debian. Have tried multiple times. |
|
See #1332 (comment) |
|
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). |
|
Hello everyone, For me enabling |
|
I had a healthy system on which |
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 |
|
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. |
|
The current status of this issue ("invoke-rc.d: could not determine current runlevel") is it is closed duplicative #573. |
|
Had the same issue with couchdb. Tried everything - remove, purge, etc and kept hitting The only thing that worked perfectly is @marchom's #1761 (comment) |
and others
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
Removed some lines here........
Your Windows build number
Microsoft Windows [Version 10.0.15042]Steps / All commands required to reproduce the error from a brand new installation
Got error in upgrading these below packages:
imagemagick-common libimage-magick-perl libimage-magick-q16-perl libmagickcore-6.q16-2 linux-libc-dev mdadmThe text was updated successfully, but these errors were encountered: