「WSL」カテゴリーアーカイブ

Windows 10 Anniversary Update GAとBash On Ubuntu On Windows(長い)のインストール方法

Capture_2016_08_03_0708_008

Starting today the Windows 10 Anniversary Update will begin rolling out for our customers around the world*. The Windows 10 Anniversary Update is full of new features and innovations that bring Win…

情報源: How to get the Windows 10 Anniversary Update

日本にもやって参りました。GAっすよ。既にWindows 10インストール済みの方はWindows Updateからアップグレードできます。(よい子は事前にバックアップを取っておくように。)

既にMSDNサブスクライバダウンロードよりISOのダウンロードも可能になっています。

Bash on Ubuntu On Windowsをインストールするには、Win+Xキーでプログラムと機能を選択し、Windowsの機能の有効化または無効化を選択、下図のようにチェックを入れ、OKボタンをクリックするとインストールが始まり、終わると再起動を促されると思いますので、再起動します。

Capture_2016_08_03_0708_001

再起動したら適当なコンソールか、コマンドプロンプトを開いてbashとタイプしてC:\Windows\System32\bash.exeを起動します。

Capture_2016_08_03_0708_003

もちろんyとタイプ。
Capture_2016_08_03_0708_004

ジョジョかよっって突っ込みを入れながらインストールが終わるのを待ちます。

Capture_2016_08_03_0708_005

ユーザー名、パスワードを決めて入力します。さすがに最初の時のようにrootユーザーのまま使わせるのはやめたらしい。

Capture_2016_08_03_0708_007

これでインストール終了。

ちなみに$ su - とかしてもrootのパスワードがわからなくては入れないので、suしたいときにはsudo suとしてください。

Ubuntuとカーネル(と言ってもエミュレーション)のバージョンは以下の通り。

WSL File System Support

情報源: WSL File System Support

WSLのファイルシステム解説。

LinuxはPOSIX互換システムなのでinodeベースのファイルシステムが使われていて、VFSで実際のファイルシステムとアプリケーションAPIから見えるファイルシステムと分離する仕組みになっており、Windowsのファイルシステムとは全然違うわけです。

このため、普通にやればWSL用にベアメタル上にパーティションを作ってそこにExt3なりLinuxのファイルシステムのドライブを構築するのが一番無難なわけですが、その作業自体煩わしいですしWSLではそんな普通な事はしていないわけです。

逆に見ればVFSの仕組みを使って、アプリケーションに対してNTFSを上手くinodeベースのファイルシステムに見せかける事が出来れば、アプリケーション側でファイルシステムの違いに対応する必要がなくなります。

このため、ほぼ完全にinodeベースのLinuxファイルシステムをエミュレートするVolFsとNTFSファイルシステムのディレクトリ、ファイルをinodeベースのファイルシステムに見せかけるDrvFSが作られました。

以下内容を要約してみます。

VolFs

WSLが使用するプライマリファイルシステムがにvolfsです。 Linuxのシステムファイル、ならびにLinuxのホームディレクトリの内容を格納するために使用されます。このように、volfsはLinuxのVFSをほとんどサポートし、Linuxのパーミッション、シンボリックリンク、FIFOは、ソケット、およびデバイスファイルを含め、提供しています。

volfsは、バッキングストレージとして%LocalAppData%\lxss\rootfsを使用して、VFSルートディレクトリをマウントするために使用されます。またそれ以外にもいくつかマウントしていて、/rootとして %LocalAppData%\lxss\root をマウントし、/homeとして%LocalAppData%\lxss\homeがマウントされます。これはWSLがアンインストールされてもそれらのフォルダは削除されないので、ユーザーファイルを保護することが出来ます。

これらのすべてのポイントはストレージが、Windowsのユーザーフォルダ内のディレクトリを使用してマウントされていることに注意してください。各Windowsユーザーは、自分のWSL環境を有しているので、Linuxのルート権限を持っているし、他のWindowsユーザーに影響を与えることなく、アプリケーションをインストールすることができます。

Inodes and file objects

