z80oolong さんはインスタンス qiitadon.com のユーザーです。アカウントさえ持っていればフォローしたり会話したりできます。 もしお持ちでないなら こちら からサインアップできます。

z80oolong @z80oolong@qiitadon.com

## proot 案件

Linux において、 root 権限を取る事なく chroot を実現するソフトである [proot][2] の [Debian noroot 環境対応版][4]について、 [Termux の開発コミュニティによる proot のソースコード][3]が最新の commit に更新された事に伴い、[最新の commit に追随した Debian noroot 環境対応の proot の安定版][1]をリリースした。

このリリースに伴い、 proot の Debian noroot 環境対応版の安定版の実行ファイルについても、再度コンパイルを行っている。

[1]:github.com/z80oolong/proot-ter
[2]:github.com/proot-me/PRoot
[3]:github.com/termux/proot
[4]:github.com/z80oolong/proot-ter

# 現在の技術案件の近況

## tmux 案件

端末多重化ソフトである [tmux の EAW 文字対応差分ファイル][1]について、 [koie 氏][2]による[ファイル tty-acs.c 内の配列 tty_acs_table のリファクタリング][3]の pull request を先行的に取り込んだ。

すると、 koie 氏より [tmux の画面分割において、罫線の文字を適切に判別・描画する修正][4]を頂いたので、修正の上で当方の差分ファイルに merge した。

本件について、 tmux の差分ファイルの作成に多大な協力を頂いた koie 氏に心より御礼申し上げます。

[1]:github.com/z80oolong/tmux-eaw-
[2]:github.com/koie
[3]:github.com/tmux/tmux/pull/1907
[4]:github.com/koie/tmux/commit/ac

## ASUS Vivo Tab 8 案件 (2)

前節で述べた問題の原因を踏まえ、 ASUS Vivo Tab 8 に搭載された Windows OS より、 Bluetooth に関するファームウェアを取り出し、ファイル名を BCM43341B0.hcd に変更した上で、 Ubuntu 上のディレクトリ /lib/firmware/brcm 以下に置き、タブレットの再起動を行った。

しかし、上記の通り Bluetooth 用のファームウェアの導入を行った所、 Ubuntu の設定画面より Bluetooth が有効化出来ない問題が発生し、本件の問題が解決されなかった。

本件の問題については、現在も調査中である。

なお、タブレットに搭載された Windows OS より取り出した Bluetooth 用ファームウェアについては、 [Github リポジトリ Asus-T100/firmware][1] から取得出来るファームウェアと同一のバイナリであることが判った。

[1]:github.com/Asus-T100/firmware

# 現在の技術案件の近況

## ASUS Vivo Tab 8 案件 (1)

夏季休暇時に Windows 搭載タブレット ASUS Vivo Tab 8 を入手し、これに Ubuntu 18.04.2 及び最新の Linux カーネルを導入した。

タブレットへの Ubuntu の導入に関しては、概ね問題無く行われたが、以下の機能が正常に動作しない事が確認された。

- タブレット内蔵の Bluetooth に関する機能
- タブレット内蔵の音声出力機能
- タブレット内蔵のカメラに関する機能

この内、 Bluetooth に関する機能について調査した所、以下に示すログファイル /var/log/syslog の内容より、 Bluetooth において使用するファームウェアである BCM43341B0.hcd が、 Ubuntu 上に導入されていない事が原因と考えられた。

...
Bluetooth: hci0: BCM: Patch brcm/BCM43341B0.hcd not found
...

## /etc/fstab の記述

以下の記述が正当。

...(略)...
UUID=<UUID of ext4> /mnt/expand ext4 rw,error=remount-ro 0 1
/mnt/expand/home /home none bind 0 0
/mnt/expand/var /var none bind 0 0
...(略)...

# 御詫びと訂正

先程投稿した ["現在の技術案件の近況"][1]において、一部記述に誤りがありました。以下の通り訂正すると共に、ここに謹んで御詫び致します。

## "/home, /var ディレクトリの移設について" の第1段落

- (誤) ここで、 GPD MicroPC に Wubi 経由で導入した Ubuntu 19.04 環境は、そのルートパーティションを EFI システムパーティションを含む C ドライブ上に導入した。
- (正) ここで、 GPD MicroPC に Wubi 経由で導入した Ubuntu 19.04 環境は、そのルートパーティションを EFI システムパーティションを含むストレージデバイス上に存在する C ドライブ上に導入した。

