[^ arch]: I don't know because I'm not familiar with Arch Linux, but like looking at the repository February It feels like glibc is up to 2.31

Specifically, this will happen

** Cannot upgrade from Ubuntu 18.04 **

In the first place, do-release-upgrade -d is moss on the way and cannot be upgraded. Ubuntu 18.04 LTS in my environment was said to be sudo apt upgrade and ʻE: Unmet dependencies. Try'apt --fix-broken install' with no packages (or specify a solution) .` [^ a].

[^ a]: I leave the English environment. The reason is unknown

So sudo apt --fix-broken install and ...

sleep: cannot read realtime clock: Invalid argument
dpkg: error processing package libc6:amd64 (--configure):
 installed libc6:amd64 package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 libc6:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

I get an error. This sleep: cannot read realtime clock: Invalid argument indicates that the problem in the example occurred. By the way, in Japanese, it seems that real time clock cannot be read: invalid argument.

rustup cannot install the toolchain

To build a Rust environment (on UNIX-like), just paste curl --proto'= https' --tlsv1.2 -sSf https://sh.rustup.rs | sh into the shell.

info: profile set to 'default'
info: default host triple is x86_64-unknown-linux-gnu
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: latest update on 2020-04-23, rust version 1.43.0 (4fb7144ed 2020-04-20)
info: downloading component 'cargo'
info: downloading component 'clippy'
info: downloading component 'rust-docs'
info: downloading component 'rust-std'
info: downloading component 'rustc'
info: downloading component 'rustfmt'
info: installing component 'cargo'
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `22`,
 right: `4`', src/libstd/sys/unix/thread.rs:166:21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `22`,
 right: `4`', src/libstd/sys/unix/thread.rs:166:21
stack backtrace:

What do you mean?

There are already issues on the rust-lang side (rust-lang / rustup # 2245: rustup panic with WSLv1 + glibc 2.31, # 2293).

As far as I confirmed the above. Homebrew also gives an error, but the installation proceeds normally.

Coping

Ubuntu 20.04 and WSL 1 - Ubuntu Community Hub

For WSL 1 users, I recommend you sit tight on Ubuntu 18.04 for now. The patch for issue 4989 will take some time to be backported. Ubuntu 18.04 is an LTS release, short for long-term servicing, and is supported through 2023 so you will continue to get security patches and backports from Canonical in the meantime.

WSL1 users are advised to stay on Ubuntu 18.04. Until the patch to issue 4989 is backported to Typo. *, Probably microsoft / WSL # 4898 It will take a while. Ubuntu 18.04 is LTS, or Long-Term Servicing, where you can receive security patches and backports from Canonical until 2023.

In summary, ** wait on Ubuntu 18.04 for a patch to fix the problem **.

Avoid Ubuntu 20.04

When you introduce Ubuntu from now on ...

For those who want to install WSL1 and install Ubuntu now, install the app "Ubuntu 18.04 LTS" do it. On the other hand, install 20.04 for the visible land mine called "Ubuntu 20.04 LTS" and the app that is difficult to understand but simply says "Ubuntu". It ends up. 16.04 disappeared before I knew it.

When I'm using Ubuntu now ...

If you already have Ubuntu 19.10 or lower, just wait. It seems that updates will be sent to the "Ubuntu" and "Ubuntu 18.04" apps from time to time, but this is not related to the upgrade of Ubuntu itself, so you can rest assured. On the contrary, if you execute do-release-upgrade in the Ubuntu shell, the upgrade will start, so be careful.

Wait for a patch to WSL1

With the words "until the patch is backported"? You might have thought, but according to Microsoft's comment, the fix is coming and the backport is It seems that it is under consideration.

Comment that Windows Insider Fast Ring 19608.1006 resolves, but [Windows Insider Preview Announcement](https:: //blogs.windows.com/windowsexperience/2020/04/15/announcing-windows-10-insider-preview-build-19608/) doesn't mention it in particular, and this problem goes back to the build around February. There was no talk that it was resolved. Should it be seen as a silent fix?

Introduce WSL2

2020-05-28 Addendum: The next version of Windows 10 with ** WSL 2 ** ** May 2020 Update ** [^ win] has been released. WSL2 uses a serious Linux kernel, so this problem does not occur. Can you google for more details?

Since WSL1 also has one advantage, there are no plans to abolish it, and in fact, a patch has been issued for WSL1 in this way. I wonder if I could have come up with a name that feels more equal than the one-ordered name.

[^ win]: The version number is 2004, the version number under development is 20H1, and the build number is 19041.207. as known as too much

Other methods

-Insert the modified version (2.31-0ubuntu8 + lp1871129 ~ 1) of glibc 2.31 published in ppa: rafaeldtinoco / lp1871129 ([ppa: rafaeldtinoco / lp1871129] US number 612622828) -Put a symbolic link on Busybox sleep --sudo apt-mark hold use to fix the version

Is also proposed.

On Arch Linux, it seems to be downgrade you can use the command to downgrade.

Ubuntu 20.04 is sleeping next to me

To those who are too late [^ teokure] to have performed the upgrade.

For the time being, mv and cp should be usable if you are not doing strange things, so ** I think it is better to save the necessary data to the Windows side (/ mnt / c) **. I had the necessary data on the Windows side in the first place, so I put it on the laboratory table and did various things.

[^ teokure]: About the author

# 4898 comment number 611583534 describes how to deal with it. … But when I tried it, Ubuntu was completely dead [^ rip] so I can't really trust it. As for the comment itself,: thumbs up: is 3 and: thumbsdown: is 7, and after that, the comment “as soon as I did that, my WSL broke completely” has arrived, so it feels like hmm.

As a result of repeated experiments, Ubuntu has become like this when I try to start it. As a result of googled properly, it seems to be SIGSEGV (segmentation violation). It's hard.

[^ rip]: I'm stupid, so I'm not sure if it's because I tried the method of commenting after that or because of this guy.

How did this happen

** Because glibc 2.31 now uses system calls that don't support WSL1 with sleep **.

In the first place, WSL1 played a role in translating and mediating for the Windows NT kernel that software running on Linux requested "use this feature of the Linux kernel". It's like installing an English automatic translator on a Japanese person to accommodate foreign customers. The English ability of the translator is inferior to that of native speakers, so if you say something you don't know, you can't translate it. WSL2, on the other hand, carries the entire Linux kernel. In other words, it feels like the native English brain is attached to the Japanese. Since it is native English (Linux kernel), it can be understood even by words that the translator does not know (system calls that are not implemented in WSL1). Since the body is moved directly by the native brain, the response is quick. Instead, it wastes energy (heavy movement).

This issue probably became widespread after glibc upgraded to 2.31 on Ubuntu 20.04, but it seems that Arch Linux had already had the issue since it was upgraded in February (reference: [yuk7 / ArchWSL #]. 108](https://github.com/yuk7/ArchWSL/issues/108), 02/12, [Causes and remedies when CPU usage does not decrease with VS Code (WSL1) --Qiita](https: // qiita.com/RShirohara/items/727feb89c63cdd0d1f62), 03/03). Since ArchWSL is not in the Microsoft Store, I first learned about its existence, but I thought it was amazing that the author was Japanese and 19 years old (impression of elementary school students).

Then, I want to know the cause a little more, so I will bring the posted earlier again.

Issue 4989

An example of the WSL team continuing to service WSL 1 for now is a patch for issue 4989. Issue 4989 arises from a patch in glibc 2.31 that implements a nanosleep() library call in a more UNIX-like manner based on CLOCK_REALTIME. Emulating UNIX system clocks on an NT kernel is tricky. WSL 1 implemented the most popular clock-based system calls, but not all of them, and did not build CLOCK_REALTIME support into nanosleep. But because this is such a fundamental change in glibc the WSL team is very graciously implementing support for CLOCK_REALTIME in nanosleep in WSL 1 and will be backporting it in updates to existing builds. This is a challenging task that will take some time. In contrast, other more obscure system clock calls, like the one raised in issue 4973, will likely not see implementation in WSL 1.

Translated,

This issue is due to glibc 2.31 now calling the nanosleep () library in a more UNIX-like way using CLOCK_REALTIME. Emulating a UNIX system clock on a Windows NT kernel is hard. WSL implements the most common clock-based system calls, but not all, and nanosleep doesn't include support for CLOCK_REALTIME. But since this is a radical change to glibc, thankfully the WSL team has implemented support for CLOCK_REALTIME in nanosleep, which will be updated to existing builds as well. This is challenging and time consuming. On the other hand, other less popular system clock calls, such as those mentioned in # 4973, will probably not be implemented in WSL1.

I'm not familiar with Linux so I don't know at all, but CLOCK_REALTIME seems to be one of the flags when getting the time. (?) According to this article, there are multiple types of flags, and it seems that WSL1 does not support CLOCK_REALTIME in the first place. microsoft / WSL # 2503 is an issue that was set up in September 2017 that CLOCK_REALTIME fails with ʻEINVAL` in WSL. "Isn't it okay to postpone the emulation implementation of the clock system?" At that time, it was left unimplemented, but it seems that this is called by the update on the glibc side.

Dig the glibc side

According to Comments on microsoft / WSL # 4898, the code has been added to /posix/nanosleep.c on glibc. Seems to be the cause. The commit is here. It's a commitment on November 06, 2019, so it's just halfway between 2.30 in August and 2.31 in February 2020. Looking at the description text, it seems that I always called it with CLOCK_REALTIME for GNU Hurd.

Summary

――WSL2 is good. maybe ――I don't know Linux, I mean, I knew for the first time that GNU was doing / bin / sleep. --I want to use ArchWSL --I didn't expect to see the Hurd name in such a place ――It's interesting and educational to see that everyone is searching for solutions.