VirtualBox 6.0.14のdkmsがLinux kernel 5.4の仕様変更でbuildできない (VBox 6.1で対応)

*** update ***

2020-01-21更新: Linux kernel 5.4.13 (1/21現在5.4.x系列の最新版)を試している。既にVBox側で対応済みなため、特に問題なくkernel modulesをbuild、使用できている。

*** updateここまで ***


Linux kernel 5.4からset_pages_x()とset_pages_nx()というfunctionsが削除された。

Debian unstableに入っているVirtualBox 6.0.14はこの変更に対応しておらず、現状ではkernel moduleがbuildできずにerrorになる。

VBoxのdevelopersは既に対応するpatchを作製済みで、6.1RC1としてreleaseしている (cf. [#18945 (Linux 5.4: no more arbitrary executable pages and more changes) – Oracle VM VirtualBox](https://www.virtualbox.org/ticket/18945))。

何れDebian unstableかexperimentalに入るだろう。 2020-01-21現在sidに6.1が入っている。

Linux kernel 5.4 seriesにはi915でgpu resetがtimeoutしてin-flight renderingが止まる問題もあるので、当面は5.3で運用する予定。 2020-01-21現在、5.4.13で特に問題がなさそうなのでこのまま移行できそう。

Linux kernel 5.4.1でgpu resetがtimeoutしてXの画面が止まる (1/22: 5.4.13でも発生 → 1/24: 5.5-rc7で解決か)

*** update ***

2020-01-21追記: 5.3系列がEOLっぽいので5.4.13を試してみているが、rebootから2hrsぐらい経過して特に問題なく使えている。少なくとも"Resetting rcs0"は出ていない。

2020-01-22追記: 気付いたら止まっていた……5.5-rc7をテスト中。

2020-01-24追記: 2日以上安定して使えているので5.5-rc7に移行する。

*** updateここまで ***


5.3.10の時点で既に出ていた症状だが、5.4.1にversionが上がって改善されるかなと思いきや、freezeしたまま延々とerror messageがsyslogに吐かれている状況で寧ろ悪化している？

syslogに残っていたerror messagesはこんな感じ (この時のkernelは5.4.0):

Dec  1 00:00:06 kernel: i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
Dec  1 00:00:08 kernel: i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
Dec  1 00:00:10 kernel: i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
Dec  1 00:00:12 kernel: i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
Dec  1 00:00:14 kernel: i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
Dec  1 00:00:16 kernel: i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
Dec  1 00:00:18 kernel: i915 0000:00:02.0: GPU recovery timed out, cancelling all in-flight rendering.
Dec  1 00:00:18 kernel: i915 0000:00:02.0: Resetting chip for hang on rcs0

中途半端に止まったり (resetによって)動いたりを繰り返すよりは、いっそ止まって使えないというはっきりした状態の方がマシという考え方もあるが。

5.4.0では普通に使えているので取り敢えず様子見。
5.4.0でも止まったので、5.3.14に戻して暫く使ってみる。Debian unstableのVirtualBox (6.0.14-dsfg-3)だとkernelの仕様変更で5.4に対応できていないのもあるので。

(12/4追記) 5.3.14でも時々画面のrenderingが止まるが、数秒後に回復する。その時のsyslog:

Dec  4 03:16:10 kernel: i915 0000:00:02.0: Resetting rcs0 for hang on rcs0

resetが掛かった後5.3だと復帰するけど、5.4では復帰できずにin-flight renderingが停止する。5.4で変更された中に何かあるようだ。

Apple iOS 12.4.2へupgrade

Apple iPad mini 2などに向けてiOS 12.4.2がreleaseされた。

内容はsecurity update。

設定 → 一般 → ソフトウェア・アップデート → 自動アップデート が「オン」になっていれば、自動的に適用されるはず。

Apple iOS 12.4.1へupgrade

手持ちのiPad mini2では、今日9/1の夜あたりに自動でupgradeされる予定だったが、今すぐ更新のボタンを押した。

軽く使ってみた感じ特に不具合には遭遇していない。

yascrollがemacsの仕様変更で動かなくなったので修正してみた

yascrollが動かなくなっていることに今頃気付いた。

試しに M-x yascroll:show-scroll-bar を実行してみると:

Wrong number of arguments: (left-width right-width outside-margins), 4

なるerror messageが返って来る。どうやらEmacs側の仕様変更があった模様。

git logで調べてみるとこれだった:

commit 8e0ebb9a3cb9beef2f5ff50436fef1c54a3e3c92
Author: Martin Rudalics <rudalics@gmx.at>
Date:   Mon Jul 22 09:19:18 2019 +0200
    Handle persistence of windows' scroll bar and fringes settings (Bug#36193)

src/window.cに含まれるwindow-fringesというCで書かれたfunctionは、これまで指定された (Emacsにおける) windowのleft-widgh, right-width, outside-marginsの3つのparametersを返していた。

このcommitで加えられた変更により、新たに4つ目のpersistentというparameterが追加された。これがyascrollの側でparametersの数が合わないというerrorの原因となっていた。

なお、window-fringesの詳細はEmacsからF1 helpで参照できる:

window-fringes is a built-in function in ‘C source code’.
(window-fringes &optional WINDOW)
  Probably introduced at or before Emacs version 22.1.
  This function does not change global state, including the match data.
Return fringe settings for specified WINDOW.
WINDOW must be a live window and defaults to the selected one.
Value is a list of the form (LEFT-WIDTH RIGHT-WIDTH OUTSIDE-MARGINS
PERSISTENT), see ‘set-window-fringes’.

さて、実際にerrorを起こしていたのはyascroll.el内に定義されたyascroll:choose-scroll-barである:

(defun yascroll:choose-scroll-bar ()
  (when (memq window-system yascroll:enabled-window-systems)
    (cl-destructuring-bind (left-width right-width outside-margins)
        (window-fringes)
      (cl-loop for scroll-bar in (yascroll:listify yascroll:scroll-bar)
               if (or (eq scroll-bar 'text-area)
                      (and (eq scroll-bar 'left-fringe)
                           (> left-width 0))
                      (and (eq scroll-bar 'right-fringe)
                           (> right-width 0)))
               return scroll-bar))))

left-width, right-width, outside-marginesの3つがcl-destructuring-bindに指定されているため、新たに4つ目のpersistentを返すようになったwindow-fringesと不整合を起こした。

解決方法は簡単で、

(cl-destructuring-bind (left-width right-width outside-margins persistent)

のように適当な名前のvariableを追加すれば良い (なお、このvariableは使われない)。

fileを修正したら、M-x byte-recompile-fileなどでyascroll.elcを再生成し、el-get-reload (他お好みのpackage management systemの作法)でyascrollをreloadする。

Debian sidのchromium (76.0.3809.87-1)でextensionが使えない

*** 2019-08-04更新 ***

* chromium 76.0.3809.87-2で修正されたことを確認した。

*** 更新ここまで ***


Debian BTSに同様の報告が既に上がっている。

何れ修正されたversionがuploadされるだろうが、workaroundとしてはdowngradeすれば直るとのこと。

cf. [#933598 - Most extensions now crash upon browser start - Debian Bug report logs](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933598)

yaskkservがgeneral protection faultで死ぬのでlocal dictionaryに移行した

yaskkserv (1.1.0-2+b1)が以下のような感じで死んで使いものにならないので、Emacsのddskk側にlocal dictionaryを持たせてそこから変換することにした。

% dmesg
...
[ 6720.501847] yaskkserv_hairy[24540]: segfault at ffffffff65c2a470 ip 0000557bd2ec4550 sp 00007ffc5c73ac38 error 5 in yaskkserv_hairy[557bd2ec3000+11000]
[ 6720.501852] Code: 41 8b 7c 24 10 49 8b 5c 24 08 99 f7 ff 48 63 d2 4c 8b 34 d3 4d 85 f6 0f 84 7c 02 00 00 85 ff 0f 84 74 02 00 00 45 85 c0 74 46 <41> 0f b6 06 45 8d 68 fe 41 bb 01 00 00 00 49 83 c5 02 84 c0 0f 84
[ 6731.709864] traps: yaskkserv_hairy[24640] general protection fault ip:560bc7400550  sp:7ffc61b6d098 error:0 in yaskkserv_hairy[560bc73ff000+11000]
[ 6742.007321] traps: yaskkserv_hairy[24729] general protection fault ip:5633f951d550 sp:7ffd18e31568 error:0 in yaskkserv_hairy[5633f951c000+11000]
[ 6780.822601] traps: yaskkserv_hairy[24917] general protection fault ip:55eed261a550 sp:7fffa84c1108 error:0 in yaskkserv_hairy[55eed2619000+11000]
[ 6784.167264] traps: yaskkserv_hairy[25045] general protection fault ip:561fa6e21550 sp:7ffd698daa68 error:0 in yaskkserv_hairy[561fa6e20000+11000]
[ 6787.968865] traps: yaskkserv_hairy[25093] general protection fault ip:557eda003550 sp:7ffe8633b038 error:0 in yaskkserv_hairy[557eda002000+11000]

...

移行先の候補

* yaskkserv以外のskkserver → 未だにuim-skkを使っているので利点もあるが今回はパス

* EmacsのDDSKKにdictionaryを持たせる → 今回採用

yaskkservを使っていた一番の理由が複数の辞書を指定できることだった。SKKの辞書には一般的な使用に適するL辞書 (SKK-JISYO.L)の他にも、複数の専門的な辞書が存在していて、それを一括して指定できるのが便利だった。

ただし、他の辞書を1つしか指定できないskkserverであっても、複数に分割されている辞書を統合して1つの辞書にしてしまえば機能的に何ら変わらない。辞書を操作するためのツールであるskkdic-expr2を用いて作業する。

skkdic-exprとskkdic-expr2の違いは:

* 動作が高速 (expr2)

* skkdic-sortが必要ない (expr2)

* annotationに対応している (expr2)

など。

cf. [辞書メンテナンスツール - SKK辞書Wiki](http://openlab.ring.gr.jp/skk/wiki/wiki.cgi?page=%BC%AD%BD%F1%A5%E1%A5%F3%A5%C6%A5%CA%A5%F3%A5%B9%A5%C4%A1%BC%A5%EB)

作業例

統合辞書の作製

必要なdictionaries (eg. /usr/share/skk/以下にあるものとか)を'+' operatorで結合する。個人的に旧仮名の北極三號も結合している。

% skkdic-expr2 dic1 + dic2 + ... + dicn

このあたりは一度適当なscriptに記述しておくと後は一発で同じ作業できるようになって面倒事が減る。bashとかzshの機能とかをうまく使って柔軟性の高いscriptを書けるのだろうが怠いのでabsolute pathを決め打ちした。

/etc/default/yaskkservの記述を参考にして取り込む辞書を決めてabsolute pathでリスト (というか空白で要素を区切った文字列)に記述し、bashの機能で空白' 'を' + 'に変換するという雑な方法でskkdic-expr2に与えている。

dic_list="\

/path/to/skk/dic1 \

/path/to/skk/dic2 \

...

/path/to/skk/dicn"

↓ ${dic_list// / + } # 文字列内のすべての' 'を' + 'にreplace

/path/to/skk/dic1 + /path/to/skk/dic2 + ... + /path/to/skk/dicn

なお、SKKの辞書はDebianならskkdicやskkdic-extraあたりに収録されていて、/usr/share/skk/以下に展開される。他にもCVS repositoryから引っ張って来ることもできるが、その場合はcvs update -dPしてmake allしないと辞書が生成されない (或いは最新版にupdateされない)ので注意。

使っているRuby scriptが想定しているversionが古いため、nitemsというobsoleteなmethod (Ruby 1.9で廃止)が使われていたりした。これはcount {|item| !item.nil?| }というRuby 1.9移行の等価な（？）記述に変更すれば動くようになる。

cf. [nitems (Array) - Rubyリファレンス](https://ref.xaio.jp/ruby/classes/array/nitems)

作製した辞書を使うための設定

Emacsの設定ではSKKのdictioaryのcharacter encodingをUTF-8にしている (defaultではEUC-JP)ので、nkfを使って結合済みのdictionary (SKK-JISYO.my)をUTF-8に変換する。

% nkf -w -Lu SKK-JISYO.my > SKK-JISYO.my.utf8

~/.skkの記述を変更してskkserverではなくlocal dictionaryを直接読み込む設定に変更。Dictionaryのcharacter encodingをUTF-8に指定するのも忘れずに。

(setq skk-large-jisyo "/path/to/SKK-JISYO.my.utf8")

(setq skk-jisyo-code 'utf-8)

M-x skk-restartを実行して設定を最新の状態に更新する。

*scratch* bufferあたりで適当に変換して期待する動作が行われることを確認して終了。

UIMなどimput methodにSKKを用いている場合は、それぞれのtoolbarとかから設定できるはず。UIMの場合はuim-pref-gtk3とかがあるのでそこから辞書サーバではなくてlocalの辞書fileを指定する。

これで設定が反映されれば良いが、されない場合は既存のprocess(es)を皆殺しにするか、Xのsessionをrestartすれば多分反映される。

Debianで暗号化したroot fsを読めなくなりunbootableになった

Linux kernel 5.2.3のreleaseに伴ったupgradeを実施してrebootした所、LUKSで暗号化したroot filesystemが読めず (passphraseを尋ねてくるpromptも出ず)にunbootableに陥った。

原因は、dependencyの関連でcryptsetup-initramfsというpackageがuninstallされ、その後にregenerateされた/boot/initrd.imgにcryptsetup関連のbinaryが含まれなくなったことだった。

症状と対策

* Linux kernelがloadされboot processは進行するが、暗号化されたroot filesystemが開けずにretryを繰り返して何れgive upする
* 前回別のmachineでGRUB2関連のトラブルを経験していたので、GRUB2 (今回はx86_64-efi)を入れ直したのだが↑と同じ症状でbootできず
* 以前のkernel (v5.1.15)からbootできることに気付き、kernel optionなどの変更によるものかと疑いはじめる。また、他のinitrd.imgと比較した所、bootできないinitrd.imgは1MBほどsizeが小さくなっていると気付き、ここに問題が潜んでいると推定
* 通常の方法では中に含まれているものが見えないので、lsinitramfsという専用のprogramで中身を検めた所、cryptsetup関連のprogramなどが含まれていないと判明
* 最終的にcryptsetup-initramfsというpackageがuninstallされていたことに気付いて再びinstallし、initrd.imgをregenerate (update-initramfs)して解決した

蛇足

根本的な理由に辿り着くまで非常に時間が掛かったのだが、それは以下の要因のため。

* 数日前に別のmachine (Linux box)でGRUB2関連のトラブルに遭遇していた。今回もそれに類似する、或いは見た目は違っていても根本に同じ問題があるのではないかと推定し (結果的に外れていた)、そちらの問題の解消のため作業に取り掛かった

* 前回のmachineと今回のmachineでは使っているGRUB2の種類が違っており、作業に慣れていなかった。前回はDOS形式のdiskにi386-pc方式でMBRにGRUBをinstallしていたが、今回はGPT形式のdiskにx86_64-efi方式でEFI領域にGRUBをinstallしていた

* LVMの扱いに習熟していなかった

参照したwebsites

* [mount: unknown file system type LVM2_member | SvennD](https://www.svennd.be/mount-unknown-filesystem-type-lvm2_member/)
* [Recovering from an unbootable Ubuntu encrypted LVM root partition](https://feeding.cloud.geek.nz/posts/recovering-from-unbootable-ubuntu-encrypted-lvm-root-partition/)
* [GRUB - ArchWiki](https://wiki.archlinux.jp/index.php/GRUB#GUID_Partition_Table_.28GPT.29_.E7.89.B9.E6.9C.89.E3.81.AE.E6.89.8B.E9.A0.86)

Apple iOS 12.4がreleaseされた

手持ちのiPad mini 2にてupgradeを実施。今の所は特に問題なく使えている。

WWDC 2019で発表されたiOS 13 iPadOSでは、残念ながらiPad mini 2が対象外となりそうだが。

Debian sid (unstable)でgrub2がおかしくなりunbootableになったのを修正した

Linux kernel 5.2.1がreleaseされたのでいつも通りにcustom kernelをbuildしてupdateした所、grub2 (bootloader)の設定がどこかの時点でおかしくなっていたらしくunbootableとなった。

色々と調べつつDebian liveからGRUB2を入れ直して復旧できたので手順を記録しておく。

症状と原因

...
symbol `grub_file_filters' not found
grub rescue>

lsすると(hd0,msdos1)みたいなのが表示される。環境依存だが、今回は(hd0,msdos1)が/dev/sda1で/bootに割り当ててあるpartition。

insmod normal.mod
を実行するとsymbol not foundが出る。insmod normal.modできないとnormalになれずbootもできない、と。

どうやらupgradeしたgrub2のpackageそのものか、grub2のinstallation processに問題があったようだ。

rebootのlogとaptitudeによるupgradeのlog

* grub2関連packagesがupgradeされたのは7/10 (2.02+dfsg1-20 → 2.04-1)
* それ以降のrebootは今回 (7/18)が初めてだった (`last reboot`で調べられる)

復旧の用意

正常に稼働するmachineでDebian liveのUSB flash memoryを作製する。今回は別のLinux boxを利用した。

Debian liveのUSB用imageをdownloadする

速度や負荷の面からrikenやjaistなど日本国内のmirror siteを使うと良いだろう。今回はrikenからdebian-live-10.0.0-amd64-standard.isoをdownloadした。GUIは不要との判断からstandardを選択したが、好みでXfceなどのdesktop environmentのflavorsも使える。

standardだとDEがないのでfilesizeが小さい、USB flash memoryへの書き込みが速く終わる、起動が速い、などの利点がある（ように思う）。boot後は自動loginですぐconsoleが使えるようになるので面倒がない点も良い。

USB flash memoryに書き込み

書き込み先のUSB flash memoryは/dev/sdbとして認識したが環境依存。危険なcommandなので必ず書き込み先を確認する。あとblocksize (bs)は適当なので最適値かどうかは不明。

% sudo dd if=debian-live-10.0.0-amd64-standard.iso of=/dev/sdb bs=10M

復旧の手順

ここから復旧対象のmachineでの作業。

BIOS/UEFIのmenuからboot deviceの順序を変更する

USB flash memoryを最優先にする。BIOS/UEFIによって様々だが、一通り眺めればわかるだろう。今時のUEFIだとどんなdevice(s)が接続されているかも表示されることが多いと思う。

Debian liveから起動

USB flash memoryからbootするとmenuが表示される。Installではなく、Debian liveを選ぶ。standardだとconsoleに自動loginなので面倒がなくて良い。

なお、Debian liveでは（次回のsessionには保存されないが）必要なDebian packagesを後付けでinstallできる。defaultではLUKSやGRUB2のpackagesが入っていないので、これを導入する。

packageを導入するにはまずnetworkをどうにかする必要がある。ここも環境依存なのだが、今回復旧対象のmachineはstaticにIPv4 addressを割り当てているのでip commandで関連の設定を行う。

IPv4 addressの割り当て

対象のnetwork interfaceはenp0s****として認識された。環境依存。

% ip addr show # どんなnetwork interface(s)があるか、どんなaddressが割り当てられているか
% sudo ip addr del 169.254.13.127/16 dev enp0s**** # 不要なaddress (多分autoで設定されているやつ)を削除しておく。不要だとは思うが念のため
% sudo ip addr add 192.168.11.2/24 dev enp0s**** # 普段machineに割り当てているaddressをassignする

routingの設定

このままだと外に出て行けないのでdefault gatewayを設定する。今回使うrouterのaddressは192.168.11.1。

% ip route show # 現在のrouting tableの確認
% sudo ip route add default via 192.168.11.1 # routerのaddressをdefault gatewayに指定

nameserverの設定

まだdomain nameのresolveができないのでnameserverを指定する。今回はdefault gatewayと同じaddress。

% sudoedit /etc/resolv.conf

> nameserver 192.168.11.1

aptのmirrorを設定

ここまででnetwork installが使えるようになったので、日本国内のmirror serverを設定する。今回はftp.jp.debian.orgを指定した。

% sudoedit /etc/apt/sources.list

> ftp.jp.debian.org

必要なDebian packageのinstallation (#1 LUKS)

前述の通り、Debian liveにはLUKSもGRUB2もdefaultでは入っていないので、別途installする必要がある。networkを設定したので導入可能な状態。

まずはcryptsetupを導入する。grub2は後で別にinstallする。

% sudo apt-get update
% sudo apt-get install cryptsetup

cryptsetupでLUKSの領域をmount

復旧対象machineのSSDは/dev/sdaとして認識されていて、/dev/sda1が/boot、/dev/sda5がroot (LUKSでencrypted)。

% sudo cryptsetup luksOpen /dev/sda5 secured_root # "secured_root"は何でも良いので適当な名前をつける
% sudo mount /dev/mapper/secured_root /mnt # ↑で適当に付けた名前が/dev/mapper/以下に現われるのでそれをmountする
% sudo mount /dev/sda1 /mnt/boot # LUKSで暗号化されたroot partitionに本来の (現在は壊れているので復旧対象の)/bootをmountする

必要なDebian packageのinstallation (#2 GRUB2)

% sudo apt-get install grub2

installationの最中に、grubの設定に関するgraphical menuが出るがcancel。

GRUB2をSSDへinstallし直す

あくまで対象はSSD (/dev/sda)であって、USB flash memoryではないことに注意。

% sudo grub-install --root-directory=/mnt /dev/sda

再起動してUSB flash memoryを引き抜く

% sudo shutdown -r now

reboot後、本来のGRUB menuが出れば復旧完了。

必要に応じて変更したBIOS/UEFIの設定（boot deviceの優先順位)を元に戻す。

参照したwebsites

* [Linux Set Up Routing with ip Command - nixCraft](https://www.cyberciti.biz/faq/howto-linux-configuring-default-route-with-ipcommand/)
* [grub rescueでnormal.modがnot foundですとか言われた話 - ひびっちぇ どっとこむ](http://hibitche.hatenablog.jp/entry/2015/07/17/012051)
* [WM×LI: grub rescue が表示されても慌てずに．](http://nort-wmli.blogspot.com/2013/06/grub-rescue.html)
* [#931896 - grub-efi-amd64: symbol `grub_file_filters` not found - Debian Bug report logs](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931896)

SwissMicros DM15Lのfirmware update (V29)

SwissMicros DM15Lのfirmware (V29)がreleaseされていたのでupdateした。

いつも通り、Linux boxからlpc21ipcを用いた。

firmware updateの手順については以前の記事で触れているので必要に応じて参照されたい。

cf. https://typeinf-memo.blogspot.com/2016/07/swissmicros-dm-15lfirmware-upgrade.html

SwissMicros DM42のfirmware update (DMCP v3.14)

SwissMicros DM42のfirmware (DMCP)のv3.14がreleaseされていたのでupgradeした。

今回はDM42のinternal storageのFAT領域にDMCP v3.14のfileをuploadして、DM42のmenuからupgradeを試みた (7/8)。

なおDMCPのみなので、upgradeが終了してDM42をresetするとDMCP menuで立ち上がって、そのままでは計算機として使えない状態となる。別途DM42-3.14.pgmをdownloadしてFAT areaのrootにinstallした後、DMCP menuのload programから実行する必要がある。

7/18現在ではfirmwareのdownload pageより、DMCP_flash_3.14_DM42-3.14.binをdownloadしてupgradeする方が楽だろう。

cf.

* [Index of /dm42/firmware](https://www.swissmicros.com/dm42/firmware/)

Raspbianで/lib/modules以下のfilesがdisk容量を喰っていた

概要

* Raspbianで/lib/modules以下が肥大していた
* 不要なfilesの削除で8GB → 230MBにダイエット成功
* rpi-updateを頻繁にする人は気をつけよう

本編

Raspberry Pi 3 model Bで32GB (≒29.8GiB)のUSB flash memoryを使っているのだが、妙に使用量が多い気がしていた。DE (GNOMEとかKDEとか)をinstallしている訳でもないのに、30GiBのおおよそ半分程度が消費されている。

経験則に過ぎないが、Debian系distributionをCLI環境のみでinstallした場合は2〜3GB程度が良い所だ。そこにちょっと容量を食うdevelopment関連のpackageとか、gitのrepositoryのcloneとかを入れても5〜6GBぐらいだろう。

最初はBME280で取っているlogが消費しているのかとも思っていたのだが、それらをNASに移動しても容量にほぼ変化がなかった。

% sudo du -hc . | sort -h
...
8.0G /lib/modules
8.1G /lib
13G /
13G total

プログラム開発の格言に「何処で時間を消費しているのか計測しないうちから最適化するな」という意味合いの言葉があるけど正にその通り。思い込みって怖いな。

さて、/lib/modules以下に何があるのか？

% ls /lib/modules
...
drwxr-xr-x 3 root root 4.0K May 18 20:54 4.19.42+/
drwxr-xr-x 3 root root 4.0K May 18 20:54 4.19.42-v7+/

とまぁ、こんな感じで過去から現在最新版に至るまでのkernel modulesを収めたdirectoriesがある。古いのは4.9.Xとか4.14.Xなんてのがずらりと並んでいた。

1つのversionに対応するpairで100MiBちょっとあるので、うっかり消し忘れていると膨大な領域が消費され続ける (今回は8Gぐらいだったので、80弱のversionが残っていたようだ)。

なお、最新版と1つ前 (念のため)だけ残して全てrmした後は:

% du -hc /lib/modules
...
229M /lib/modules
229M total

全体で見ても:

% df -h
...
/dev/root        29G  4.5G   23G  17% /
...

rpi-updateでよくupgradeを行う方は注意されたい。

grepでnull character (\x00)を検索する

Raspberry Pi 3で気温・湿度・気圧センサからのデータを記録しているCSVに時折null byteが混じってCSV readerがerrorを吐くので、それを効率的に発見するために調べてみた。せめてPythonのCSV moduleが行番号とか知らせてくれれば良いのに……。

% grep -Pa '\x00' FILE

Optionsの解説:

* -P → patternをPCRE (Perl compatible regular expression)として解釈する

* -a → 指定されたfileをtext fileと見做して処理する

CSV fileが大きいためか-a optionなしだとbinary fileとして該当部分を表示してくれないことがある。

参考にしたURI

cf. [linux - Find files with non-printing characters (null bytes) - Stack Overflow](https://stackoverflow.com/questions/54131197/find-files-with-non-printing-characters-null-bytes)

パスコードでロックされたiPad mini 2をfirmware等の入れ直しで復旧する

これは何？

パスコードロックされた状態のiPad mini 2 (以下、iPad)を、idevicerestoreというtoolで初期化し、Windows 10のiTunesを使ってiOS 12.2にupdate後、新しいApple IDと紐付けた時の記録。

動機と目的

iPad mini 2を譲り受けた。先方で本体内データは削除済みとのことで早速自分のApple IDに紐付けしようとしたが、パスコードを要求されてしまった。先方と相談しながら思い当たるパスコードを入力したのだが結局分からず、最終的に「このiPadは使用不可能」な状態 (=パスコードロック)に陥る。

色々調べてみると、idevicerestoreというtoolでLinux boxからfirmwareなどを書き込んで強制的に初期化＆パスコードロック解除できる (勿論内部のデータは消える)と分かったので試してみた。

用意するもの

* Apple iPad mini 2
* USB-A to Lightning cable
* Linux box (w/ Debian GNU/Linux) ※idevicerestoreを利用するためのmachine
* Windows box (w/ Microsoft Windows 10) ※iTunesを利用するためのmachine

手順

idevicerestoreのinstall

Linux boxにidevicerestoreをinstallする

* libusb-devやlibimobiledevice-*あたりをinstallしておく
* idevicerestoreがdependしているlibirecoveryをinstall
* idevicerestoreをinstall

iPadの強制再起動

* Linux boxにiPadを接続する
* iPadをホームボタン＋スリープボタン同時長押しで強制再起動する

idevicerestoreでiPadにfirmwareを書き込む

* sudo idevicerestore -l -n ※iPadを認識するかを確認する
* sudo idevicerestore -l -x ※basebandをupdateしない (-x)

iTunesでiPadのiOSをupdateする

iPad単独でもiOSをupdateできるはず、もしくはiTunesでなくてもupdateできるらしいが今回は試していないので割愛。

* Windows 10 machineにApple iTunesをinstallする
* iTunesを立ち上げる
* iPadをWindows boxに接続する
* iTunesがiPadを認識したかを確認し、updateなどに関するwindowが出るのを待つ
* 必要に応じてupdateなどを行う

補遺

* iPadのデータを消したくない場合は別の方法を取る必要がある
* 有料のツールを使うのも手。3000〜4000円ぐらいからあるので、急ぎで確実に行いたいならばそちらを使うのも良いだろう

参照したwebsites

基礎知識について

* [Show UDID of iPhone Using awk, cut, grep, lsusb, sed](https://www.commandlinefu.com/commands/view/9632/show-udid-of-iphone)
* [ECID - The iPhone Wiki](https://www.theiphonewiki.com/wiki/ECID)

Softwareのrepositories

* [GitHub - libimobiledevice/idevicerestore: Restore/upgrade firmware of iOS devices](https://github.com/libimobiledevice/idevicerestore)
* [GitHub - libimobiledevice/libirecovery: Library and utility to talk to iBoot/iBSS via USB on Mac OS X, Windows, and Linux](https://github.com/libimobiledevice/libirecovery)

その他

* [Device never fully restores · Issue #124 · libimobiledevice/idevicerestore · GitHub](https://github.com/libimobiledevice/idevicerestore/issues/124) ※-x option

Firefoxのaddonが証明書の期限切れで使えなくなった問題に対するworkaround

5/5現在、徐々に回復してきているらしいが、引き続き自分の環境はaddonがinstallできない状態は継続しているのでそれに対するworkaroundを。

about:config → xpinstall.signature.required を false にする

このworkaroundにより:

* 起動中のFxで突然無効になったaddonが復活する
* 新たにaddonを入れ直す時に「壊れているのでinstallできない」問題が解決

本質的にはsignatureが正しいものに更新されるのを待つ。修正されたら再びxpinstall.signature.requiredをtrueに戻す方が良いだろう。

なお、動作を確認したのは:

* Mozilla Firefox 68.0a1 (Nightly) @Linux
* Mozilla Firefox 60.6.1esr (ESR) @Linux

という、多数派ではない環境なので留意されたい。

/tmpがdisk fullになったのに原因が不明だったのでlsofで調べた話

結論から言うと:

Linuxではopenされたfileがcloseされるまで、deleteされてもmemory上に残ってしまう。それによるdisk fullだと、lsofで調べて初めて分かった。

ちなみに、犯人 (process)がmultiprocess対応のFirefoxだったので、当該tabを閉じたら (=processを殺したら)fileがcloseされて開放された。

cf.

* [ubuntu - lsof shows tmp growing file marked as deleted - Server Fault](https://serverfault.com/questions/881501/lsof-shows-tmp-growing-file-marked-as-deleted)
* [linux - /tmp used 100% where is files? - Server Fault](https://serverfault.com/questions/488132/tmp-used-100-where-is-files)

SwissMicros DM42のfirmware update (v3.13)

2019-03-13にDM42のfirmware v3.13が公開されていた。気付いたので早速updateしてみた (なお元々、この記事は2019-03-18に公開する予定だった)。

どんな変更がなされたかは以下を参照されたい:

cf. [Firmware History](https://www.swissmicros.com/dm42/firmware/history.html)

Updateには2つの方法がある:

* Downloadしたfileをdfu-utilで書き込む、か
* DownloadしたfileをDM42のFAT領域に転送して本体でupdateする

の何れか。

今回はdfu-utilで書き込んだ。dfu-utilを使った方法は以前紹介しているので過去記事を参照されたい:

cf. https://typeinf-memo.blogspot.com/2017/12/swissmicros-dm42firmware-update.html

Mesalibのお勧めbuild方法がautotools → meson & ninjaに変更されていた

Linux (やUnix-likes)におけるsoftwareをsource treeからbuild & installするには、

% ./autogen.sh
% ./configure
% make
% make install

の一連のcommands発行によって行われてきたが、cmakeやmeson & ninja採用のものも増えている。なお、Mozilla Firefoxのように規模の大きいprojectは独自のbuild system (mach)を持っていたりする。

Mesalibも数年前からmeson & ninjaによるbuildが推奨になっていたようで、最近になって./autogen.shを実行するとその旨表示されるようになった。慣れたものから変更するのはそれなりに抵抗があるのだが、今後を考えると公式に推奨されるものに「乗る」方が良いだろうと判断した。

そういえばMesalib以前にもmesonとninjaでbuildしたことがあるなと思い返してみたら、GithubのAtomとかChromiumがそうだった。

下準備

Debianの場合はmesonとninjaがpackageになっているのでinstallする。

% sudo aptitude install meson ninja

Mesalibのbuild (w/ meson & ninja)

最初にbuildのためのdirectoryを作る (eg. build/)

% meson setup build/

reconfigureしたい:

% meson setup --reconfigure build/

buildする:

% ninja -C build/

installする:

% sudo ninja -C build/

cleanする:

% ninja -C build/ clean

取り敢えず細かいoption指定とかをしなくて良いならこれで十分。

option指定 (w/ meson):

勿論option指定もできる。とりあえず、以前からの設定を引き継ぐ格好で以下のように指定してみている:

% meson setup --reconfigure build/ -Dgallium-drivers=iris,radeonsi,swrast -Dvulkan-drivers=intel,amd

cf. [Compilation and Installation using Meson](https://www.mesa3d.org/meson.html)

Linux kernel 5.0がrelaseされたのでupgrade

Linux kernel 4.20.13 → 5.0へupgrade。

Phronixが行っているbenchmark testによれば、Linux 5.0は4.20.x比で性能が低下しているとのこと。Spectre/Meltdown対策が主な要因のようだ。そう言えば最近SPOILERなんて新顔も報告されている。

cf. [Linux 5.0 Kernel Performance Is Sliding In The Wrong Direction - Phoronix](https://www.phoronix.com/scan.php?page=article&item=linux-50-sliding&num=1)

なお、最新のLTSは4.19.x series (ちなみにRaspbianも最新版は4.14.x seriesから4.19.xに移っている)。

cf. [LKML: Linus Torvalds: Linux 5.0](https://lkml.org/lkml/2019/3/3/236)

SwissMicros DM15Lのfirmware v28が公開された

去る2/22にSwissMicros DM1x seriesのfirmware v28が公開されたのでupgrade。

cf. [Firmware History](https://www.swissmicros.com/dm42/firmware/history.html)

今回の更新内容は:

* DM1Xでirregular LED blinkingの修正
* DM41向けfixes

とのこと。


Upgrade instructionsは以前紹介した通りなので詳細は過去記事を参照されたい:

cf. https://typeinf-memo.blogspot.com/2017/12/swissmicros-dm42firmware-update.html ※dfu-utilを用いたfirmware updateの手順

電子機器の裏側などに表示されている様々なマークについて

スマートフォンやノートブックPCなど電子機器の裏側のラベルには多くのマークが記載されている。その意味がふと気になったので可能な限り調べてみた。

図1と図2の通り:

図1 Wacomのタブレットの裏側のマーク

図2 Xbox360のコントローラ (有線)の裏側のマーク

今回発見できたマークは以下の通り:

* EAC → ユーラシア経済連合 (ロシア、カザフスタン、etc)による認証
* KC → 韓国の国家統合認証マーク
* CE → EUの安全基準
* VCCI → 日本企業のEMI (電磁妨害)の自主規制
* BSMI → 台湾の通商機関の認証
* FCC → アメリカの連邦通信委員会の認証
* RCM → オセアニア (オーストラリアとニュージーランド)の規制
* WEEE → EUの電子機器廃棄の基準
* DoC → ウクライナの自己宣言マーク (ウクライナ版RoHS)
* China-RoHS → チャイナ版RoHS

今回は無かったが、他にも有名所としてULや技適 (日本の電波法)、最近モバイルバッテリーにも必要になったPSEマークなどがある。

なお、China-RoHSの上下に分かれた矢印の円の中央の数字は「環境保全使用期限」と言い、含まれている有害物質が放出されない期間を年数で示したものである。

eg. 中央の数字が10の場合、その製品は製造から10年間有害物質を放出しないことを意味する

参照したwebsites

* [安全規格から探す | ACアダプター＆スイッチング電源のユニファイブ](https://www.unifive.com/products/safety/) ※DoCはここでようやく発見した

マークを探すに当たって

マークは文字ではないので検索して調べるのは中々面倒な作業である。ローマンアルファベットで色々と書いてあればまだ検索のしようもあるのだが、DoC (ウクライナ)に至っては写真を切り出しuploadして画像検索しても引っ掛からなかった。最終的には前述のwebsiteで一覧から見付け出した。

また、検索を困難にする理由の一つに何に対する認証や規制であるかがバラバラであることも挙げられる。例えばDoCやChina-RoHSは含まれている物質に関する安全基準についての適合を示すものだし、FCCやKCは当該国の電波法 (やそれに類する法令)への適合を示す、VCCIは電磁妨害に対する業界団体の自主規制への適合を意味する、などなど。どれか一つの意味を知っていて類推しようとしても、全く別の規制や法令、基準、規格への適合を示す場合がざらにあるので調べにくくなる。

先に挙げたwebsiteのように各国、各地域の基準などをまとめて掲載している場所を探す方が先決だと思う。

Philips 246Eのfactory modeに入って電源投入時の(目に悪い)ロゴを表示させないようにする

Philips 246E (以下246E)というFHDのLCDを使っている。価格も機能も見た目も気に入っているのだが、電源投入時に2〜3秒表示される真っ青なロゴ画面がだけは唯一気に入らなかった。

以前からfactory mode (以下FM)に入ればこれを表示しないよう設定できると目にしてはいたのだが、調べ方が足りずに結局放置していた。

5chのスレ (cf. [Philips 　液晶モニター総合スレッド 4枚目 \[無断転載禁止\]©2ch.net](https://mevius.5ch.net/test/read.cgi/hard/1468622967/))に書いてあった方法でFMに入れたのでメモしておく。なお、FMはend userが使うことを想定していないため、不具合が発生しても自己責任となる点に注意 (FMの設定項目を見れば分かるが、おそらく個体ごとのcolor calibrationとか設定しているっぽいので)。

* 246E本体から電源ケーブルを抜く ※スレで「主電源」と記載されていたのはこのこと
* 背面にあるカーソルキーを正面から見て右側に入れたまま電源ケーブルを挿入
* 電源が入ったら一旦放して、改めてカーソルキーを右側に入れるとメニューが表示される
* メニューの表示場所は中央からズレているかも知れないが気にせず一番下に行くとFMがある

更にFMに入って (カーソルキーを右に入れる)ロゴ画面の表示をOFFにする。

* "show logo"を選択してON→OFFに変更する
* FMの一番下にあるexitを選択 → 電源が切れる
* 電源スイッチを押すとロゴは表示されずに電源が入る (序でにFMにも入れなくなっている)

個人的にロゴ表示画面は不要だと思う。

Raspberry Pi 1 Model Bを使ってWinbondのflash chipに書き込みしてみた

*** 更新記録 ***

* 2019-01-28 材料、接続方法について追記

*** 更新記録ここまで ***


Raspbianのflashrom v0.9.9-r1954でread/writeできたので記録として。

$ flashrom --version
flashrom v0.9.9-r1954 on Linux 4.14.79+ (armv6l)
flashrom is free software, get the source code at https://flashrom.org

教訓1: flashromで読み書きする時はspispeedを指定しよう (linux_spi時は特に)

教訓2: 面倒でもICテストクリップのピンの対応を確認しよう

動機

* Shuttle SZ170R8のUEFI (BIOS)が飛んだ (飛ばした)時に備えてやり方を知っておきたかった
* ↑ UEFI (BIOS)に含まれているIntel ME関連のcodeを排除したcustom UEFIを作り、書き込んでみたかった
* 普段使ってないRaspberry Pi 1 Model BがあるのでROM焼き器として流用したかった

概要

こんな具合で接続している。

図1 RPi1BとブレッドボードとICテストクリップ

図2 別の角度から

図3 ICテストクリップとSOIC

材料など

Hardware

* Raspberry Pi Model B (RasPi1B) ※ちなみにrev1とrev2があるがどちらかは不明
* microSD card (32GB) ※32GBも要らないのだが適当なものが余っていなかったので
* LAN cable ※Rasbpian install後update & SSHでheadless運用するため
* USB cable (Type A - micro B) ※電源
* USB電源 ※5V 2Aぐらいのもの
* ICテストクリップ for SOIC-8 ※ebayで適当に買った物。400円くらい
* Winbond W25Q64FVSIG ※これも多分ebayで入手。10個で600円ぐらい
* ピンケーブル ※RasPiのGPIO (ピンヘッダ)からブレッドボードに繋ぐメス→オスのものと、ブレッドボードからICテストクリップのソケットに繋ぐオス→オスのもの
* ブレッドボード ※その辺に余っていた物。多分秋月電子で買った200円ぐらいの品
* テスタ (DMM) ※ICテストクリップのピンの対応を調べるのに使う

Software

* Raspbian Stretch Lite ※2019-01の最新版stable
* flashrom v0.9.9-r1954 ※Stretchに含まれるversion
* 書き込むUEFI/BIOSのimage file ※場合によっては.exeなどから取り出す必要あり

接続方法

具体的な方法は既に他のwebsiteでなされているので省略。要点のみ挙げると:

* SPIの最もsimpleな接続方法を使う (dual SPIとかquad SPIとかは使わない)
* W25Q64FVSIGの場合は電源電圧が3.3 V
* W25Q64FVSIGの場合は/HOLDと/WPのpinをpullup (=3V3と接続)しておく (pullupでholdとwrite protectの機能をそれぞれ解除)
* Raspbianの初期状態ではSPIの機能が無効化されているので、raspi-configで有効化しておく

Pitfalls

ICテストクリップの接続先の対応について

非常に当たり前のことなのだが、テストクリップの先のピンが、コネクタ部分のどのピンと対応しているのかを予めテスタで調べておくこと。

これを怠ったが故に間違ったピンを接続し、flash chipから香ばしい臭いが漂ってきた (80〜90度Cくらいにはなっていたようだ)。Flash chipは安いし予備もあるから良いが、RasPiが壊れていたら大変だった。

危うく2019年の「今年破壊したモノ」リスト入りさせる所だった。こういう基本的な所で手を抜くとロクなことがないという実例である。

なお、今回は幸運にもRasPiは勿論、flash chipも破損していなかった (書き込み・読み取り共に正常に完了した)。

spispeed=指定について

Web上にはRaspberry Pi + flashromでW25Q64FV (W25Q64.V)を扱っている記事がたくさんあり、すんなりいくものとばかり思っていた。が、実際に (↑きちんと確認して)接続しても認識すらしなかったので一体何が悪いのか分からなくなった。そんな中でこのpageを見付け、速度が問題なのでは？と気付き、安定性を取って遅いspispeed (512)を指定したらうまく認識するようになった。

cf. [Does not work without spispeed= on RPi · Issue #29 · flashrom/flashrom · GitHub](https://github.com/flashrom/flashrom/issues/29)

要は、高周波をまともに扱えるような配線状況でもないのに最高速度を出して (？)無理するとchipもまともに認識できない、という至極当たり前なことだった訳だ。よって、spispeed=による速度 (kHz)指定が必要となる。

ちなみに、このoptionについて調べると以下のような記述も出て来た:

Flashrom uses the Linux-native SPI driver, which is implemented by flashrom's linux_spi module. To use the RaspberryPi with flashrom, you have to specify that driver. You should always tell it at what speed the SPI bus should run; you specify that with the spispeed parameter (given in kHz). You also have to specify the Linux SPI device, e.g.

flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=1000

cf. [RaspberryPi - flashrom](https://www.flashrom.org/RaspberryPi)

今回は写真 (図1及び図2)の通り、RPiのGPIO headerから一旦ブレッドボードに出して、そこから長さが不揃いのジャンパケーブルでテストクリップに接続している。この非常に残念な接続方法により、datasheetによれば104MHzまで出るらしいが30MHzが限界だった (少なくとも35MHzだと認識せず)。

spispeed=で指定しない場合にどれくらいの値が出ているのかは不明だが、遅い方が読み取り・書き込みできる可能性が高くなるのは言うまでもない。勿論、読み書きの速度も遅くなるが。

Command examples

Flash chipの認識

特にoperationを指定しないと、何のchipとして認識しているかをprobeしてくれる。

$ flashrom --verbose --programmer linux_spi:dev=/dev/spidev0.0,spispeed=30000
...
Probing for Generic unknown SPI chip (REMS), 0 kB: probe_spi_rems: id1 0xef, id2 0x16
Found Winbond flash chip "W25Q64.V" (8192 kB, SPI).
This chip may contain one-time programmable memory. flashrom cannot read
and may never be able to write it, hence it may not be able to completely
clone the contents of this chip (see man page for details).
No operations were specified.

Winbondのflash chip "W25Q64.V"として認識しているのが分かる。W25Q64FVを接続しているのでok。

Flash chipからの読み取り

$ flashrom --verbose --read /tmp/image.bin --programmer linux_spi:dev=/dev/spidev0.0,spispeed=30000

Flash chipから読み取った内容を/tmp/image.binにdumpする。

Flash chipへの書き込み

$ flashrom --verbose --write /tmp/image.bin --programmer linux_spi:dev=/dev/spidev0.0,spispeed=30000

Flash chipへ/tmp/image.binを書き込む。

flashromのcommandsとoptionsについて

$ flashrom --help

で見られる。

$ man flashrom

もある。

参照したwebsites

* [flashrom](https://www.flashrom.org/Flashrom)

* [BIOSのアップデートに失敗するなどしてBIOSの内容が壊れ、ＰＣが起動しなくなった場合の対処方法（Raspberry Pi を使用した）](http://www.floatgarden.net/pc/bios_flash_raspberry_pi.html)

* [Raspberry Piを使ってBIOSが飛んだマザーを修理したお話 - Qiita](https://qiita.com/Ellise_MX/items/ed12700dbce31c01b34d)

* [Raspberry Pi(Zero)でASUS Z97-CのBIOSを焼く | 純規の暇人趣味ブログ](https://jyn.jp/raspberrypi-bios-flash/)

* [Libreboot – How to program an SPI flash chip with the Raspberry Pi](https://libreboot.org/docs/install/rpi_setup.html)

Firefox (nightly)をclang 8 + libc++でbuildする

Firefox (nightly)をmercurialのsource treeからbuildしているのだが、先日Debian experimentalに入ったGCC 9をinstallした時に入ったlibstdc++が原因でbuildできない。ただし、これがlibrary側のbugなのか、それともFirefox側の記述に問題があるのかは切り分けていないため不明。

以前から薄々気付いてはいたのだが、error messageを見るに、LLVM/Clangでbuildした場合でもC/C++ standard libraryとしてGCCに付属するlibstdc++が使われている。GCC 9付属のlibstdc++がだめでも、LLVM/Clangに付属するlibc++なら大丈夫なのでは？と思い実験してみた所無事にbuildできた。

なお、GCC 9とLLVM/Clang 8ではdevelopment stageが異なるのでcodeのmature具合が違っていて当然な点、更にはexperimental packagesにtroubleがつきものなのは当然なので予め申し述べておく。Firefox nightlyのbuildもGCC 8に付属のlibstdc++なら正常にできる。

software environment

* Firefox nightly (Mercurial) → cset 454868:c60e6c0c2e23

* llvm-8:amd64/experimental 1:8~svn351401-1~exp1

* llvm-8-runtime:amd64/experimental 1:8~svn351401-1~exp1

* clang-8:amd64/experimental 1:8~svn351401-1~exp1

* lld-8:amd64/experimental 1:8~svn351401-1~exp1

* libc++-8-dev:amd64/experimental 1:8~svn351401-1~exp1

* libc++1-8:amd64/experimental 1:8~svn351401-1~exp1

build instruction

.mozconfigに以下の記述を行う:

export CC='clang-8 -stdlib=libc++'

export CXX='clang++-8 -stdlib=libc++'

ac_add_options --with-clang-path='/usr/lib/llvm-8/bin/clang'

ac_add_options --with-libclang-path='/usr/lib/llvm-8/lib'

ac_add_options --enable-linker=lld-8

ac_add_options --with-ccache=/usr/bin/ccache

今回の肝は、compilerを指定する最初の2行の"-stdlib=libc++"というoption (ただし、これをclang-8の側 (C++ではなくてC)に適用して良いのか、意味があるのかは不明)。Debian packageのclangはdefaultでlibstdc++ (GCC由来)を使うため、-stdlib optionでlibc++ (LLVM/Clang由来)を使うよう明示する。

また、standard libraryの変更とは直接関係ないが、ついでにFirefoxが用いるlibclangなどのpathを指定し、更にlinkerをbinutilsのldではなくLLVM/Clang由来のlldを用いるよう明示する (ほとんど気分の問題)。

あとはいつも通り:

./mach build

で暫く待つ。

SwissMicros DM42のfirmware v.3.12がreleaseされた

SwissMicros DM42 (HP-42Sのclone)用firmware v3.12がreleaseされたので、早速upgradeしてみた。

cf. [Firmware History](https://www.swissmicros.com/dm42/firmware/history.html)

今回の更新内容は:

* Free42 (HP-42Sのemulator)のupgrade
* (様々なhardwareのreviewなどで有名な) EEVlogで指摘された不具合の修正
* etcetc

とのこと。

Upgrade instructionsは以前紹介した通りなので詳細は過去記事を参照されたい:
cf. https://typeinf-memo.blogspot.com/2017/12/swissmicros-dm42firmware-update.html ※dfu-utilを用いたfirmware updateの手順

Debian experimentalにGCC 9とClang 9が入った

GCC 9とClang/LLVM 9がそれぞれDebian experimentalに入った。

GCC 9

2019-01-23現在GCCは8.2 seriesがstableで、GCC 9は2019-04あたりにreleaseされる予定のようだ。

cf. [GCC Development Plan - GNU Project - Free Software Foundation (FSF)](https://gcc.gnu.org/develop.html)

LLVM/Clang 9

2019-01-23現在Clang 7.1 seriesがstableで、Clang 8は2019-02以降にreleaseされる予定:

cf. [The LLVM Compiler Infrastructure Project](https://llvm.org/)

emacsに-rvをつけて起動すると"invalid face: tooltip"を吐いて死ぬ

emacs-git (commit 551051596fe51d6e232315eeda8a0a79eb43bfdf)をsourceからbuildした後、早速立ち上げようとしたら:

% emacs -rv
invalid face: tooltip

……255を返して死んでしまった。

取り敢えずstraceでも見るか、と思い:

% strace emacs

は普通に立ち上がる (ただし-rvじゃないので真っ白なbgで)。

どうやら-rvをつけた時に立ち上がらないらしい。

問題が設定にあるのかemacs側にあるのか切り分けてすらいないので正確な原因は不明だが、取り敢えずこのままでは見た目が慣れないことこの上ないので、color themeを入れることにした。

el-get installでcolor-themeをinstallし、color-theme-clarityを採用。

White on black color theme by Richard Wellum, created 2003-01-16.

とのこと。何となく選んだ一発目で慣れた配色を引いた。

図1: color-theme-clarity (w/ transparent)

update-grubが"grub-probe: error: failed to get canonical path of ..."を吐いて失敗した原因と対策

Main machineではLinux kernel image (linux-image)を自前でbuildしているのだが、その際不要になった古いpackageの削除が失敗した。原因はlinux-image packageのpostrm scriptにhookされているupdate-grubが:

grub-probe: error: failed to get canonical path of sdb5_crypt

を吐いて失敗したことによる。なお、sdb5_cryptはLUKSでencryptしているpartitionであって、環境に依存して名前が変化する。

ちなみに、なぜlinux-imageの削除にupdate-grubがhookされているのかというと、linux-imageが削除されるとそのversionのkernelはもはや存在せずbootできないので、update-grubを実行してboot menu (/boot/grub/grub.cfg)をupdateする必要があるからだ。

最も簡単なworkaroundは、/dev/mapper/sdb5_cryptが存在しないので、これを作り直してやること。

sudo ln -s /dev/dm-0 /dev/mapper/sdb5_crypt

以前存在していた/dev/mapper/sdb5_cryptがなぜ無くなったのかについては不明だが、Linux kernelのupdate (4.19.11 → 4.20)、systemdのupdate、sysvinit → systemdへの変更、など幾つかの要因が考えられる。