[1]:qiitadon.com/@z80oolong/102462

### /etc/fstab の設定

以下に、前述したファイルシステムのマウントに関する設定ファイルである /etc/fstab に追記する設定について記述する。

ここに、 <UUID of ext4> は、増設 microSD 上に作成した ext4 ファイルシステムの UUID を、 /mnt/expand は、増設 microSD 上に作成したファイルシステムのマウント先のディレクトリを示す。

...(略)...
UUID=<UUID of ext4> /mnt/expand ext4 error=remount-ro,rw 0 1
/mnt/expand/home /home none bind 0 0
/mnt/expand/var /var none bind 0 0
...(略)...

以上の設定により、増設 microSD のマウントが可能となった。

### /home, /var ディレクトリの移動手法

以下、 GPD MicroPC 上の Ubuntu 19.04 環境の /home, /var ディレクトリ以下の内容を増設した microSD の領域に移動する手法は以下の通りである。

- 先ず、増設した microSD 上にパーティションを切り、 ext4 ファイルシステムを作成する。今回は、増設 microSD の領域全体で1個のパーティションと ext4 ファイルシステムを作成した。
- 次に、 GPD MicroPC 上の Ubuntu 19.04 環境をリカバリモードで起動して、増設 microSD 上に作成した ext4 領域を適当なディレクトリにマウントする。
- そして、 /home, /var ディレクトリの内容を増設 microSD 領域に移動した後、移動先のディレクトリを mount --bind ... を用いてルートディレクトリ上の /home, /var ディレクトリにバインドする。
- その後、設定ファイル /etc/fstab の末尾に後述で示す記述を追記する。

# 現在の技術案件の近況

## GPD MicroPC 案件

### LXDE 環境の導入について

先日、 Ubuntu 19.04 を Wubi 経由で導入した GPD MicroPC 環境について、通常使用するデスクトップ環境について検討していたが、この度、軽量な環境軽量なデスクトップ環境である LXDE の導入を行った。

LXDE については、従来より使用していた環境であり、また使い慣れた環境であるので非常に快適である。

### /home, /var ディレクトリの移設について

ここで、 GPD MicroPC に Wubi 経由で導入した Ubuntu 19.04 環境は、そのルートパーティションを EFI システムパーティションを含む C ドライブ上に導入した。

この為、Ubuntu 19.04 のルートパーティションの容量が現時点では 64GB 程度しか無く、今後大量のソフトウェア及びデータを格納する際は非常に不便を強いられる事が予想された。

そこで、 /home, /var ディレクトリ以下の内容を増設した microSD に移動する事を検討した。

## proot 案件

現在、 Debian noroot 環境に導入する Ubuntu 19.04 環境の動作確認等を行っているが、 Debian noroot 環境下における proot において 20 byte 程度のパス名の socket を作成した際に、 invalid argument - connect(2) socket のメッセージを表示して異常終了する問題について調査した。

その結果:

- proot は、 -r オプションで指定したルートディレクトリのパス長と作成する Socket のパス長の合計が 108 byte を超えた場合は、 PROOT_TMPDIR 以下にパス長を 17 byte に短縮した代替の Socket を生成する。
- ここで proot が Android OS の増設メモリで動作している場合、ルートディレクトリのパス長は 80 byte となり、 PROOT_TMPDIR をルートディレクトリ以下に設定していると、 20 byte 前後で Socket の最大パス長を越えて異常終了する。

なる原因が判明した。

# 現在の技術案件の近況

## GPD MicroPC 案件

先週末に、漸く予約購入していた GPD MicroPC が自宅に届いたので、早速 Ubuntu 19.04 を導入した。導入に当たっては、 @kapper1224 氏によるブログを参照した。導入の際に各種気付いた点及び備忘録等に関する tweet を纏めたものを Twitter のモーメント及び [togetter の纏め][1]にて投稿した。

現時点で確認された問題点としては:

- 導入可能なディストリビューションは Ubuntu 19.04 に限られている。その他の Xubuntu 等の導入は成功しなかった。
- 現状では、 GPD MicroPC の無線 LAN の動作が若干ながら不安定である。
- Wubi による導入では増設メモリへの導入に失敗する場合がある。

