Installed libc bin package post installation script subprocess returned error exit status 135

Are you upgrading from 16.04 or performing a routine upgrade on an existing 18.04?

Routine upgrade on 18.04.

I usually just go ahead and reset the app when I get this error (about every few weeks, roughly once a month). I decided to just wait and see if anyone had any ideas that I could look at, first. Weird thing is, it seems to have resolved itself(?) and I have no idea why. I was able to install libc-bin and a few other packages and looking at my /var/log/dpkg.log seems to confirm it. So now I feel like the boy who cried wolf, only there was a real wolf before it disappeared.

I think a reboot is essentially «fixing» the problem, at least partially. It just cropped up in a Windows 10 VM I have (1909, 18363.535). Before the reboot I did (in a sudo -i session): «rm /var/cache/ldconfig/aux-cache» and «ldconfig». The ldconfig aborted with error. After VM reboot, I was able to do a «sudo apt-get install —reinstall libc-bin» and it complained that «W: APT had planned for dpkg to do more than it reported back (0 vs 4)» but I had also tried to install aptitude somewhere in the mix. Anyways, that reinstall of libc-bin finished successfully. So, rebooting resets or fixes something. For what it is worth, this WSL has been upgraded (wslconfig /upgrade ubuntu) but I had this problem occasionally before the upgrade process was available.

I reboot the computer,but the problem just still there

This happened again to me recently, and this time, a reboot no longer fixed the issue (in this particular circumstance, I received an update for «wslu», and I believe that it is the offending package, or at least is the package where the error occurred). I was forced to reset the app and do all apt updates and customization again.

Do you want to continue? [Y/n] y
Setting up libc-bin (2.27-3ubuntu1) ...
Aborted (core dumped)
/sbin/ldconfig.real: Can't stat /usr/local/lib/x86_64-linux-gnu: No such file or directory
/sbin/ldconfig.real: Path /lib/x86_64-linux-gnu' given more than once /sbin/ldconfig.real: Path /usr/lib/x86_64-linux-gnu' given more than once
/usr/local/lib:
/lib/x86_64-linux-gnu:
Aborted (core dumped)

That fail (particularly the segfault) is all in userspace so there is (unfortunately) no WSL actionable. Standard operating procedure is doing various apt rain dances of questionable efficacy and reinstall when all else fails. Hat tip for the ubuntu forum link above.

I suspect this is a Canonical problem? Not sure. I wish someone could figure it out and resolve it. I for sure can’t, other than resetting the app which works great, but have to start all over again of course.

I suspect this is a Canonical problem?

Probably not, narrowly speaking. I imagine the problem, educated guess, applies to any Debian based distro (ubuntu or otherwise). Whatever (scary quote) «the problem» is/was. Once a distro is hooped down at the ldconfig and libc system layer that’s a deep hole to climb out of. It is almost certainly possible to recover without resorting to a reinstall (because anything possible), but likely you would be chasing diminishing returns in the effort. Note you can get the equivalent of a reboot with a wsl.exe --shutdown if you (or anyone else) bangs on it further. You don’t need to resort to the red button. Bonne chance.

Thank you for that explanation. I didn’t think of that. Makes sense. I love Windows 10. I love Ubuntu. I really like the entire idea behind Ubuntu WSL, and I’d actually love it, if I wasn’t cursed with this problem (one of the few, the proud… lol). As far as I know, I’m not doing anything to cause it. I’ll try that wsl.exe —shutdown thing next time (I’d cross my fingers, but I’m not exactly hopeful).

Well, it just happened again, and wsl.exe —shutdown did not fix it. For what it’s worth. Why does this happen to me and almost no one else? Is no one else even trying to update their Ubuntu WSL on a regular basis? I imagine they would want to do so, for security fixes if nothing else.

