テクニカルプア

備忘録と若干の補足

systemd 239.0 で machinectl list-images の標準出力をパイプやリダイレクトで処理させようとすると assert して止まる

という事象がある。 これについては github.com で issue をつくった。 内容を追っていると assert() している箇所を消せば終わりな気がしたので github.com でプルリクもつくった。

先程プルリクを master にマージして頂いたのを記念して記事を書いている。 なお本件のワークアラウンドとしては /var/lib/machines/ 下をみてよしなにする以外の方法を思いついていない。

プルリクの中で

  • 英語がずさんすぎる
  • テスト書いてない
  • レビュアーさんを急かす

ということをしていてだいぶひどいことになってしまった事をここで謝罪致します。

systemd 239.0 で machinectl import-(raw|tar) を使うと結果が返ってこない事象の迂回策

TL; DR

systemd-importを使うとよい。 /usr/lib/systemd/ 下にあるのでパスが通っていない場合は絶対パスで頑張る。

systemd のバージョン

Arch Linux を使っています:

$ systemctl --version
systemd 239
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN +PCRE2 default-hierarchy=hybrid

$ machinectl --version
systemd 239
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN +PCRE2 default-hierarchy=hybrid

$ pacman -Qs systemd
local/libsystemd 239.0-2
    systemd client libraries
local/systemd 239.0-2 (base-devel)
    system and service manager

内容

systemd 239.0 になってから machinectl のサブコマンドである import-rawimport-tar とで nspawn 用イメージのインポートができなくなった様子。

具体的にはインポートしたいイメージをこしらえてから machinectl import-rawmachinectl import-tar を実行しても transfer を enqueue したというメッセージ以降でコマンドが応答しなくなる(以下 import-raw を取りあげるが import-tar でも同じだった):

# machinectl import-raw RAW_IMAGE
Enqueued transfer job 1. Press C-c to continue download in background.

コマンドとしては何も返さないが、machinectl list-transfers をみるとイメージのインポートについての進捗が得られる:

$ machinectl list-transfers
ID PERCENT TYPE       LOCAL    REMOTE
 1     31% import-raw RAW_IMAGE

1 transfers listed.

しかし list-transfers が下記のようになり、machinectl list-images でインポートしたイメージが見れるようになっても import-raw はプロンプトを戻してくれず、ダンマリを決めこんでしまう。

$ machinectl list-transfers
No transfers.

いろいろあって

https://www.freedesktop.org/software/systemd/man/systemd-importd.service.html によれば machinectlimport-(raw|tar) は systemd-importd の実装を借りているとのこと。

これを踏まえて import-raw 中に systemctl status systemd-importd を眺めていてみつけた /usr/lib/systemd/systemd-import を使ってみたところ、インポートの進捗がコマンドの応答として得られ、インポート完了後もプロンプトを返してくれた:

# /usr/lib/systemd/systemd-import raw RAW_IMAGE
Importing 'RAW_IMAGE', saving as 'RAW_IMAGE'.
Imported 0%.
Imported 1%.
Imported 2%.
Imported 3%.
Imported 4%.
...
Imported 99%.
Operation completed successfully.
Exiting.
#

いまのところ systemd-import を使うので特に問題なさそうなので、しばらくはこれでいこうと思う。

追記

issue あげた。勘違いとかでないとよいのだが。コメント欄の通り修正された。ご対応ありがとうございます。

machinectl: import-raw and import-tar not show progress / not respond · Issue #9527 · systemd/systemd · GitHub

pacman 5.1.0 の makepkg でのパッケージビルドが operation not permitted でコケる場合のワークアラウンド

pacman が 5.1.0 になった。 しかしながらこれに付属する makepkg でパッケージをビルドしようとすると、 /etc/makepkg.confBUILDDIR に指定しているディレクトリによっては Operation not permitted となってコケる場合がある。 事象としては https://bugs.archlinux.org/task/58790 のとおりで、すでにバグとして報告されているの為そのうち修正ないし対策はされると思う。

ところでいつ対応されるかわからん状況をただ待っているのはつらいという向きもあると思う。 わたしもその質である。 そんな中いろいろやっていたらワークアラウンドをみつけたので書いておくことにした。