現在は、 GPD MicroPC 上の Ubuntu 19.04 には、軽量デスクトップ環境である LXDE を導入し、自宅で使用していた環境を移行している所である。

[1]:togetter.com/li/1374467

### その3

- 最後に、 MATE デスクトップ環境を起動するスクリプトを起動すると、 XSDL サーバに MATE 環境が描画されるので、適切に画面表示及び日本語入出力の設定を行う。

以上の作業により、以下の画像の様な MATE デスクトップ環境が得られた。

なお、以上の環境は現時点では試作の環境であり、今後試作の環境が置かれている ubuntu ディレクトリ以下のファイル群を tarball で固めて、 Debian noroot 環境に移動・展開して、本格的な動作確認を行う予定である。

また、試作環境の段階において、現時点では、以下の問題点が判っている。

- dbus daemon の動作について、 /var/run/dbus/dbus_system_socket に関する動作が不安定である。
- /var/run/dbus ディレクトリが存在しない場合は、当然に上記ソケットの作成に失敗し、 MATEデスクトップの設定の一部が起動しない問題が発生し、上記ディレクトリが存在する場合でも上記ソケットの通信に不具合が発生する場合がある。

### その2

- 以上で作成したスクリプトが正常に起動すると、 CLI ベースの Ubuntu 環境が起動するので、その後以下の様にして MATE デスクトップ環境と日本語環境等を導入した。
```
$ apt-get install mate-desktop-envronment plank fcitx-mosc
```
その他、必要に応じてパッケージを導入した。
- この時、幾つかのパッケージについて設定及び依存解決の失敗が発生するので、以下の様に原因のファイルの削除と設定の再実行を行った。
```
$ rm /var/lib/dpkg/info/udisk.postinst
$ rm /var/lib/dpkg/info/libfprint0:armhf.postinst
$ dpkg --configure -a
```
- 次に、前述した Debian noroot 環境の動作原理を元に MATE デスクトップ環境を起動するスクリプトを記述した。
- そして、上記のスクリプトの起動前に、 XSDL サーバを起動しておく。

# 現在の技術案件の近況

## Debian noroot 環境案件

### その1

ここ最近は、 Debian noroot 環境に導入する為の Ubuntu 19.04 環境の作成を行っていた。基本的には、以下の手順で作業を進めた。

なお、以下の作業は Terminal Emulator の内部ストレージ領域に ubuntu なるディレクトリを作成して行った。

- 先ず Ubuntu 19.04 環境は、[canonical.com で配布されている tarball][1] をベースとした。
- 上記の tarball を前述したディレクトリに展開し、同じディレクトリに proot 等を置いた。
- そして、[Debian noroot 環境の動作原理][2]に基づいて proot を起動するスクリプトを記述した。

[1]:partner-images.canonical.com/c
[2]:qiita.com/z80oolong/items/4ef1

## Termux 版 proot 案件

さて、最新版の Termux の開発コミュニティによる proot では、 proot jail 環境内での chroot システムコールの実装が強化された。

そこで、 Termux において Ubuntu 19.04 を動作させる為の Ubuntu の tarball を Debian noroot 環境内で展開し、 [Ubuntu 19.04 の chroot jail 環境の作成について実験を行い、 tweet にて言及した。][1]

chroot jail 環境の作成自体は成功したものの、 mount システムコールの未実装や proot のオプションを通したディレクトリのバインドが chroot jail 環境から見る事が出来ない等幾つか問題があった。

しかしながら、概ねこの環境は動作しているので、 Debian noroot 環境上に Ubuntu 19.04 の導入を今後検討している所である。

[1]:twitter.com/z80oolong/status/1

# 現在の技術案件の近況

先々週から今週までの技術案件の進捗等について述べる。

## Debian noroot 環境案件

先日頃より、 Debian noroot 環境において、 proot コマンドに --root-id オプションを付与する事により、 proot の fake_id0 機能を有効にして起動している。

これにより、 apt-get コマンドにより、標準的な SSH サーバである OpenSSH を導入して起動させる事に成功した。

即ち、以下の様に OpenSSH を導入し、 /etc/ssh/sshd_config ファイルを "[Debian noroot 環境において OpenSSH に基づく SSH サーバを導入する][1]" で述べた通りに設定した所、正常に SSH サーバが起動した事が判った。

$ apt-get install openssh-server

[1]:z80oolong.qrunch.io/entries/YI