存在しないUUIDを書き込むgrub-mkconfig

grub-mkconfigというスクリプトが多くのdistroで採用されています.

今実行しているOSをgrubのブートメニューに加えるのはもちろんのこと,マウントしていない他のパーティションにあるOSも探し出してメニューに加えてくれます.

現在第2 workstation (以下 “第2WS”)では,第1OSであるManjaroが第1パーティションにEFI+GRUBのブートローダーをインストールして,第2OSもその御蔭でブートするようにしています.

ところがどっこい,第2OSの情報が正しくgrub.cfgに書き込まれておらず,ブートしてくれません.いろんなOSを仮想マシンから引っ張り出してコピーしてみましたが,だめでした.

いろいろその過程でわかってきたのは,どうもgrub.cfgに書き込まれている第2OSのパーティションのUUIDが間違っていることです.

パーティションのUUIDはフォーマット時に設定されますからいくらでも変わるわけですが,それじゃ面倒なのと,FEATURE_C12の呪いの問題があるので,第2OSのパーティションは1度SlackwareのインストールDVDイメージからフォーマットして以来フォーマットせず,OSの入れ替え時には,rsync--deleteオプションを付けてコピーするようにしています.

何度grub-mkconfiginstall-grubをかけても,grub.cfgには,多分昔設定されていたであろう現存しないUUIDが頑なに書き込まれてしまいます.やむを得ないので,grub-mkconfig (あるいはupdate-grub)のあと,grub.cfgを編集して,UUIDを現在のものにすることで,第2OSもブートできています

第2OSの側で,

find -type f -exec grep -H 古いUUID {} \;

をかけても見つかりませんでした.今度第1OSで同じことをして探してみます.

Linux distributionの略.英語のドキュメント類を読んでいないことがバレるので “ディストリ” と略さないようにしましょう.
Debianの32bit版,64bit版,Slackware 32bit版,64bit版,Manjaro 64bit版の5種類試しました.
もちろんsedでもできますが,全体を見渡しながら修正するほうが好きなのでエディターでやってます.
というか,それがわかってそのようにしているのはきょうになってから😅

箱庭遊び16: ほぼ習熟

バックアップから, 仮想ディスクを仕立てて,仮想マンシを起動するまでの手順をほぼ習熟しました.KVM/QEMUでもVMWare Fusionでもほとんど手順を間違えずに,あるいは間違えたとしてもすぐ修正して,仮想マシンが動きました.

一応これは実用的な訓練でしたが,あとは実用的な利用目的は考えつかないので,そろそろ箱庭遊びは切り上げます.

さて,次は何をしようかな😥

箱庭遊び15: KVM/QEMUでもバックアップから作った仮想ディスクでブート成功

某所で動いている実用サーバーのバックアップから仮想ディスクを起こして起動させるテストの続きです.

一昨日うまく行かなかった理由はDebianのインストール用DVDイメージのRescueモードから,作った仮想ディスクにchrootしていたからです.この方法だとchrootの前のおまじないが足りないということは,随分前に経験済みだったのですが,同じところで一日はまり込んでいたわけです.

この日の作業では,まず上記Debianのインストールディスクでchrootしてうまく行っていなかった,DOSパーティションの仮想ディスクに,Gentoo方式で正しくchrootして,grub-install, grub-mkconfigを実行して,ちゃんとブートするようになりました

次に,まっさらな仮想ディスクを仕立て,GPTパーティションとしてBIOS boot領域とルートの2パーティションにして,バックアップからコピーをして,同様にchrootしてgrub-install, grub-mkconfigをし,こちらもブートするようになりました

どちらの仮想イメージについても,Bookwormに無事upgradeできました.

使用したインストール用DVDイメージはSlackware64 15.0.
同じくSlackware64 15.0.

箱庭遊び14: ようやく1勝

今日は都合によりいつも仮想マシン遊びをする第2 WS(workstation)でなくて,第3 WSの位置づけであるMacbookのVMWare Fusion 13 Player(以下 “VMWare”)で戦いの続きをすることにしました.

まずはVMWareで新規のマシンOther Linux Kernel 5.x (64bit)を作りました.インストール用DVD イメージはSlackware64 15.0のものを使いました.仮想ディスクは分割しない40GBです.

DVDイメージからブートして,仮想ディスクをfdiskで1つのパーティションのみのDOSパーティション(MBR)にしました.そして普通に,

mkfs.ext4 -j /dev/sda1

としてformatしました.

ここでいったん仮想マシンを終了させて,同じVMWareで動いているまともなLinuxの仮想マシンに,先程作った仮想ディスクを接続(元からは削除)してrsyncを使ってバックアップの内容をコピーしました.バックアップには/sys /proc /tmp /devがありませんからこれらを手で作ったり,/devに関してはコピーしました.

コピーが完了したら,もう一度その仮想ディスクを先程の仮想マシンに戻して,引き続きSlackware64 15.0のDVDイメージから起動して,いよいよchrootです.

