Closed Abhinickz closed 6 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.
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.
Had the same issue. No changes on this?
Still having the problem. Exporting RUNLEVEL
didn't make a difference.
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 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.
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
`
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.
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!
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 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).
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.
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:
/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
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
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.
Hi I just marked ebtables as holded, so apt won't try to update it :
$ sudo apt-mark hold ebtables
ebtables set on hold.
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
@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.
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.
@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.
@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.
Same problem here. Just marked this package on hold.
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.
@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.
Same problem here.
@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.
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
@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.
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.
@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.
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.
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.
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.
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
.
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.
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.
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 https://github.com/Microsoft/WSL/issues/2288
@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.
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) ```
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)
I found the same problem as @yairEO, did you find a solution?
@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.
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
Actual results (with terminal output if applicable) 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
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