Windowsは全くinodeとそれに関連する概念がないので、volfsはiノードに、Windowsのファイルオブジェクトへのハンドルを保持する必要があります。 VFSがルックアップコールバックを使用してあたらしい要求をしたとき、VolFsは親inodeからのハンドルを使用して、相対的に子の名前を取得して、新しいinodeのハンドルを取得します。これらのハンドルはファイルへの読み書きのアクセス無しに開かれ、メタデータ要求に対してのみに使用されます。

Emulating Linux features

簡単にまとめるとNTFSで足りていないものはVolFsがエミュレーションするか機能を提供すると言う事です。そして、NTFSに無いファイルのメタデータはNTFSのEA(EAレコード)として保存されます。(こりゃまた懐かしいものがw)

Interoperability with Windows

volfsファイルが上記のディレクトリにWindows上で通常のファイルに格納されていますが、Windowsとの相互運用性がサポートされていません。このためWindowsのエディタから直接volfsのファイルを編集してしまうと、Windowsエディタの多くがEAをサポートしていないので、保存時にEAを削除して問題を起こしてしまいます。

DrvFs

Windowsとの相互運用性を容易にするために、WSLがDrvFsファイルシステムを使用しています。 WSLは自動的にサポートしているファイルシステムの固定ディスクを/mntの下に、/mnt/c, /mnt/d等としてマウントします。現在、NTFSとReFsがサポートされています。

DrvFs permissions

簡単にまとめると以下のようになります。

  • DrvFsではWindowsのファイルアクセス権限が使用されるよ
  • bash.exeの実行権限に依存するのでsudoしてもアクセスできない場所があるよ。UACの昇格の有る無しでアクセスできる出来ないが発生するよ。
  • アクセス権限が必ずしも1:1で対応できているわけでないよ。でも一応計算して出来るだけ対応するようにしている。

Case sensitivity

まとめると。

DrvFsはNTFSの元々の機能を使用して大文字と小文字を区別したファイルをサポートしているけど、Windowsのアプリケーションは区別できないから注意してね。ただドライブのルートでは禁止しているので必ずその下のディレクトリを作ってね。

Symbolic links

NTはシンボリックリンクをサポートしていますがWSLによって作成されたシンボリックリンクはWindowsでは意味を持たない/procのようなパスを指している可能性があるため、私たちはこのサポートに頼ることができませんでした。また、NTは、シンボリックリンクを作成するには、管理者権限が必要です。このため、我々は別の方法を見つけなければなりませんでした。

VolFsとは異なり、我々はファイルがDrvFsにシンボリックリンクであることを示すためにEAに頼ることができませんでした。その代わりに、WSLは、シンボリックリンクを実現するために新しいリパースポイントを使用しています。その結果、これらのリンクは、WSLの内側にのみ機能し、エクスプローラやcmd.exeのようなWindowsのコンポーネントから使用する事は出来ません。(ワオ!)また、ReFsではリパースポイントのサポートがないので、シンボリックリンクのサポートがないことに注意してください。NTFSでは完全にWSLのシンボリックリンクをサポートされます。

Interoperability with Windows

VolFsとは異なり、DrvFsは、任意の追加情報を格納しません。代わりに、すべてのinodeの属性が照会ファイル属性、有効なアクセス許可、およびその他の情報によって、NTで使用される情報から導出されています。 DrvFsはまた、常にWindowsプロセスは、ディレクトリの内容を変更した場合でも、正しい、最新の情報を提供し保証するために、ディレクトリエントリのキャッシュを無効にします。このように、DrvFsは彼らに動作している間、Windowsのプロセスはファイルに何ができるかに制限はありません。

DrvFsはファイルに対してWindowsのデリートセマンティクスを使用するので、ファイルが開かれている場合にはリンクを解除することが出来ません。

ProcFs and SysFs

Linuxでのように、これらの特殊なファイルシステムは、ディスク上に存在するファイルを表示するのではなく、プロセス、スレッド、およびデバイスについてのカーネルによって保持される情報を表すものではありません。読んだときにこれらのファイルは、動的に生成されます。いくつかのケースでは、ファイルの情報がlxcore.sysドライバ内部に完全に保持されます。このようなプロセスのCPU使用率などの他の例では、WSLはこの情報のためのNTカーネルを照会します。しかし、Windowsのファイルシステムとここには相互作用はありません。

まとめ

