-
Notifications
You must be signed in to change notification settings - Fork 822
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
Ubuntu 17.10 bash
preinst: ../sysdeps/unix/sysv/linux/spawni.c:360: __spawnix: Assertion `ec >= 0' failed.
#2615
Comments
|
Interestingly enough, I was able to successfully perform the dist-upgrade that jumped me all the way from 16.04 to 17.10 with no upgrades to 16.10 or 17.04 first after performing the dbus commands and regenerating the locale but I get this error that is extremely similar to yours when I try to do a apt-get upgrade. I'm unable to show the output right now but basically there's an error that created by bash_4.4-5ubuntu1_amd64.deb that appears to be generated by dpkg. It appears that the .deb file didn't successfully migrate with the upgrade to 17.10 and is expecting data files from 16.04 that no longer exist. I have done the dpkg --configure -a to no joy. I believe the issue could be corrected by simply replacing the .deb file with an un-corrupted version though how one could go about doing that is the part I'm not entirely sure about. Also, performing an strace literally generates pages upon pages that's too long to place here. I am running the FCU build. |
This has the same underlying cause as #1878. This will be fixed in future insider build. |
@jstarks Do you know which Insider build it will be released in? |
Was this fixed in 17040 ? |
Unfortunately it didn’t make 17040. But the changes are staged for the next insiders build (along with some other good fixes). |
Windows Insider Build 17046 has improved CLONE_VFORK and CLONE_VM support. |
In the spirit of openness and out of genuine interest, could you elaborate on the issue(s) with CLONE_{VFORK,VM} which caused this problem, and what technical fix has been made to address the situation? |
The CLONE_VFORK issue is described here. The crux of the CLONE_VM issue is that the building blocks of a process on Windows and Linux are different: on Windows you have a process object which amongst other things is a virtual memory container, and threads that run within this process. On Linux (*note some conjecture here as we can't actually read the Linux source) there is a virtual memory object that can be assigned to processes. So on Linux, CLONE_VM makes a lot of sense: just reference the current VM object and assign it to the cloned process. On Windows however the VM object is the process, so what does it mean to share the VM space? Well, it means that you are running in the same process. So essentially what you get is a Windows thread. Conceptually this is pretty straight-forward, but all of our code was built around trying to map Linux process concepts to NT process concepts, and this did not fit into that model very well (two Linux processes mapping to one NT process). So @jstarks refactored a lot of code so that we ended up with a model where adding this additional capability was straight forward. We like to use equivalent Windows constructs whenever possible because it gives us for free all of the optimizations around scheduling, power, memory usage, etc. |
@Brian-Perkins Fantastic explanation - thanks for taking the time to elucidate! I'd assumed that you guys had GPL-licensed source in a separate module ("kernel mode driver"? I'm not sufficiently familiar with the NT kernel to know how Windows Loadable Kernel Modules work...) making use of public hooks into the kernel, rather than having to do a black-box reimplementation without having seen the Linux source, so that the result doesn't also have to be GPL-licenced 😮 |
Any chance we could get this bug fix rolled into a cumulative update to 16299? I don't like to run insider on my daily driver but would like Artful. |
Both glibc-2.25 and glibc-2.26 have received workarounds for this issue upstream: You can ask your distribution vendor to include the fix for 2.25/2.26, 2.24 doesn't need it. Debian unstable recently received glibc_2.25-3 which contains the fix as well. |
@Nathan-Harris I'm sorry, but it's not likely. The code change to fix this was substantial. Hopefully glibc's workaround can unblock you until the next Windows release. |
Is there a workaround to unblock this upgrade bug on a default (non-insider) windows? |
@pwuertz You don't need to wait for the Windows patch. Just make sure your Linux distribution has a recent enough version of glibc which handles the issue more gracefully. |
same error on ubuntu 18.04 root@Big:/home/gorgone/simplebuild/crosstool-ng# apt-get dist-upgrade INFO :: *** Running autoconf |
Please report this as a bug in Ubuntu against the glibc package. This particular issue has been addressed in glibc upstream and does no longer show in Debian which has version 2.26 with the particular patch included. Upstream fixed the issue both in the glibc 2.25 and 2.26 branches. |
You can download the newer version of |
@glaubitz the issue isn't glibc. The latest version on their mirror is 2.9 but all contain from 2.25 the fix. The problem is when we attempt to upgrade, glibc doesn't upgrade with it and is stuck on 2.23, which prevents bash from upgrading and without bash upgrading, you're unable to upgrade all your packages to the latest version in 17.10+. The latest stable version is 2.6 which is why I'm trying to install that vice 2.9. It would be nice if Ubuntu actually attempted to maintain the current stable version instead of staying with an older version on their LTS. Anything considered stable should be installed so why they won't make 2.6 available is beyond me. To further emphasize, even Kubuntu doesn't have it available and it's supposed to be ahead of Ubuntu when packages have updates and upgrades. This seems odd to me so if anybody has any pull over there to force to them to keep glibc up-to-date even on their stable version, I'm sure the entire community would be appreciative. |
@DarthSpock If you see this particular assertion failure in glibc, then, yes, it's a glibc issue. And after a quick glimpse, it seems Ubuntu doesn't carry patch to fix this issue. See again this bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=22273 If the version of glibc you are trying to install is crashing with the error message from the original bug report, your glibc is missing this patch: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=fe05e1cb6d64dba6172249c79526f1e9af8f2bfd Basically: Both Microsoft's WSL and qemu-user did not implement a variant of clone() properly which resulted in this assert() - which was introduced with glibc 2.25/2.26 - to be triggered. On real machines, this assert() did not trigger, but it triggered on WSL and qemu-user. While Microsoft has already addressed the issue in WSL in newer versions, qemu-user hasn't. Thus, if you are running on an older version of WSL or qemu-user, you must have the patch linked above. |
A temporary workaround would be to install the (patched) packages from debian sid via dpkg -i:
The |
if you're downloading from debian, then you may as well use the backport available on Ubuntu instead or you can manually download it from the Ubuntu archives and |
help! Windows (admin) PowerShell Loading personal and system profiles took 562ms. donofrio@WSAL0196 sudo apt-get update && sudo apt-get upgrade -y && sudo apt-get dist-upgrade -y && sudo apt-get autoremove -y && sudo apt-get autoclean -y && sudo sync && sudo sync |
You need to hold back bash, see reddit |
Yeah, no. It's not just bash or ebtables, or any one particular package. The fix is to upgrade to build 17134, the latest and greatest stable version. As stated above, there is an issue with 16299 and below in support CLONE_VFORK and CLONE_VM. The upgrade does work in this build. That said, if upgrading Windows isn't an option, Ubuntu 18.04 has it's own image on the Microsoft Store for download. |
I'm trying to get to is where I can do "Updates" to the system, (I do not have the store with corp 1709 image) - these days you have to keep "up-to-date" with patches and the like. What is weird is on my desktop's at work it's failing but on the work notebooks it's working. I'll provide bash versions in a few hours (I'm on iirc freenode #windows-subsystem-for-linux #ubuntu-on-windows.) |
@lewisdonofrio You sound like you just need to wait for the server install method to become available. Or you can just use https://github.com/Microsoft/WSL-DistroLauncher to compile and build the win32 (or take the extra steps to make it an appx) using the Docker image. Since Canonical hasn't released details on which image they use, this is the default image I'd go with (this would be the case for most distros) |
I've used WSL-DL and it didn't "quite do it" for me and I am using the unsquish method from #2618 with the squish file https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.tar.gz then I update/dist-upgrade then I get 201 packages to update and bang 200th package errors ;( |
Did you see nay error with |
not yet but when I did last time I just did the fix'ed script outlined in #143 (comment) |
Well this is really weird...the notebook that is working has bash 4.4.19(1) and that is the weird thing, it updates fine, no issues with things seg-faulting during updates. Now the desktops built last few of them, they try to install the (2) version and blow up the whole show...thoughts? (they were all built with same files from tinyurl.com/donofrioworkdesk (the ppt and the zipfile in downloads dir then rootfs is in downloads dir when done) |
@lewisdonofrio Can you post the output of the notebook and the desktop's WSL Ubuntu for |
Desktop at work having "issues" returns Bash 4.4.18(1)-release (older???) Linux WSAL0196 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64 x86_64 x86_64 GNU/Linux Notebook that works and I get full xfce4 updated desktop running bash 4.4.19(1)-release . |
anyone else getting weird perms for .cache directory, I have to manually do chown/chgrp -R /home/donofrio/.cache then the many dbus permission notices goes away from the console. Just figured I'd share. |
Attempting to
dist-upgrade
to Ubtuntu 17.10 fails (if bash is not marked for hold - see Issue #1878).The reason for this appears to be that the deb package's
preinst
script is actually a binary, and the behaviour is odd:Running under
gdb
gives no output:The text was updated successfully, but these errors were encountered: