Raspberry PiシステムSDイメージを縮小してから復元

投稿者: | 2022年3月7日

Raspberry Pi のシステムの入った SD カードのディスク イメージ を同じ容量の別の SD カードへ 復元 する際、正確な容量が微妙に小さいとそのままでは正しく 復元 出来ません。そこで イメージ を編集しメディアの差異に依らず正しく 復元 出来るようにしてみます。

微妙に小さいSDへの復元

FlightAwareがRaspberry Pi向けに提供しているADS-Bレシーバシステム、PiAwareを運用しているSDカードが怪しくなってきたため、新しいSDカードへ交換すべく、以前作成したバックアップイメージから復元しようとするも、Win32DiskImagerではイメージ書き込み時に容量不足の警告を受けます。

図1.Win32DiskImager 容量不足警告

図1.Win32DiskImager 容量不足警告

これは同じ容量が謳われたSDカードであっても、同じメーカーの商品でさえ製造時期により、その正確な容量が異なるため。

それでも書き込みを強行出来てしまうため、警告内容をよく見ずに進めてしまったのですが、後から検証してみるとbalenaEtcherでは容量が小さすぎると、ターゲットメディアとして選択することが出来ない安全仕様になっていました。

図2.balenaEtcher 容量不足で選べない

図2.balenaEtcher 容量不足で選べない

警告無視して復元したSDを検証

こうして警告を無視して復元したSDカードは、Windowsのエクスプローラ上でも一見問題無く認識されており、ドライブの中もエラー無く開くことができました。

図3.Windowsエクスプローラでの見え方

図3.Windowsエクスプローラでの見え方

尚、Linuxで一般的に使われるextファイルシステムをWindowsで読み書きするには、ext2fsdをインストールしておく必要があります。

 

Windowsでこれ以上調べることは難しいので、このSDカードをUbuntuで開いてみます。Disksユーティリティでは問題無さそうに見えますが、

図4.UbuntuのDisksでパーティション確認

図4.UbuntuのDisksでパーティション確認

blkid で確認すると、ルートシステムのPARTUUIDが見当たりません。

私もきちんと理解しておらず今回あらためて調べてみたのですが、PARTUUIDとはパーティション毎に固有な識別子であり、メディアが変わってもイメージから復元後も同じPARTUUIDが保持されるのだそうです(ちなみにUUIDはファイルシステムに付与される識別子)。

 

ブート時にカーネルパニック

このSDカードをRaspberry Piに挿して起動の様子をUARTから観察してみると、案の定カーネルパニックしてしまいました。

 

これはブートの挙動を決める /boot/cmdline.txt において、ルートファイルシステムの場所を次のようにPARTUUIDで指定しているためでしょう。

これを以下のようなデバイス指定とすれば起動するのかも知れませんが、

おそらく /etc/fstab にも同様な表記が使われていることからも、書き込み時に警告が出ないよう、ディスクイメージをメディアより少し小さめにトリムしてみます。

 

ディスクイメージの編集

Ubuntuではイメージファイルの右クリックから、ディスクイメージマウンタでまるごとループデバイスとしてマウントすると、先ほどのDisksユーティリティで通常のストレージと同じように扱うことが出来ます。

図5.ループデバイスとしてマウントしたイメージ

図5.ループデバイスとしてマウントしたイメージ

rootfsのパーティションを選びアンマウントの後、下の歯車アイコンからリサイズをクリックすると、次のようなパーティションサイズ編集ウィンドウが開くので、1.59GBあるこのパーティションを15.0GBまで小さくしてみます。

図6.ボリュームをリサイズ

図6.ボリュームをリサイズ

リサイズ後のパーティション構成は次のように変わり、後方が空き領域となりました。

図7.リサイズ後のパーティション構成

図7.リサイズ後のパーティション構成

なお、ディスクイメージの状態によっては、ループデバイスが読み取り専用となってしまい、変更を伴う操作が出来ないことがあります。このような時は、以前、CLIでのループデバイス操作をまとめたこちらの記事を試してみると良いかもしれません。

こうしてパーティションは小さくなったので、次は truncate コマンドを使って後方の空き領域をディスクイメージから切り取ります。まず fdisk で2つ目のパーティション後端のセクタ番号を確認。

こうして判明したセクタ番号( 29630463 )から切り取りサイズを割り出して truncate コマンドを実行します。

これでようやくイメージファイルのダイエットは完了しました。

これまでの作業の過程でイメージファイルのファイルサイズがどのように変化したのか比べてみると、パーティションをリサイズしただけでは小さくはならず、 truncate して初めて小さくなったことが分かります。

 

小さくしたイメージを書き込み

小さくしたイメージをbalenaEtcherに読み込ませると、今度はターゲットSDカードを選択出来るようになったので、そのまま書き込みました。その後のSDカードのパーティション構成をUbuntuで確認すると、rootfsパーティション後方の空き領域の容量が図7の時と異なるのが分かります。この差がSDカードメディア間の微妙な容量の差異というわけです。

図8.小さくしたイメージを書き込んだSDの構成

図8.小さくしたイメージを書き込んだSDの構成

また、 blkid でもルートシステムのPARTUUIDが正しく表示されるようになっていました。

 

正常にブート成功

このSDカードをRaspberry Piに挿して通電すると、シリアルコンソールを確認するまでもなく、基板上のACT緑LEDの点滅から正常に起動していることが分かりました。

図9.ブートに成功した初代Raspberry Pi

図9.ブートに成功した初代Raspberry Pi

起動中のRaspberry Piのコンソールから blkid を確認すると次の通り。

 

メディア間の容量の差異はSDカードに限った話ではなく、HDDでも普遍的に起こりうる事象で、RAIDミラーリング構成ではよくHDDの容量より少し小さめに領域確保して、メディア間に多少の差異があっても問題無くディスク交換出来るようにするのを思い出しました。

 

コメントを残す

メールアドレスが公開されることはありません。

CAPTCHA