今後も改善していくのでGitHub等でフィードバックしてください。

感想

もうなんかお疲れ様でしたとしか言いようが無いwただシンボリックリンクに関してはやはりNTFSの実装が中途半端すぎた感じですね。


Announcing Windows 10 Insider Preview Build 14366 & Mobile Build 14364

Hello Windows Insiders! WOW, what a week. You all were on fire last week with the all of the feedback for the double dose of PC + Mobile. I also appreciated you sharing your career/business goals w…

情報源: Announcing Windows 10 Insider Preview Build 14366 & Mobile Build 14364

だんだんアニバーサリーのリリースが近づいてきているためか、今回は安定性向上と言った感じですね。

Bash on Ubuntu On Windowsの実行環境でGit for Windowsのbash.exeを使いたいときの注意点

バッチファイルやJenkinsからGit for Windowsのbash.exeを起動したい事が有ると思いますが、Bash on Ubuntu On Windowsが動作する環境だとsystem32\bash.exeが起動されてしまい不具合がでているような状況もあるようです。

単純に環境変数PATHの参照順の話なのですが、バッチファイルやJenkinsのスクリプト記述で以下のようにすれば回避できます。

方法1 bash.exeを全てフルパスで記述する。

すべてフルパスでbash.exeを記述してしまえば間違えようがありません。

方法2 バッチファイル(スクリプト)内で環境変数PATHを設定し直す。

ようはsystem32\bash.exeより先にGit for Windowsのbash.exeが呼び出されれば良いので、バッチファイルの先頭に以下をのようにPATHの設定を追加します。

まとめ

めんどくさいですが、以上の方法で改善できます。最初からPATHの参照順を変えてしまうのは、それはそれでBash on Ubuntu On Windowsの使い勝手が悪くなってしまうので、個人的にはおすすめしません。

Tmux support arrives for Bash on Ubuntu on Windows 

情報源: Tmux support arrives for Bash on Ubuntu on Windows | Windows Command Line Tools For Developers

build 14361のUbuntu on Windowsで XTerm Control Sequencesがサポートされたので、みんな大好きtmuxがサポートされました。apt-getでインストールすれば動作するようです。

追記:

IPのアップデート後apt-get upgradeしてしまったらupgradeであれこれエラーが出て、tmuxのインストールも出来なかったので、みなさんご注意を。。。とほほー。

エラーは出るものの、インストールは出来ていて、ちゃんと動きました。

SnapCrab_SHINANO 上の Win10IP  - 仮想マシン接続_2016-6-9_7-37-50_No-00

Huge improvements to Bash on Ubuntu on Windows in Build 14361 

情報源: Huge improvements to Bash on Ubuntu on Windows in Build 14361 | Windows Command Line Tools For Developers

今回のBuild 14361ではBash on Ubuntu on Windowsで大幅な改良がされています。SysCallの対応も追加されています。

詳細は以下のリリースノートで確認してください。

https://msdn.microsoft.com/en-us/commandline/wsl/release_notes

Pico Process Overview 

情報源: Pico Process Overview | Windows Subsystem for Linux

謎過ぎなWindows Subsystem for Linux(WSL)で使用されているPicoプロセスの解説です。

基板技術となったDeawbridgeの簡単な解説、前提となるMinimal Processの説明、それを受けてのPico Processの解説となっています。

そもそもMinimal Processって何だよって感じですが、これはユーザーのアドレス空間だけを示しているもので、本当にプロセスのガワだけといったものの事のようです。Pico ProcessはPico Providerと呼ばれるこのMinimal Processを管理するためのカーネルモードドライバに紐付けられたMinimal Processの事を指すようです。

また、Windows Kernelに対しては、やはりForkの改善が行われているほか、Pico Processのために4KBずつメモリ管理出来る様にしたり、WSL起動時はNTFS上で大文字小文字の区別が生きるように改造が行われたとマジカ!と言う内容が行われているようです。

という事で、速報的にかいつまんで書いてみました。正式な翻訳が欲しいです。


Windows Subsystem for Linux Overview

情報源: Windows Subsystem for Linux Overview

Windows Subsystem for Linuxのソフトウェアアーキテクチャに関するペーパーと解説のビデオが出てきました。