内容は単純で /etc/makepkg.confBUILDDIR で設定しているディレクトリを makepkg する時に使用するユーザが所有するものに変更すればよい。 例えばログインユーザが hogehogefuga というグループに所属する場合、所有ユーザ及びグループが hoge:fugaディレクトリを BUILDDIR へ指定してやる。

わたしは普段 tmpfs としてマウントしている /ramdisk 内に scratch/ というディレクトリを tmpfiles で勝手に作られるようにし、/ramdisk/scratch//etc/makepkg.confBUILDDIR に設定している。 こいつは root:root0777ディレクトリであるため、今回の事象に引っかかってしまった。

今回のワークアラウンドでは /ramdisk/scratch/nosada/ というディレクトリを新たに作成して適当なユーザ及びグループに所有させるように tmpfiles へ設定を追加し、これを BUIILDDIR に設定するようにした。 これで pacman 5.1.0 の makepkg でもパッケージがいつもどおりビルドされるようになり、不安が解消されるに至った。

めでたし。

GPD Pocket 買った

f:id:aaodsn:20180422230204j:plain
映り込みが激しい……。ノングレアな液晶フィルムが欲しい

確か去年秋の OSC Tokyo だと思うのだが、実際に動いている GPD Pocket を少し触らせてもらい、これはいつか欲しいなと思った。 月日が経ちそんな記憶も薄れたところで先々週くらいに偶然中古 PC 屋さんで GPD Pocket が売られているのを見付けてしまい、そういえばこんなものもあったなあと懐しみを覚えたのちに物欲がふつふつと沸いてきたのだった。

で、買った。

Windows 版を買ったのだがわたしは Windows を使えないので Arch Linux をいれている。先人の蓄積をありがたく流用し、GPD Pocket 固有の問題ではとくに躓くことなく Arch のインストールができた。

ちいさい鞄に適当に入るそれなりのパソコンが手に入ったのでとても満足度が高い。携帯電話を持ちあるくような気軽さでパソコンが持ち運べるのはとても嬉しい。

nspawn コンテナのなかで X なアプリケーションを動かす

追記:

当初の記事ではコンテナ内 qutebrowser を起動させるときに systemd-nspawn -M CONTAINER という感じのコマンドを使用していたが、これはコンテナが登録済み(machinectl list に使用したコンテナが表示される状態)では上手く動かないことがわかった。

環境変数を直打ちしないといけない面倒さはあるが machinectl shell で同様のことができるようなので、本文中は machinectl コマンドに差しかえしている。

動機

人生オワタの大冒険 みたいな Flash ゲームをたまにやりたくなる。 が、2018年にもなって手元の PC に Flash を入れたくはない。

いままでは LiveUSB かなにかで起動した GUIFlash をいれて凌いでいたが、ゲームやるためだけに PC 起動しなおすみたいなのはしたくない。

なんとかしたいなと思いチマチマ調べたり手を動かしていたものがやっとできるようになったので書く。

加えて昨今はコンテナ内で X なアプリケーションを動かすことが流行っているような印象があったので、流行にのれそうなチャンスを活かしたいという気持ちもあった。

やったこと

個人的な事情で make するときに reflector が必要。まずこれをインストールする:

# pacman -S reflector

そのあと mkosi-files/guispawn at master · nosada/mkosi-files · GitHub を手元にもってきて

# make
# make install

したあと

$ xhost +local:
$ machinectl start guispawn
$ machinectl shell -E DISPLAY=:0 -E XAUTHORITY=~/.Xauthority -E 
PULSE_SERVER=unix:/run/user/host/pulse/native gui@guispawn /usr/bin/qutebrowser

すれば Flash の動く qutebrowser があがってくる。 この qutebrowser は nspawnコンテナのなかで動くので、Flash 関連の諸々がホストに入ることもない。

ブラウザに qutebrowser を使っているのは筆者が qutebrowser のファンであるため。

nspawn へ与える設定

[Exec]
Environment=DISPLAY=:0
Environment=XAUTHORITY=~/.Xauthority
Environment=PULSE_SERVER=unix:/run/user/host/pulse/native
PrivateUsers=true
NotifyReady=true

[Files]
BindReadOnly=/tmp/.X11-unix/
BindReadOnly=/etc/resolv.conf
Bind=/run/user/1000/pulse:/run/user/host/pulse
Bind=/dev/snd
Bind=/dev/shm

[Network]
# Private=yes
# VirtualEthernet=yes

