2020/04/21(火)Ubuntu 20.04 インストール (2)
- デスクトップのリサイズ、
- ホストOSとのクリップボード共有(文字列のコピペが出来るようになる)、
- フォルダ共有
sudo apt install open-vm-tools-desktopとしましょう。
共有フォルダは、vmwareの「設定→オプション→共有フォルダの有効化」で共有フォルダを有効にして再起動。
sudo vmhgfs-fuse -o allow_other -o auto_unmount .host:/ /mnt/hgfsで/mnt/hgfs以下にマウント出来ました。永続的にmountするには、/etc/fstabで
.host:/ /mnt/hgfs fuse.vmhgfs-fuse allow_other,auto_unmount,defaults 0 0と書くとよいでしょう。
2020/04/21(火)Ubuntu 20.04 インストール (1)
18.04以来2年ぶりのLTS (Long Time Support)で、5年間のサポート期間があります。半年毎にアップデートするのは面倒なのでLTSを愛用しています。
というわけで、20.04のインストールメモです。20.04betaを使って試しました。多分リリース版でも変わっていないと思います。betaでもとても調子がよく、また過去の例ではbetaを入れてもアップデートを繰り返していれば自然とリリース版と同等になるそうで、このまま使い続けるつもりです。
Ubuntu 20.04 LTS (Focal Fossa) Betaから、ubuntu-20.04-beta-desktop-amd64.isoをダウンロードしました。数日以内にベータでなくなるはずです。
VMwareで作業しました。新規仮想マシンの作成→標準→後でOSをインストール。仮想マシンの種類はLinux Ubuntu 64bit。ディスクはデフォルトの20Gじゃ少ないので512Gに増やしました (ここを多くしても実際に仮想マシン内で使用しない限りホストマシンのディスクを圧迫することはありません)。メモリはとりあえずデフォルトの2Gで (こちらは大きくするだけホストマシンのメモリを食います)。仮想マシンの設定でisoをマウントし起動。
- 言語は「日本語」を選び、「Ubuntuをインストール」をクリック。
- キーボードレイアウトは「Japanese」「Japanese」
- 「通常のインストール」を選ぶ。
- 「Ubuntuのインストール中にアップデートをダウンロードする」、「グラフィックスとWi-Fiハードウェアと追加のメディアフォーマットのサードパーティ製ソフトウェアをインストールする」をチェック
- 「ディスクを削除してUbuntuをインストールする」を選ぶ。
- 「インストール」をクリック。
- TimeZoneは「Tokyo」を選ぶ。
- 「ログイン時にパスワードを要求する」を選ぶ。
とりあえず端末を出すには、右下のBCGの痕みたいなアイコンをクリックして「端末」を選びます。右クリックして「お気に入りへ追加」するといいでしょう。
日本語をかな漢字変換で入力するには、インストール直後の一回だけ、右上の「ja」をクリックして、「日本語(Mozc)」を選ぶ必要があります。
(4月24日追記)
4月23日に、予定通り20.04LTSが正式にリリースされました。Ubuntu 20.04 LTS (Focal Fossa)から、ubuntu-20.04-desktop-amd64.isoをダウンロードすればいいです。このインストール日記(1)-(10)の手順を全てやり直してみましたが、Juliaのversionが1.3.0から1.4.1に変わっていた以外は特に違いはありませんでした。
なお、beta版に対して、「ソフトウェアの更新」をかけたところ、/etc/os-releaseが、
NAME="Ubuntu" VERSION="20.04 LTS (Focal Fossa)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu Focal Fossa (development branch)" VERSION_ID="20.04" HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" VERSION_CODENAME=focal UBUNTU_CODENAME=focalから、
AME="Ubuntu" VERSION="20.04 LTS (Focal Fossa)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 20.04 LTS" VERSION_ID="20.04" HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" VERSION_CODENAME=focal UBUNTU_CODENAME=focalに変わって、ちゃんとリリース版になったようです。
2019/12/20(金)nvidia-dockerインストールメモ
機械学習などでCUDAの実行環境が必要になることは多いかと思います。自分は囲碁AIを動かすのに必要となりました。ところが、環境構築がかなり複雑で、また使いたいソフトウェアによってcudaやcudnnの必要なversionが異なることも多く、苦労させられます。VMwareやVirtualBoxなどの仮想化環境を使いたくなりますが、残念ながらそれらの仮想マシンからはGPUは見えません。またWSLからもGPUは見えません。
そこで解決策の一つとして考えられるのが、nvidia-dockerです。dockerはコンテナ型の仮想環境を提供するもので、VMwareなどに比べて例えばメモリ空間を共用できるなど、とても軽いものです。nvidia-dockerはNvidiaのGPUを仮想化して共有することが出来ます。NvidiaのGPUでいろいろなソフトウェアを試したいとき、これはとても便利です。cudaやcudnnがインストールされた状態のイメージも公開されているため、それをダウンロードすればインストールの手間も省けます。元々nvidia-dockerはdockerをNvidiaのGPUを扱えるようにした改造版?でしたが、docker本家がversion 19.03でNvidia GPUに対応したため、19.03以降は普通にdockerを入れた後に追加のパッケージを入れるように変更されました。
以下、Ubuntu 18.04にnvidia-dockerをインストールしたときの様子をメモしておきます。入れたマシンは、
- msi PS42 Modern 8RC (GTX-1050 max-Q搭載モバイルノート、2019年6月に実行)
- GIGABYTE BNi7HG6-1060 (GTX-1060搭載小型デスクトップ、2019年12月に実行)
まず、Nvidia GPUのためのドライバを入れます。これだけはホストマシンに入れる必要があります。まず、
ubuntu-drivers devicesとして使用可能なドライバを検索します。ここで、GTX-1060デスクトップの方は、
== /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0 == modalias : pci:v000010DEd00001C20sv00001458sd0000D005bc03sc00i00 vendor : NVIDIA Corporation model : GP106M [GeForce GTX 1060 Mobile] driver : nvidia-driver-430 - distro non-free driver : nvidia-driver-390 - distro non-free driver : nvidia-driver-435 - distro non-free recommended driver : xserver-xorg-video-nouveau - distro free builtinのように情報が表示されました (2019年12月)。GTX-1050ノートの方は何も見えなかった(2019年6月)ので、
sudo add-apt-repository ppa:graphics-drivers/ppa sudo apt updateのようにPPAの追加が必要でした。これが、ハードの違いによるものか、実行した時期の違いによるものかは検証していません。PPA追加後は、
== /sys/devices/pci0000:00/0000:00:1c.4/0000:03:00.0 == modalias : pci:v000010DEd00001C92sv00001462sd00001245bc03sc02i00 vendor : NVIDIA Corporation driver : nvidia-driver-418 - third-party free driver : nvidia-driver-415 - third-party free driver : nvidia-driver-430 - third-party free recommended driver : nvidia-driver-410 - third-party free driver : xserver-xorg-video-nouveau - distro free builtinのように表示されるようになりました。なお、現在(2019年12月)に ubuntu-drivers devices を実行すると
== /sys/devices/pci0000:00/0000:00:1c.4/0000:03:00.0 == modalias : pci:v000010DEd00001C92sv00001462sd00001245bc03sc02i00 vendor : NVIDIA Corporation driver : nvidia-driver-410 - third-party free driver : nvidia-driver-430 - third-party free driver : nvidia-driver-415 - third-party free driver : nvidia-driver-440 - third-party free recommended driver : nvidia-driver-435 - distro non-free driver : xserver-xorg-video-nouveau - distro free builtinとなったので、実行する時期によって内容は異なるようです。これらを見て、"recommended"なドライバをインストールしました。
(GTX1050, 2019年6月)
sudo apt install nvidia-driver-430(GTX1060, 2019年12月)
sudo apt install nvidia-driver-435いったん再起動し、動作確認は、nvidia-smiを実行します。
Thu Dec 12 03:20:08 2019
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 435.21 Driver Version: 435.21 CUDA Version: 10.1 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 GeForce GTX 1060 Off | 00000000:01:00.0 On | N/A |
| N/A 47C P8 4W / N/A | 254MiB / 6075MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| 0 1082 G /usr/lib/xorg/Xorg 18MiB |
| 0 1132 G /usr/bin/gnome-shell 48MiB |
| 0 1393 G /usr/lib/xorg/Xorg 114MiB |
| 0 1527 G /usr/bin/gnome-shell 69MiB |
+-----------------------------------------------------------------------------+
のように表示されれば正常に動作しています。次に、dockerをインストールします。19.03以降でないとnvidia-docker化はできないので、本家から最新のものを入れます。ほぼ本家のページに従いました。
sudo apt update sudo apt install apt-transport-https ca-certificates curl gnupg-agent software-properties-common curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - sudo apt-key fingerprint 0EBFCD88 sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" sudo apt update sudo apt install docker-ce docker-ce-cli containerd.io動作確認は、
sudo docker run hello-worldとして、
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
1b930d010525: Pull complete
Digest: sha256:4fe721ccc2e8dc7362278a29dc660d833570ec2682f4e4194f4ee23e415e1064
Status: Downloaded newer image for hello-world:latest
Hello from Docker!
This message shows that your installation appears to be working correctly.
To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
(amd64)
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.
To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash
Share images, automate workflows, and more with a free Docker ID:
https://hub.docker.com/
For more examples and ideas, visit:
https://docs.docker.com/get-started/
のようなメッセージが表示されれば成功です。次に、nvidia-docker化を行います。これも、本家のページの通りです。
distribution=$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list sudo apt update sudo apt install -y nvidia-container-toolkit sudo systemctl restart docker動作確認は、コンテナの中でnvidia-smiを実行してみましょう。
sudo docker run --gpus all --rm nvidia/cuda nvidia-smiとして、
Unable to find image 'nvidia/cuda:latest' locally
latest: Pulling from nvidia/cuda
7ddbc47eeb70: Pull complete
c1bbdc448b72: Pull complete
8c3b70e39044: Pull complete
45d437916d57: Pull complete
d8f1569ddae6: Pull complete
85386706b020: Pull complete
ee9b457b77d0: Pull complete
be4f3343ecd3: Pull complete
30b4effda4fd: Pull complete
Digest: sha256:31e2a1ca7b0e1f678fb1dd0c985b4223273f7c0f3dbde60053b371e2a1aee2cd
Status: Downloaded newer image for nvidia/cuda:latest
Wed Dec 11 18:34:37 2019
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 435.21 Driver Version: 435.21 CUDA Version: 10.1 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 GeForce GTX 1060 Off | 00000000:01:00.0 On | N/A |
| N/A 38C P8 4W / N/A | 253MiB / 6075MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
+-----------------------------------------------------------------------------+
のようにcuda入りイメージのダウンロード後、コンテナの中でnvidia-smiが実行できたら成功です。なお、このように"--gpus all"を付ければnvidia-dockerとして、付けなければただのdockerとして振る舞うようです。ご参考になれば幸いです。
後はおまけ。dockerの使い方はまるで分かってなくて適当に検索しながら使ってるので、備忘録として。
- sudoなしでdockerを使うには、sudo usermod -aG docker (自分のユーザ名) として再起動。
- dockerの使い方参考ページ1 CentOS 7のDockerでコンテナの作成と基本的な操作を行ってみる
- dockerの使い方参考ページ2 Docker ハンズオン - 基本コマンド編
docker run -dit --gpus all --name katago nvidia/cuda:10.1-cudnn7-develのようにしてコンテナをバックグラウンドで立ち上げ、
docker exec -it katago bashとしてその中に入って作業を行いました。Dockerfileとかを使わない、ダメな使い方だと思いますが、これで十分役に立っています。
2018/05/01(火)ubuntu 18.04 インストール (リンク集)
- ubuntu 18.04 インストール(1)
- ubuntu 18.04 インストール(2) vmware tools
- ubuntu 18.04 インストール(3) TeX関連
- ubuntu 18.04 インストール(4) vim
- ubuntu 18.04 インストール(5) プログラミング系あれこれ
- ubuntu 18.04 インストール(6) apache,php
- ubuntu 18.04 インストール(7) samba
- ubuntu 18.04 インストール(8) マルチメディア系
- ubuntu 18.04 インストール(9) その他
- ubuntu 18.04 インストール(10) リモートデスクトップ
学生が研究のために環境を整えるなら、とりあえず(1),(3),(5),(9)を見ればいいかな。
2018/05/01(火)ubuntu 18.04 インストール(10) リモートデスクトップ
リモートのubuntuに何かさせたいとき、普通は単にsshで、GUIなアプリを使いたければssh -Xで済みますが、稀にデスクトップ全体を転送したいことがあります。それを実現するものとしては、windowsのリモートデスクトップとVNCが有名ですが、素のwindowsで使えるし速度も速いのでリモートデスクトップを愛用しています。
ところで、unityを採用していた最近のubuntuは、リモートデスクトップやVNCのサーバの設定がとても難しいことが知られています。代わりに標準で「画面共有」という機能があるのですが(プロトコルはVNC)、これは本体にログインしている状態でしか使えず、ログアウトしてしまうとリモートからログイン出来ないというとても不便なものです。
ubuntuは18.04になるとき、Xサーバを17.10で導入されたWaylandからXorgに戻したそうで、これはVNCやxrdpとの相性を考えてのことだそうです。また、unityからgnomeに戻った、更にパッケージのxrdpのバージョンが最新になった、ということもあり、xrdpが簡単に使えるようになったのではないかと期待していました。
しかし、いろいろ試したところあまり上手くは行かず、それでも何とかしてみた、というのが以下の記録です。
基本的に、
の記事に従ってやってみました。
sudo apt install xrdpこれで、サーバそのものは簡単に入ります。カーソル回りに不具合があるらしく、/etc/xrdp/xrdp.iniで、
new_cursors=true を、 new_cursors=false に書き換える sudo systemctl restart xrdpが必要です。
上のサイトによれば、~/.xsessionrc に、
export GNOME_SHELL_SESSION_MODE=ubuntu export XDG_CURRENT_DESKTOP=ubuntu:GNOME export XDG_DATA_DIRS=/usr/share/ubuntu:/usr/local/share:/usr/share:/var/lib/snapd/desktop export XDG_CONFIG_DIRS=/etc/xdg/xdg-ubuntu:/etc/xdgと書くとgnomeが使えるとのこと。しかし、試してみると、本体でログアウトしておかないと使えないことが分かりました(少なくともうちの環境では)。本体使用中に接続しようとしてもすぐに画面が消えてしまいます。クライアントAで使っている時にクライアントBから接続すると、Aの画面が閉じてBで続きができる、という、windowsに似た動作になります。また、どこかのクライアントで使用中のときは、本体でログイン出来なくなってしまいます。
これでは不便なので、16.04のときと同じく、「MATE」を使う作戦を試してみました。MATEは、「メイト」ではなく「マテ」と読み、gnome2の操作性で軽く、見た目を重視しているということで最近人気があるデスクトップ環境です。
sudo apt install ubuntu-mate-desktopインストール中、display managerをgdm3とlightdmのどちらにするか聞かれましたが、とりあえずMATEの標準と思われるlightdmにしました (gdm3でどうなるかは未確認)。再起動し、本体の方でログイン時に「MATE」と「Ubuntu(デフォルト)」(gnome)が切り替えられ、どちらでも正常に使えることを確認しました。
まず、/etc/xrdp/startwm.sh を書き換えて、最後の2行のXsessionを起動している場所の前に
exec mate-session (これを挿入) test -x /etc/X11/Xsession && exec /etc/X11/Xsession (これは元から) exec /bin/sh /etc/X11/Xsession (これは元から)のようにMATEの起動コードを挿入します。これで一応動きましたが、起動時に「Could not acquire name on session bus」と変なウインドウが出てしまいます。これは、mate-sessionの起動前に
unset DBUS_SESSION_BUS_ADDRESSを挿入したら直りました。
16.04のときと違ってキーボードは正常に使えます(xrdpが新しいおかげ)。かな漢字変換は作動しないので、16.04のときに倣ってmate-session起動前に
export GTK_IM_MODULE=ibus export QT_IM_MODULE=ibus export XMODIFIERS="@im=ibus" ibus-daemon -dを挿入したらうまく動きました。
なお、xrdp接続するとthinclient_drivesというフォルダがホームにでき、接続が切れるとこれがアクセスできないフォルダになってlsの度に警告が出て大変鬱陶しいです。一応ホームで
sudo umount thinclient_drivesとすれば直りますが、面倒です。これを何とかしようと、/etc/xrdp/sesman.iniで、
FuseMountName=thinclient_drives を、 FuseMountName=.thinclient_drives に変更 sudo systemctl restart xrdpとして見えなくしました。
18.04でのxrdpに対する期待とは裏腹にかなり面倒なことになってしまいましたが、一つの例として記録を残しました。もう少し賢い方法がありそうな気もするので、少し様子見ですかね。