LXSS-diagram-1024x472

記事本文にもありますが、今回のWSLは従来のOS/2サブシステムやSFUのInterixのサブシステムとは全く作り方が違います。従来はNTDLL.DLLという門に守られていたWindowsのカーネルモードの壁に新しい通用口を作った感じです。

bash.exeはユーザーモードで動いているLX Session ManagerにCOM(!)で接続し、一方Ubuntuのユーザーモードは一つの大きな分離プロセスとしてユーザーモードで動作し、外側へのインターフェイスとしてinitというタスクを持っています。LX Session Managerとinitとの間はカーネルモードで動作するLXCore/LXSSを通して接続されています。そして、分離プロセスとして動作しているLinuxのインスタンスの中で動作するbashやvimなどは、Linuxのインスタンスの中のピコプロセスとしてinitにより起動されます。

このピコプロセス管理し、カーネルとして振る舞うこともLXCore/LXSSの仕事になり、Linuxのバイナリが必要とするLinuxシステムコールをWindowsのシステムコールに翻訳をします。Windowsから見るとこのlxcodre.sysとlxss.sysはデバイスドライバとして動作しています。

ファイルシステムとしてはUnixファイルシステムを再現し、Windowsアプリケーションやそのファイルとは相互互換性のないVolFsと、Linuxサブシステム上からWindowsのファイルシステムを使用するためのDriveFs(/mnt/cのやつですね)が作られたようです。

ということで、自分が理解した内容をつらつら書いてきましたが、正確な内容については情報源のところの元の記事とビデオとで参照・確認してください。

いやぁ、やはりというか思った以上にというかELFバイナリをそのまま動かすって大変ですね。やっぱすごいことしてた。UWPと分離プロセスとかWindowsコンテナのような様々な要素技術が十分そろった今だからこういうことができるようになったという感じですね。Drawbridgeの成果物としてこういうものも出てくるとは思ってもみなかったです。

あと、MSKKには是非ちゃんと翻訳してほしい。


とりあえずの答え合わせ - BASH Running in Ubuntu on Windowsについて

情報源: BASH Running in Ubuntu on Windows 現状わかってきたことをまとめてみ…

情報源: BASH Running in Ubuntu on Windowsについて

本日配布が始まったWindows 10 Insider Preview Build 14316よりLinux Subsystemが使用できるようになりました。とりあえず先週の想定が合っていたかの答え合わせをしたいと思います。今後の情報によりまた内容が変わる可能性は沢山ありますw

BASH Running in Ubuntu on Windowsで出来ること。

  • GUIの無いLinuxアプリケーションの実行。
    • OK.
  • ELF形式のバイナリファイルを直接実行できる。
    • OK.
  • ELF形式のバイナリを開発できる。
    • OK, 開発環境のインストールが必要(apt-get install build-essential)
  • Aptによるアプリケーション管理。
    • OK.
  • Windows側ファイルシステムのマウント。
    • OK, ただしWindowsファイルシステム側でln -sが動かないなど制限もある。
  • Windows側から見るとLinux(Ubuntu)のファイルシステムは通常のディレクトリ/ファイルに見える。
    • OK.

BASH Running in Ubuntu on Windowsで出来ないこと。(そう考えることが出来るもの)

  • Ubuntu側のシェルからのWindowsアプリケーションの起動、またその逆。
    • OK.
  • Ubuntu側LinuxアプリケーションとWindowsアプリケーションとのパイプ、共有メモリ等による連携。SocketやHTTPなら可能だろうけど。
    • OK.また、UWPと同様な形でWindowsアプリ側とプロセスの分離をしていると思われる。
  • X Window Systemに依存するアプリケーションの動作。これはServerだけでなくClientも動作できないと考えられる。

  • コンソールアプリケーションでもフレームバッファに直接アクセスするなどするアプリケーションの動作。
    • 今のところ不明。
  • 上二つはWindowsの制約からWindowsサブシステム以外グラフィックシステムにアクセスできない制約による。
    • 今のところ不明
  • Linuxサーバーとしての運用。(これは出来ないというよりやら無い方が良いレベルになるかも)
    • 今のところ不明

情報が増えてきたらまたアップデートします。