Network セクションは好みにあわせて変更する。

こんな設定を /etc/systemd/nspawn/ 下に コンテナ名.nspawn で作成してコンテナを作れば、コンテナ内で X が使え、それをホストから参照できるようになる様子。

備考

人生オワタの大冒険は tanasinn の倒しかたがわからず進捗していない。

参考

ThinkPad X201s 買った(2枚目)

秋葉原を歩いてたらジャンクの X201s が他のジャンクな PC と一緒に棚へ詰め込まれていたので買った。

液晶割れあり、メモリおよびディスク無し、外装割れなくも汚ない、割合きれいな US キー付き、タッチパッドありで6000円也。型番は 5129CTO。 画面割れは残念だけれど*1 US キーつきでこの値段はお買い得だったと思う。

持ち帰ってから細部を確認したところ AC アダプタのジャックや USB ポートなどの状態がだいぶ前に買っていまだ現役の X201sよりも良いことが判明した。部品単位で引き剥すのが面倒臭いのと下半身の外装が綺麗なのとを鑑みて旧来の X201s とニコイチにすることにした。いまこの記事はニコイチにしたあとの X201s で書いている。

2018年にもなってまだ X201s を使い続けているとは正直以外だった。 とっくの昔に ThinkPad に見切りをつけて他の機械を使っていると思っていたし気持ちとしては今もそうなのだが、結果として今も X201s を使い続けている。 あたらしい機械を買おうとしてもどうも食指が動かず結局 X201s を使いつづけてしまう。 最近はちょっと諦めの境地に逹しつつあり、X201s でダメになる日が来るまでは X201s を使い続けようと思うようになった。

*1:意地でも X201s を使う理由って 1440 x 900 な画面だからだとおもう

近況

放置しすぎて広告が出てしまうようになったので書く。
それぞれ別個の記事にしてもよいのではと思うのだが、いかんせんネタを膨らませるに至らなかったので纏めて書く。

SKK 導入

mozc の更新がもう一年以上止まってるよねという話があちらこちらで目に入るようになったので、そういえばそうだなあと思い移行先を考えた結果として SKK を選ぶに至った。
下記のようにしておわり(普段 Fcitx を使っている為こうなっている):

$ sudo pacman -Rscnu fcitx-mozc-ut
$ sudo pacman -S fcitx-skk skk-jisyo skktools

設定や辞書の追加みたいなやつは kcm-fcitx などが入っていれば systemsettings から適当に出来る。

SKK 自体のお作法に不慣れな部分もまだかなり有るが、一通りの文章を書けるようにはなった。
この記事も SKK で書いている。

「おみくじ」や「う゛ぁーじょん」などを変換して遊んでいた時分が懐かしい。

pacaur から aurutils への乗り換え

pacaur が2017年12月15日を以って更新を停止したようなので、移行先を探さねばなあと思いいろいろ探し回っていた。
以前使っていた yaourt へ戻るのでもまあ良かったのだが、せっかくなので bauerpill や auracle 等いろいろ試して回った結果として aurutils を選んだ:

$ sudo pacman -Rscnu pacaur cower
$ sudo pacman -S pacutils
$ git clone https://aur.archlinux.org/aurutils.git
$ cd aurutils/
$ makepkg -sri

aurutils を使用する場合 pacaur とは異なり AUR のパッケージを別レポジトリとして管理しなくてはならないようなので、そのあたりの設定もあわせて実施した。
このあたりは aurutils の man が詳しい*1

pacaur とは異なり操作内容によりコマンドが分離しているので慣れるまでは取っつきづらいと感じたが、これはまあ時間が解決してくれるだろうとは思っている。
pacaur で特にトラブルが無ければそのまま pacaur を使用し続けたと思うので、悲しいことに全てが pacaur の比較になってしまう……。

*1:man をよく読まなかった結果つまったのでここで恥を晒しておく。 man に従えば /etc/pacman.d/ 下にレポジトリを定義する設定ファイルを作り、それを /etc/pacman.conf で Include する。このとき /etc/pacman.d/ 下に置く設定ファイルと /etc/pacman.conf 内の記載とで同一セクション名でレポジトリを設定するとエラーとなってしまう。 要は /etc/pacman.d/ 下でレポジトリを定義してそいつを単に /etc/pacman.conf で読み込ませればよい。 私はこれを勘違いして結構悩んだ。