今回は昨日の反省を踏まえて,ちゃんと手作業で準備をしてからchrootしました.これで,

grub-install /dev/sda
grub-mkconfig -o /boot/grub/grub.cfg

として,今度は祈りながら仮想ディスクイメージからブートさせることで,ようやくディスクイメージからのブートに成功しました.

ネットワークの設定方法をすっかり忘れてしまっていましたが,実用マシンはスタティックなIPアドレスを使っていますが,そのままでは仮想環境から外に繋がらないので,/etc/network/interfacesをちょこっと編集しました.

これで外につながるようになったので,

apt update
apt upgrade
apt autoclean
apt autoremove
ここでリブートできればする
再度ログインして/etc/apt/sources.listのbullseyeをbookwormに書き換える
apt update
apt upgrade
apt dist-upgrade
apt autoclean
apt autoremove

以上で無事にBookwormになりました.このVMareの仮想ディスクvmdkをqemu-imgでqcow2にコンバートすれば何もいじらずにKVM/QEMU環境で起動すると思いますが,練習を積むことも重要な目的なのでKVM/QEMU環境では仮想ディスクの作成からもう一度やってみます.

たぶんGPTにする場合,BIOS boot用のパーティションが別に必要になると思います.
今回はManjaro AMD64.

箱庭遊び13: Debianの仮想マシンの復元作業で連戦連敗

今年の読売の対阪神戦のようです

少し実用に近い作業をしていますが,昨日は使える時間をすべて使って取り組んだにも関わらず全く成果が得られませんでした.

何をしているかというと,某所で実用的に動いている仮想マシンが現在Debian 11.x Bullseyeのままなので,その某所のネットワーク管理者に叱られる前にDebian 12.x Bookwormにupgradeする必要があり,その下準備です.

その某所の仮想マシンについては,「ホストの管理者権限をもっていない」という大きな制約があります.したがって作業は慎重に慎重を重ねてやっていますが,これまで動かしてきた1年ちょっとの間に数回リブートできないトラブルに見舞われました.

そのうち1度はブートの仕組みをぶっ壊してしまい,手元にあるバックアップファイルから仮想ディスクを再構築して,仮想マシンのホストの管理者(以下「大家さん」)にSDカードに書き込んだ仮想ディスクを郵送して差し替えてもらいました.

残りのブート失敗はKVM/QEMUのバグで,何回かブートするとブートの一番最初のあたりで引っかかって先に進まないものです .このトラブルの場合には,大家さんに仮想マシンの強制リスタートをかけてもらえばたいていというかこれまでのところ全部解消してきました.

それで今回の話に戻りますが,しばらくその実用的なDebianの仮想マシンはいじっていないのて勘所をすっかり忘れています.そこで,そのマシンのバックアップから仮想ディスクを作り,仮想マシンとして起動して,Debian Bookwormまでupgradeをするという手順の確認と習熟を手持ちのマシンでするという非常に生産的な作業をしています.

最初は最新状態のManjaroで空の仮想ディスクを作ってext4にformatしてnbdでマウントしてバックアップをコピーし,Debian 12.1 (Bookworm)のインストールDVDイメージからchrootしてgrubのインストールを試みましたが,何度やっても自分で起動するようになりません.ときどき “unknown filesystem” っていうエラーメッセージが出ている事に気づきました.FEATURE_C12の呪いを忘れていました.

Debian 11.xの仮想ディスクはDebian 11.xでformatして作らないとNGです

それを思い出してから作業をしていますが,Debian 11.xのインストールDVDから仮想ディスクイメージにchrootする選択をして,grub-installなりupdate-grubをするとエラーなくコマンドは通るのですが,いざ仮想ディスクイメージからブートしようとしてもgrubのrescueモードになってしまい,コマンドラインを打ち込んでもKernel Panicで止まってしまいます.

寝ながらいろいろ考えましたが,既に考え得ることは全てやり尽くしたように思います.しかし,昨年,確かにバックアップの内容から仮想ディスクを作り直し,その仮想ディスクで現在サーバーが稼働しているわけですから,できないはずはないです.

一つ可能性があるとしたら,Debianのインストール用DVDイメージのchrootで,必要なおまじないをしていないのかもしれません.

ということで,今日時間が取れたら,DVDイメージのRescue Modeから起動しても仮想とディスクへのchrootは自分でおまじないをしてからしてみる,というのを試みてみます.

これまで散々悪行を尽くしてきたのにこの成績とは,って誰か言ってました.
筆者がいじっている仮想マシンのうち唯一の実用マシンです😓
昨年トラブったときにネット検索をしていくつか事例を見つけたのですが,今回は面倒なので調べません.
筆者の経験則としては,10回に1回程度でしょうか.
当然最新のmkfsにFEATURE_C12をdisableにするオプションがあるはずですが,今のところ発見できていません😓