/etc/ld.so.conf:
include /etc/ld.so.conf.d/*.conf
I’m kind of curious, because I think I got a faulty /etc/ld.so.conf this time which tripped it up. It should say something like the above, but I remember it being something different. According to dpkg -S ld.so.conf, that gets installed with the libc-bin package. Also, the /etc/ld.so.conf.d/ directory got some fakeroot file which is not there on a fresh install (after doing the sudo apt update and sudo apt full-upgrade, even). Next time it crashes, in about a month, I’ll try looking up this Github comment and seeing if it fixes it (skeptical).

Oops. The /etc/ld.so.conf.d/fakeroot-x86_64-linux-gnu.conf file came in with the fakeroot package, which I think is a dependency of python3-venv (if it matters, I also tend to have python3-pip installed). Just commenting for the historical record, in case this matters.

This fix my problem 👍 :+1 if this working for you.

sudo mv /var/lib/dpkg/info/libc-bin.* /tmp/
sudo dpkg --remove --force-remove-reinstreq libc-bin
sudo dpkg --purge libc-bin
sudo apt install libc-bin
sudo mv /tmp/libc-bin.* /var/lib/dpkg/info/

Thanks! I’ve already reset my Ubuntu app so I will have to wait until it happens again, which so far is roughly every two or three weeks.

This fix my problem 👍 :+1 if this working for you.

Not in my case. I used:

sudo  dpkg --remove --force-remove-reinstreq --force-remove-essential --force-depends libc-bin
sudo dpkg --purge --force-remove-reinstreq --force-remove-essential --force-depends libc-bin
sudo mv /var/lib/dpkg/info/libc6:amd64.* /tmp/
sudo apt install -f libc-bin
sudo mv /tmp/libc6:amd64.* /var/lib/dpkg/info/

I have not seen the problem again, thankfully, but if I ever do, I will try to remember to come back here and try those instructions. Again, I am thankful also that the Reset option in Windows 10 Apps is available.

I had the issue today.

Could not install anything else because apt is trying to fix the installation of libc-bin. I tried the above instructions, but it failed at the reinstallation of libc-bin, so now there is no more libc, ldconfig, or anything else to get the system working.

I had to completely reinstall the WSL distribution.

This issue should not be closed.

This happened to me after trying to install nmap on WSL. In my case, ldconfig was segfaulting (choking on libpcap) and causing libc-bin to appear broken. I’ll provide my troubleshooting journey since yours will likely be slightly different:

Attempting to run ldconfig yielded the following:

[~/build/libc]$ ldconfig -v
/sbin/ldconfig.real: Can't stat /usr/local/lib/x86_64-linux-gnu: No such file or directory
/sbin/ldconfig.real: Path `/lib/x86_64-linux-gnu' given more than once
/sbin/ldconfig.real: Path `/usr/lib/x86_64-linux-gnu' given more than once

<... blah blah blah...>

/usr/lib/x86_64-linux-gnu:
[1]    1528 abort (core dumped)  ldconfig -v

Well, OK. Let’s uninstall nmap and try again:

[~]$ sudo apt remove nmap
<... etc ...>
Package 'nmap' is not installed, so not removed

That looks promising. Let’s see which of its dependencies might be naughty:

[~]$ apt show nmap
<... blah blah blah...>
Depends: libc6 (>= 2.15), libgcc1 (>= 1:3.0), liblinear3 (>= 2.01+dfsg), liblua5.3-0, libpcap0.8 (>= 0.9.8), libpcre3, libssl1.1 (>= 1.1.0), libstdc++6 (>= 5.2), zlib1g (>= 1:1.1.4)

Those all look fairly innocuous with the exception of libpcap. Let’s see if it’s dropped anything in that path ldconfig was complaining about:

[~]$ mkdir /tmp/pcap
[~]$ dpkg -x /var/cache/apt/archives/libpcap0.8_1.8.1-6ubuntu1.18.04.1_amd64.deb /tmp/pcap
[~]$ ls /tmp/pcap/usr/lib/x86_64-linux-gnu
libpcap.so.0.8  libpcap.so.1.8.1

Right then. Out they go!

[~]$ sudo rm /usr/lib/x86_64-linux-gnu/libpcap.so.*
[~]$ sudo apt install libc-bin

And all was well. You probably don’t need to reinstall libc-bin unless you (like me) casually delete system files in the process of troubleshooting. Don’t forget to clean up after that partially removed package:

[~]$ sudo apt remove libpcap0.8

tl;dr:
Some libs apparently break ldconfig. Manually remove the offending library and clean up the mess. In my case it was libpcap0.8.

I have recently run into this problem. The solution for my case turns out to be surprisingly easy: for each Can't stat , manually run ls that directory, and then run the same apt again.

tl;dr:
Some libs apparently break ldconfig. Manually remove the offending library and clean up the mess. In my case it was libpcap0.8.

In my case, as far as I remember, my problems arose with clean WSL installations (I never tried to install nmap or libpcap, etc.). Though I did put in a customized ~/.bash_aliases each time, and part of me wonders if something in it caused the issue. Anyways, I have not had the problem come up again, but have also not been using WSL much at all recently. I’m interested in the «ls» trick mentioned in another comment, because it sounds too good to be true.

I have recently run into this problem. The solution for my case turns out to be surprisingly easy: for each Can't stat , manually run ls that directory, and then run the same apt again.

I almost wish I would have the issue again, so I could try this—it sounds too good to be true, to be honest.

This fix my problem 👍 :+1 if this working for you.

sudo mv /var/lib/dpkg/info/libc-bin.* /tmp/
sudo dpkg --remove --force-remove-reinstreq libc-bin
sudo dpkg --purge libc-bin
sudo apt install libc-bin
sudo mv /tmp/libc-bin.* /var/lib/dpkg/info/

It works. Thank you

Faced similar problem on Kali Linux, this helped:

dpkg: warning: ‘ldconfig’ not found in PATH or not executable
dpkg: error: 1 expected program not found in PATH or not executable


~# apt download libc-bin
~# dpkg -x libc-bin*.deb unpackdir/
~# cp unpackdir/sbin/ldconfig /sbin/
~# mv /var/lib/dpkg/info/libc6:amd64.* /tmp/
~# apt install -f libc-bin
~# mv /tmp/libc6:amd64.* /var/lib/dpkg/info/

Faced similar problem on Kali Linux, this helped:

dpkg: warning: ‘ldconfig’ not found in PATH or not executable
dpkg: error: 1 expected program not found in PATH or not executable


~# apt download libc-bin
~# dpkg -x libc-bin*.deb unpackdir/
~# cp unpackdir/sbin/ldconfig /sbin/
~# mv /var/lib/dpkg/info/libc6:amd64.* /tmp/
~# apt install -f libc-bin
~# mv /tmp/libc6:amd64.* /var/lib/dpkg/info/

That worked a treat and you posted it yesterday, lucky me! THANKS!

I have recently run into this problem. The solution for my case turns out to be surprisingly easy: for each Can't stat , manually run ls that directory, and then run the same apt again.

To my absolute shock and amazement, this is indeed the solution. Except for one caveat: ls -alh didn’t quite cut it. Instead, this is what worked for me: for PROBDIR in "" "/usr" "/usr/local"; do find "${PROBDIR}/lib/x86_64-linux-gnu" -type f -ls; done;

all methods above would cause errors below
(I only found this problem on wsl ubuntu18 version)

dpkg: error processing package libc-bin (--configure):
 installed libc-bin package post-installation script subprocess returned error exit status 134
Errors were encountered while processing:
 libc-bin
E: Sub-process /usr/bin/dpkg returned an error code (1)

I have recently run into this problem. The solution for my case turns out to be surprisingly easy: for each Can't stat , manually run ls that directory, and then run the same apt again.

To my absolute shock and amazement, this is indeed the solution. Except for one caveat: ls -alh didn’t quite cut it. Instead, this is what worked for me: for PROBDIR in "" "/usr" "/usr/local"; do find "${PROBDIR}/lib/x86_64-linux-gnu" -type f -ls; done;

This fixed it, thanks!

I have recently run into this problem. The solution for my case turns out to be surprisingly easy: for each Can't stat , manually run ls that directory, and then run the same apt again.

To my absolute shock and amazement, this is indeed the solution. Except for one caveat: ls -alh didn’t quite cut it. Instead, this is what worked for me: for PROBDIR in "" "/usr" "/usr/local"; do find "${PROBDIR}/lib/x86_64-linux-gnu" -type f -ls; done;

Thanks, it worked for me too with WSL1 and Debian 10 on Windows 20H2

This fixed a related issue in Ubuntu 18.04 WSL1 Windows 10 (1909) where ldconfig complains «directory listed twice» then dumps core

Setting up libc-bin (2.31-0ubuntu9.2) …
Aborted (core dumped)
/sbin/ldconfig.real: Path /usr/lib/x86_64-linux-gnu' given more than once /sbin/ldconfig.real: Path /usr/lib32′ given more than once
/sbin/ldconfig.real: Path /lib/x86_64-linux-gnu' given more than once /sbin/ldconfig.real: Path /usr/lib/x86_64-linux-gnu’ given more than once
/sbin/ldconfig.real: Path `/usr/lib’ given more than once
/usr/lib/x86_64-linux-gnu/libfakeroot:
libfakeroot-0.so -> libfakeroot-tcp.so
/usr/local/lib:
/usr/local/lib/x86_64-linux-gnu:
/lib/x86_64-linux-gnu:
Aborted (core dumped)
dpkg: error processing package libc-bin (—configure):
installed libc-bin package post-installation script subprocess returned error exit status 134
Errors were encountered while processing:
libc-bin
E: Sub-process /usr/bin/dpkg returned an error code (1)

Finally I solved this by uninstalling ubuntu of WLS.

wonderful,it’s solved my problem

I must say sorry. I’m so excited that I reply for this wrong quote.

sudo apt autoremove can solve my problem

Finally I solved this by uninstalling ubuntu of WLS.

wonderful,it’s solved my problem

I must say sorry. I’m so excited that I reply for this wrong quote.

sudo apt autoremove can solve my problem

sorry , still this question when i do this

It does not stop it from happening but when it does I ruin this little script i found on another post. It allows it to set back up and work. So every time it bonks out i run «fixme» shell script as follows.

#/bin/bash
sudo mv /var/lib/dpkg/info/libc-bin.* /tmp/
sudo dpkg --remove --force-remove-reinstreq libc-bin
sudo dpkg --purge libc-bin
sudo apt -y install libc-bin
sudo mv /tmp/libc-bin.* /var/lib/dpkg/info/

It works for me. Someone a while ago posted it here, it is not my script, I just use it (a lot).

Run «sudo apt-get dist-upgrade» on root user on Ubuntu and it will fix the issue.

sudo apt-get dist-upgrade
still this question

Run «sudo apt-get dist-upgrade» on root user on Ubuntu and it will fix the issue.

Not solving it for me

I got the same error. Unable to solve

After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up libc-bin (2.31-0ubuntu9.4) ...
Aborted (core dumped)
/sbin/ldconfig.real: Path `/usr/lib32' given more than once
/sbin/ldconfig.real: Path `/usr/lib/x86_64-linux-gnu' given more than once
/sbin/ldconfig.real: Path `/usr/lib' given more than once
/usr/lib/x86_64-linux-gnu/libfakeroot:
        libfakeroot-0.so -> libfakeroot-tcp.so
/usr/lib/wsl/lib:
/usr/local/lib:
        libnanosleep.so -> libnanosleep.so
/lib32:
        libutil.so.1 -> libutil-2.31.so
        libthread_db.so.1 -> libthread_db-1.0.so
        libstdc++.so.6 -> libstdc++.so.6.0.28
        libSegFault.so -> libSegFault.so
        librt.so.1 -> librt-2.31.so
        libresolv.so.2 -> libresolv-2.31.so
        libpthread.so.0 -> libpthread-2.31.so
        libpcprofile.so -> libpcprofile.so
        libnss_nisplus.so.2 -> libnss_nisplus-2.31.so
        libnss_nis.so.2 -> libnss_nis-2.31.so
        libnss_hesiod.so.2 -> libnss_hesiod-2.31.so
        libnss_files.so.2 -> libnss_files-2.31.so
        libnss_dns.so.2 -> libnss_dns-2.31.so
        libnss_compat.so.2 -> libnss_compat-2.31.so
        libnsl.so.1 -> libnsl-2.31.so
        libmemusage.so -> libmemusage.so
        libm.so.6 -> libm-2.31.so
        libgcc_s.so.1 -> libgcc_s.so.1
        libdl.so.2 -> libdl-2.31.so
        libc.so.6 -> libc-2.31.so
        libBrokenLocale.so.1 -> libBrokenLocale-2.31.so
        libanl.so.1 -> libanl-2.31.so
/sbin/ldconfig.real: /lib32/ld-2.31.so is the dynamic linker, ignoring

        ld-linux.so.2 -> ld-2.31.so
/lib/x86_64-linux-gnu:
Aborted (core dumped)
dpkg: error processing package libc-bin (--configure):
 installed libc-bin package post-installation script subprocess returned error exit status 134
Errors were encountered while processing:
 libc-bin
E: Sub-process /usr/bin/dpkg returned an error code (1)

After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up libc-bin (2.31-0ubuntu9.4) ...
Aborted (core dumped)
/sbin/ldconfig.real: Path `/usr/lib32' given more than once
/sbin/ldconfig.real: Path `/usr/lib/x86_64-linux-gnu' given more than once
/sbin/ldconfig.real: Path `/usr/lib' given more than once
/usr/lib/x86_64-linux-gnu/libfakeroot:
        libfakeroot-0.so -> libfakeroot-tcp.so
/usr/lib/wsl/lib:
/usr/local/lib:
        libnanosleep.so -> libnanosleep.so
/lib32:
        libutil.so.1 -> libutil-2.31.so
        libthread_db.so.1 -> libthread_db-1.0.so
        libstdc++.so.6 -> libstdc++.so.6.0.28
        libSegFault.so -> libSegFault.so
        librt.so.1 -> librt-2.31.so
        libresolv.so.2 -> libresolv-2.31.so
        libpthread.so.0 -> libpthread-2.31.so
        libpcprofile.so -> libpcprofile.so
        libnss_nisplus.so.2 -> libnss_nisplus-2.31.so
        libnss_nis.so.2 -> libnss_nis-2.31.so
        libnss_hesiod.so.2 -> libnss_hesiod-2.31.so
        libnss_files.so.2 -> libnss_files-2.31.so
        libnss_dns.so.2 -> libnss_dns-2.31.so
        libnss_compat.so.2 -> libnss_compat-2.31.so
        libnsl.so.1 -> libnsl-2.31.so
        libmemusage.so -> libmemusage.so
        libm.so.6 -> libm-2.31.so
        libgcc_s.so.1 -> libgcc_s.so.1
        libdl.so.2 -> libdl-2.31.so
        libc.so.6 -> libc-2.31.so
        libBrokenLocale.so.1 -> libBrokenLocale-2.31.so
        libanl.so.1 -> libanl-2.31.so
/sbin/ldconfig.real: /lib32/ld-2.31.so is the dynamic linker, ignoring

        ld-linux.so.2 -> ld-2.31.so
/lib/x86_64-linux-gnu:
Aborted (core dumped)
dpkg: error processing package libc-bin (--configure):
 installed libc-bin package post-installation script subprocess returned error exit status 134
Errors were encountered while processing:
 libc-bin
E: Sub-process /usr/bin/dpkg returned an error code (1)

As other comments said, try these things:

for PROBDIR in "" "/usr" "/usr/local"; do find "${PROBDIR}/lib/x86_64-linux-gnu" -type f -ls; done;
sudo apt-get dist-upgrade
sudo apt-get autoremove

This fix my problem 👍 :+1 if this working for you.

sudo mv /var/lib/dpkg/info/libc-bin.* /tmp/
sudo dpkg --remove --force-remove-reinstreq libc-bin
sudo dpkg --purge libc-bin
sudo apt install libc-bin
sudo mv /tmp/libc-bin.* /var/lib/dpkg/info/

I have this issue pop up on me every now and then. Just made this a bash script and run it when it happens. Fixes every time. I just have to remember I have that script when it happens lol.

What the hell.

For WSL Ubuntu 20.04 users on Windows 21H2:

for PROBDIR in "" "/usr" "/usr/local"; do find "${PROBDIR}/lib/x86_64-linux-gnu" -type f -ls; done;
sudo apt autoremove

Can’t say I understood the issue but went on a limb and did the following that fixed the issue.

ln -s /usr/lib/x86_64-linux-gnu/ /usr/bin/x86_64-linux-gnu

This fix my problem 👍 :+1 if this working for you.

sudo mv /var/lib/dpkg/info/libc-bin.* /tmp/
sudo dpkg --remove --force-remove-reinstreq libc-bin
sudo dpkg --purge libc-bin
sudo apt install libc-bin
sudo mv /tmp/libc-bin.* /var/lib/dpkg/info/

Since it’s buried so far down I’m requoting it — had this issue today randomly on debian testing, this was the only solution that worked!

Just sudo apt install libc-bin did the trick — problem solved. Thanks! P.S. Removing the package didn’t work — for each I got an error «this is an essential package; it should not be removed»

I just ran «sudo mv /var/lib/dpkg/info/libc-bin.* /tmp/» and apt-get update subsequently to fix this issue.

This worked for me

for PROBDIR in "" "/usr" "/usr/local"; do find "${PROBDIR}/lib/x86_64-linux-gnu" -type f -ls; done;
sudo apt install libc-bin -y
sudo mv /var/lib/dpkg/info/libc-bin.* /tmp/
sudo apt install libc-bin -y

This worked for me

for PROBDIR in "" "/usr" "/usr/local"; do find "${PROBDIR}/lib/x86_64-linux-gnu" -type f -ls; done;
sudo apt install libc-bin -y
sudo mv /var/lib/dpkg/info/libc-bin.* /tmp/
sudo apt install libc-bin -y

FINALLY this was the first one out of countless error 134 thanks

So, it has now gotten to the point where I have to fix libc-bin every time I update/upgrade or install new packages. Any word on a fix for this?

So, it has now gotten to the point where I have to fix libc-bin every time I update/upgrade or install new packages. Any word on a fix for this?

I don’t understand why so few people are talking about this entire issue. I am litterally experiencing this on ALL systems that I use WSL on, both with Debian and Ubuntu.
There is clearly a general issue but updating your distro at a regular base seems to be a thing limited to a small amount of people or so. I don’t get it.

It only happens for me on WSL version 1 and I just have gotten used to fixing it when I update. But yes it does happen on that version almost every time.

On WSL2/Ubuntu 20.04 updating for the first time in like a year; the below let other packages update but left libc-bin as «not fully installed» and apt would try to install libc-bin, and print ldconfig messages and crash «Aborted (core dumped)», if you try to install anything else or do apt autoremove.

sudo mv /var/lib/dpkg/info/libc-bin.* /tmp/
sudo dpkg --remove --force-remove-reinstreq libc-bin
sudo dpkg --purge libc-bin
sudo apt -y install libc-bin
sudo mv /tmp/libc-bin.* /var/lib/dpkg/info/

Running sudo ldconfig crashed «Aborted (core dumped)».

Updating ldconfig cache while ignoring /var/cache/ldconfig/aux-cache fixed it for me. (I didn’t have the foresight to backup the binary aux-cache file so it could be attached to a bug report about ldconfig somewhere.) source

Solution:

Edit: Actually ignoring/removing aux-cache was mentioned early in the thread.

I have recently run into this problem. The solution for my case turns out to be surprisingly easy: for each Can't stat , manually run ls that directory, and then run the same apt again.

To my absolute shock and amazement, this is indeed the solution. Except for one caveat: ls -alh didn’t quite cut it. Instead, this is what worked for me: for PROBDIR in "" "/usr" "/usr/local"; do find "${PROBDIR}/lib/x86_64-linux-gnu" -type f -ls; done;

I want to confirm tha this worked for me on Ubuntu-20.04.
One note only is that I needed to execute command multiple times (3-4) untill problem was resolved.

Thank you for your help.

One thing that worked for me was (temporarily) changing from WSL 1 to WSL 2.

• Close any WSL windows
• From CMD or Powershell run «wsl —set-version Ubuntu-22.04 2» (you can use «wsl -l -v» to get your WSL distro name if different)
• Open WSL and run «sudo apt upgrade» or whatever was giving you the error before.
• Once you’re happy, if you want to switch back, close WSL then run «wsl —set-version Ubuntu-22.04 1»

This worked for me and may be worth trying if the find/ls solution above does not work for you (it did not work for me, I just got no such file errors).

Has been a while ago that I replied here. In my case I was using WSL 2 and experiencing the issue, not using WSL 1.

I would like to add that I changed a few things and that I seem to be no longer having the issue.

First of all I am no longer run more than 1 distro. Just Ubuntu, because I wanted to stop fixing things. I don’t know if this matters or not (I hope distros don’t conflict with resources or something weird like that).
But there is more …

I no longer install distros from the command line using wsl --install -d <Distro>, but I installed just «Ubuntu» directly via Microsoft Store app instead. (Note: I am not talking about «Ubuntu-16.04» or «Ubuntu-18.04» or «Ubuntu-20.04», but really just «Ubuntu» in both cases, because I haven’t tested the other ones. I also stopped using Debian so I don’t know if this change would apply for that one either).

Surpisingly, it turned out that I kept getting a different version of Ubuntu from the Store than when using the command line. First of all very interesting because apparantly these things differ from each other.
Secondly it’s very weird because the distro name was exactly the same, «Ubuntu» in both cases.
The version from Store looked much newer though, also coming with default styling for the Windows Terminal, which is also new.

For some people this might all be obvious, but at least it wasn’t for me.

Most importantly, it turns out that I have no longer seen the libc-bin issue coming back after this change.
So maybe if other people read it, they can benefit from this knowlege as well.

Has been a while ago that I replied here. In my case I was using WSL 2 and experiencing the issue, not using WSL 1.

I would like to add that I changed a few things and that I seem to be no longer having the issue.

First of all I am no longer run more than 1 distro. Just Ubuntu, because I wanted to stop fixing things. I don’t know if this matters or not (I hope distros don’t conflict with resources or something weird like that). But there is more …

I no longer install distros from the command line using wsl --install -d <Distro>, but I installed just «Ubuntu» directly via Microsoft Store app instead. (Note: I am not talking about «Ubuntu-16.04» or «Ubuntu-18.04» or «Ubuntu-20.04», but really just «Ubuntu» in both cases, because I haven’t tested the other ones. I also stopped using Debian so I don’t know if this change would apply for that one either).

Surpisingly, it turned out that I kept getting a different version of Ubuntu from the Store than when using the command line. First of all very interesting because apparantly these things differ from each other. Secondly it’s very weird because the distro name was exactly the same, «Ubuntu» in both cases. The version from Store looked much newer though, also coming with default styling for the Windows Terminal, which is also new.

For some people this might all be obvious, but at least it wasn’t for me.

Most importantly, it turns out that I have no longer seen the libc-bin issue coming back after this change. So maybe if other people read it, they can benefit from this knowlege as well.

I appreciate the time you took to research and write this up. However, I am using the Windows Store «Ubuntu» version and still receive this error. I am running WSL1 though, so there could be a difference here.

OdTu OdTu

1193 bronze badges