Debian Developerとしての籍は離れているが、Debianというディストリビューションやプロジェクトのファンであることに変わりはない。Debian 13 Trixieのリリース、めでたい。作業に関わられた皆さんに大拍手。
私物デスクトップもUbuntuではなくDebianを続けている。EC2立てではUbuntuを使うけど、AMIにSSMエージェントがプリインスコされているからというだけなんだよな。
という余談はさておき、Debian 12 Bookwormから更新開始。
GNOME端末が作業中に落ちた
Bookwormでのapt-get update、apt-get upgrade、apt-get dist-upgradeを終え、/etc/apt/sources.listのAPTリポジトリをtrixieに変更（オールドなのでaptコマンドにいまだ慣れない）。
まずはapt-get update、apt-get install apt dpkgで最小部分を更新。NECプリンタに使っているプリンタドライバxerox-phaser-6000-6010:i386がここで消えてしまうようだ。後で考えるとして実行。
外部サービスをしていないデスクトップなので、次に剛毅にapt-get upgradeを実行する。更新差分が発生したものは差分を確認して、新しいほうに置き換えたり、新しいほうに古いのを追加して置き換えたり、で基本的には新しいものを使うようにする。
順調順調、と思っていたら突然作業中のGNOME端末が消えてしまった。グェー。Bullseye→Bookwormのときにもやらかした覚えがあるが、またやらかした…。
デスクトップ環境上の端末で更新作業をしていると、途中の更新でデスクトップ環境または端末の更新でこういうことがたまにある。特にGNOME端末は下のライブラリの更新で影響を受けやすい。その間もある程度は裏で動いているようなので、しばらく待っていると、GNOME端末を再度起動できるようになった。
dpkg -configureの途中で待ち受け状態になっているがどうしようもないので、apt-get upgradeにシグナルを送って止める。
今度は何かあってもいいようにscreenで仮想ターミナルにして、作業を再開。設定途中状態のものをdpkg --configure -aで設定を済ませ、apt-get -f install、apt-get upgradeを再開できた。
/bootのケチりすぎはよくないことが起きます
破壊的変更をしない更新は終わったので、apt-get dist-upgradeへ。うむ、こちらも順調順調…と思っていたら、パーティションの容量残りが6MBしかないというポップアップ警告が。
最初に環境構築したときに、自動任せで/boot（sdb2）が256MB、残り（sdb3）はLVM PV 465GBにしていた。バカバカ。
Bookwormのときは2カーネルバージョン保持ならギリいけていたので、騙し騙し使っていたのだが、Trixieカーネルだとinitrdがさらに大きくなったようで、initramfsを作る段階でno space left on the device終了してしまう。厳しい。
年貢の納めどきなので、gpartedでリサイズするか〜と思ったのだが…。LVM PVの前側は削れなかった。そんな。
AIさん曰く「全体が壊れてアクセス不能になるリスク高い」とのこと。安全なのは全部インストールし直し。
再インストールはさすがに辛いなと思いつつバックアップ作業をしながら、ほかに手段がないかを考えてみる。
LVMにbootパーティションを作って、それをGRUBで参照するようにできるか、と調べてみたところ、新しいGRUBで普通にできるようだ。確かに全LVM構成とかもあるもんな。
しかし、LVMは現時点でrootとスワップの2つのLVが占有しており、空きのPEはない。rootが大きいのだが、削り出すリスクは高い。ブータブルOSで起動してresize2fsしてlvreduceして…とかになりそう。
ならスワップを削ろう。そもそもスワップ落ちするような状態になっていたら負けなので！ swapoffしてpvremoveして、同じ名前の小さいサイズでpvcreateを作ってmkswapしてswapon -aでスワップ有効、で終わり。
PEが空いたので、めでたくlvcreateで大きめなlv_boot LVを作成。いったん1GBにしてみた（もっとドーンと行ってもよかったかもしれないが…。まぁ広げるほうは簡単）。mkfs.ext4でext4フォーマットした。
/mntにlv_boot LVをマウントし、諸々やっていく。
GRUB-pcだったわ〜
UEFI環境のつもりで進めていて、新しいGRUBインストールの
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian
のところで失敗した。ハテ？と思ったらレガシーなgrub-pcを使っていた。ちゃんとEFIシステムパーティションは存在するのにどうして…（これは良いニュースではあるが）。
blkidコマンドでEFIシステムパーティションのUUIDを調べ、/etc/fstabに追加、mount /boot/efiしてマウントする。
UUID=XXXX-XXXX /boot/efi vfat umask=0077 0 1
grub-efi-amd64パッケージをインストール。GRUBインストールも行われるが、一応手で実行し直しておく。
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian update-grub
祈りながら再起動し、「debian」を選んで無事に新しい状態で起動した。/sys/firmware/efiも見えているのでよさそう。
/boot/efi/EFI/debian/grub.cfgは
search.fs_uuid xxxxxxxx-xxxx-xxxx-b9bc-f8be6e1d310a root lvmid/xxxxx-xxxx-xxxx-j7iJ-G52V-AnPw-SweSo3/xxxxxx-xxxx-nFc5-Qp18-wlu7-k6IX-Y0qmw3
となっており、blkidで見ると
/dev/mapper/XXXXXX--vg-lv_boot: UUID="xxxxxx-xxxx-xxxx-b9bc-f8be6e1d310a" BLOCK_SIZE="4096" TYPE="ext4"
でlv_boot LVに一致。
lvmidのほうはVG UUIDと、LV UUIDをスラッシュ区切りにしているだけか（vgs -v、lvs -vでわかる）。
xerox-phaser-6000-6010復帰
消されてしまったxerox-phaser-6000-6010だけど、パッケージをdpkg -iで入れ直し、apt-get -f installしたら直った。いまいち釈然としないがAPT最高と言える。
lookup-elが動かなくなっていた
Emacs 30になったのでいろいろありそうだけど意外と普通にエラーなく起動したな？と思っていたものの、やはりトラブルはあった。
まずはアップデート確認しつつスマホを見ていて気になった英単語を調べようとして、lookup-patternを実行したら「lookup-entries-cache-get: Wrong type argument: obarrayp, [nil nil nil nil nil nil nil nil nil nil ...]」で失敗した。なにこれおもろ。
似た症状を探したところ、どうもmake-vector関数の挙動が変わったっぽい。lookup.elの内容を見るといかにもこれが影響を受けてそうというところがある（1511個の0埋めベクタを作るつもりがnil埋めが作られるようになってしまった、という感じか）。
(defconst lookup-obarray (make-vector 1511 nil))
失敗した状態から(defconst lookup-obarray (make-vector 1511 0))とnilではなく0にしたものをevalして、再度lookup-patternをやってみたところ、うまく動いた。
久しぶりすぎてバグ報告の仕方を完全に忘れているし、バグ報告Emacs lispもなくなってしまったような気がする。reportbug -pで情報を作って、あとはWanderlustに貼り付けて送った。
Debian Bug #1111259に登録。おひさし〜
Wanderlustで送れなくなっていた
で、「Wanderlustに貼り付けて送った」と書いたが、実際は送ろうとしてつまずいていた。
こちらはシンプルで、mail-mailer-swallows-blank-lineというSunOSのバグ対応（！）の変数が新しいEmacsで削除され、この変数を参照して処理しているWanderlustのwl-draft.elが失敗する。
ワークアラウンドとしては(setq mail-mailer-swallows-blank-line nil)とか作っておけばよい、本質的には処理コードを削除。
しかしtatsさん活動されているのかは懸念である…（活動されていたらとっくに直されていそう）。
ホントEmacsは地獄だぜー
C-x 5 2で新ウィンドウ開いたら、えらくちっちゃいウィンドウになってしまったので、何かカスタム設定がまずそう。
OSもソフトウェアもバージョンアップしていこうな
いろいろメジャーアップデートされて、今後順次影響がわかるだろう。特にRubyのバージョンが変わるとローカルgemからまた見直すことになる。
OSやソフトウェアのメジャーアップグレードは毎回何らか問題は発生するだろうけど、そういうのを乗り越えて新しくしていこうな！ 本当に、切実に頼む！
