気の向くままに辿るIT/ICT/IoT
システム開発

NetBSDインストール済みLiveイメージの作成

ホーム前へ次へ
NetBSDのインストールと運用/NetBSD/i386 6.1.x編

NetBSDインストール済みLiveイメージの作成

NetBSDインストール済みLiveイメージの作成

2016/11/30

 NetBSDでは、比較的最近のことだと思いますが、build.shで簡単にインストール済みLiveイメージを生成することができるようになっています。

$ ./build.sh -U -O obj -x release live-image
$

 15. NetBSDのビルドとbuild.shにもあるようにソースを取得、詳細はリンク先及び./build.sh -hとusr/src/BUILDINGに譲るとして例えば、このようにすると多少時間はかかりますが、ただ待っているだけでエラーなく簡単にHDD用とUSBメモリ用の2つのXウィンドウシステム込みのNetBSDインストール済みLiveイメージが完成、デフォルトでは../release/imagesに置かれます。

 ファイル名は、確認時点では、それぞれ、NetBSD-`uname -r`-`uname -m`-live-sd0root.img.gzとNetBSD-`uname -r`-`uname -m`-live-wd0root.img.gzといった書式の名称となっており、前者がUSBメモリ用、後者がQEMUでも確認可能なHDD用です。

 ファイルサイズは、確認時点では、Xありでwd0版が2.0GB、sd0版が1.4GBで何れも使用量は700MB強、Xなしで全体容量は変わらず、使用量は共に500MB強です。

 ただし、これらはマウント後df -hで得られた値であり(、ましてファイルマネージャなどで得られる値は、その種類によって異なることも珍しくありませんが)、wd0版はともかく、sd0版は、実際、USBメモリに入れてみると1.5GBでも不足し、2GBに拡張してddした後、中身を確認してみると1.535GB程度になっていたのでUSBメモリのパーティション容量を確保する際は、要注意。

$ gzip -dc NetBSD-`uname -r`-`uname -m`-live-wd0root.img.gz > any_path/wd0.img
$ qemu-system-i386 any_path/wd0.img
...

 よってsd0版は、これをgzip/gunzipなどで伸長してUSBメモリにdd、wd0版は、伸長後、QEMUなどの引数として渡すとLiveイメージを起動することができます。

 初期パスワードはなく、アカウントをrootとして[Enter]でログインできます。

 wd0版、sd0版共にデフォルトでは英語キーボードになっていますが、日本語キーボードに設定したい場合、wsconsctl -w encoding=jpとすれば切り替え可能です。(英語キーボードで=は、^)

 Xで日本語キーボードに設定したい場合、USBを挿したPCにNetBSDが入っているなら、マウントして、xorg.confを/etc/X11以下にコピーするなどすればよいでしょう。

 タブ補完や履歴機能がなく、これが必要な場合、set -o emacs;set -o tabcompleteとすればよく、set -oで設定状況を確認可能です。(設定OFFは、+o)

 もちろん、sd0版は、USBまるごと使ってLive USBとすることもできますし、マルチブート構成としも利用することができ、GRUB 2を使ってブートすることもできます。

 いろいろパッケージを追加したい場合は、USBメモリ1本まるごとNetBSD Live用に使うのもありでしょう。

 マルチブートさせたい場合、sd0版を、まっさらなUSBメモリ1本まるごと使ってddコピーした後、Liveイメージのサイズとなって(しまって)いるトータルセクタ数含め、disklabelを調整、これによりUSBメモリの容量を上限にfdiskでパーティションを追加できるようになるので必要に応じて他のOS Live版などを追加、NetBSD Liveを先頭パーティションに置いたまま、最終的にfdiskとdisklabelを一致させておき、ブートローダをインストール(GRUB 2ならgrub-install/grub2-install、grub.cfgのmenuentry設定は、knetbsd /netbsdでも可能ですが、それよりもchainloader +1と)するのが無難かつ賢明と言えそうです。

 もし、先頭パーティションは他の目的に使いたいというケースがある場合には、いろいろやってみた結果、NetBSD(*BSD)でもLinuxでも当該イメージをパーティションにはddできない一方、一度、USBメモリ全体にイメージをddした後、相変わらず、NetBSD(*BSD)ではBSD(disklabel)パーティション間ではddできないものの、Linuxならdisklabelを見ず(が見えず)にMBRパーティション間でのコピーになるからかddできる為、これで他のUSBメモリの任意のプライマリパーティション(MBR形式)やGPT(基本)パーティションにdd後、NetBSD(*BSD)を起動し、当該USBメモリが割り当てられたデバイスのfdisk結果を注意深く眺めながらdisklabelを適切に調節すれば、(たぶん例外なく)正常に機能します。

 尚、disklabel値が正確ではない場合、GRUB 2で試してみたところ、chainloader +1ではうまくいかず、パーティションが間違っていなければ、knetbsd /netbsdでカーネルを直接コールすることはできますが、その場合、root partition(default:sd0c)といったプロンプトが表示され、うまくいけば、sd0a、残りの問いを[Enter]とすることでログインまで進み、そうでない場合はddb、reboot、haltを選ばざるを得ない状況にはなるものの、dd時にコピー先容量が微妙に不足していたなど他に基本的なミスがない限り、再度、disklabelを補正すれば、rootパーティションを問われることなく、ログインまで進む(相変わらずrootパーティションを問われるが先の手順でログインまで進む状態になるという場合は、更なるdisklabelの補正でその必要もなくなる)はずで、そうであれば、chainloader +1も機能するようになります。

 ちなみにカーネルを直接コール、rootパーティションを問われてsd0aとしても起動しない場合、NetBSD LiveのパーティションにfdiskでActiveフラグ(NetBSD)/bootフラグ(Linux)を立てることで改善される場合もありましたが、そもそもdisklabelが適切なら、その必要すらなくなるはずです。

 また、ddではなく、ラズパイでMicroSDとUSBメモリを使う際の2度手間を避ける為にふと思いついたrsyncする方法も試してみましたが、今回は、結構時間がかかって現実的とは思えなかったので、ここで、この方法を選択する意味はないでしょう。

[訂正・追記:2017/01/12]

GPT形式のUSBメモリでもNetBSD Liveを実行可能

 上記は、USBメモリがMBR形式のパーティション構成の場合ですが、マルチブート構成のGPT形式でもNetBSD Liveを起動できる方法があることがわかりました。

 ただし、

  1. GPTフォーマットしたUSBメモリの任意のパーティションにddする際には、ディスクイメージではなく、前述の要領でUSBメモリ(MBR/GPT形式不問)にddしてあるNetBSD Liveパーティションを元にすること(/dev/dk?にはddできるので作業はNetBSD上でも、また、Linux上でも可)
  2. USBメモリ(GPT形式)のNetBSDパーティションをマウント、/etc/fstab内のルートパーティションにおいて/dev/sd?a(sd0aなど)に代えてNetBSDのGPTパーティションに相当する/dev/dk?(dk3など)にし、swapとして定義されている/dev/sd?b(sd0bなど)行をコメントアウトか削除するなりして無効にしておくこと(もしくは、これに相当する/dev/dk?を確保すれば代替可かも??)
  3. ブートローダにはGRUB 2を使い、set root=(hd0,X)とした後、chainloader +1ではなく、knetbsd /netbsdとすること

 1つめは、ディスクイメージがUSBメモリまるごと1本使うことが想定されている為ですが、GPTの場合、それだけではなく、現行のNetBSDだとGPT形式用のdisklabelには未対応(もしくは、そもそもない、)なのでMBR形式の時のようなパーティション調整が効かず、マルチブート構成にする方法がない為、USBメモリをまるごと1本使うことを想定しているディスクイメージではなく、GPT形式でもMBR形式でも良いのでダミー・テスト用などのUSBメモリに一度、ddしたものをddコピー元とする必要があるということです。

 2つめは、NetBSDのルートパーティションをMBR形式の/dev/sd?aから、GPT形式の/dev/dk?に変更しておくということで、起動時にルートパーティションを認識できるようにしておく(記事中の当該部分訂正前の内容通り、ログインまでいかずシェルに落ちた原因への対処)という意味です。

 3つめもdisklabelがGPTに未対応である(または、存在しない)ことに起因する模様でchainloader +1だと[No Slice]となってしまう一方、この記事部分の訂正前にも書いた通り、knetbsd /netbsdとすると「ルートとなる/dev/sda0が見つからない」旨、表示され、shellに落ちていたわけですが、1つめ、2つめの対処・方法と、この3つめの方法を使うことにより、マルチブート構成のGPTフォーマットしたUSBメモリにおいてもNetBSD Liveを起動できるようになるということです。

 結果的にchainloader +1が使えず、カーネルを直接指定してブートする為、NetBSD標準メニューには遷移せず、直接NetBSDが起動します。

 ちなみにGPT形式でNetBSD Liveを含め、マルチブートさせようと思うと、このように一度、他のUSBメモリにddする手間がかかる一方、MBRでもNetBSD Liveを含め、マルチブートさせようと思うと微調整が必要となるのでどっちもどっち?。。。他方、USBメモリによるのか個体差なのか、MBR形式だとFreeBSD Live(bootonly.iso)とNetBSD Liveを共存できたり、できなかったりする場合があり、できなかったUSBメモリでもGPTならすんなり共存可能というケースもあったので状況に応じてMBR/GPT形式を選択するとよいでしょう。

[訂正前・2016/11/30付]

GPT形式のUSBメモリでは、微妙も実用には耐える?

 上記は、USBメモリがMBR形式のパーティション構成の場合であり、GPT形式でも一手間かければ、マルチブート構成含め、ブート自体は可能ではあるものの、GPT形式の場合、NetBSDでは、/dev/sd0aではなく、/dev/dk?に割り当てられることに起因するものと思われますが、ログインまで到達せず、シェルに落ちてしまいます。

 このようにGPT形式だとUSB上のNetBSDのルートを読み込めておらず、ログインできない為、書き込みはできませんし、仮にX込みでイメージを作成した場合でもXは使えません。

 ただ、USBメモリ内への書き込みさえしなければ、つまり、例えば、眺める程度の試用版としてならCLIのLive版としては、sysinstからシェルに落とすより遥かに多くのコマンドもある為、そういう意味では、全く利用できないというわけでもありません。

 一手間とは、USBがGPT形式の場合、理由は定かではないものの、そのままsd0版をパーティションにddしても起動しないのでsd0版のイメージとこれを入れるUSB上のパーティションを共にマウント後、イメージの中身をUSB上のパーティションにrsyncコピー、その後、GRUB用のFATパーティションが[bios_grub]となっていなければ、これに変更、また、変更した場合は、改めてgrub-installすることを指します。

 ちなみに特定のパーティションにgpt biosbootやGPartedなどにより、legacy_bootフラグを立ててしまうと(NetBSDも実際起動するにはしますが、)直接、当該パーティションのOSを起動しようとするのでマルチブート構成には不適です。

 他の方法を思いつかなかった為、シングルコアCPUマシンでUSB 2.0のUSBメモリにrsyncしたわけですが、2時間ほどかかった上、fdiskやdf -hで確認できるサイズ(1.4GB)で1.5GBとして余裕を見たつもりが、それでは足りず、途中、ディスク不足エラーで終了、gpt resize、resize_ffsで2GBに拡張後、rsyncを再実行しました(それでも途中から始めてくれるのがありがたい)。

 よってGPT対応のイメージがリリースされれば別ですが、そうでなければ、手間と時間を考えるとMBR形式のUSBメモリを別途用意してあるべき姿で使うのが無難でしょう。

[追記:2017/01/19]

CLIベースのNetBSD Liveが必要なら従来のインストーラ用ハイブリッドISOで十分

 CLIベースのNetBSD Liveが必要なら、インストーラ(sysinst)用のハイブリッドISOであるNetBSD-`uname -r`-`uname -m`.isoを、GUIが必要ならソースを入手し、build.shでlive-imageをビルドしたものを、USBメモリにdd埋め込みで使うと良いでしょう。

 NetBSDのインストーラの場合、FreeBSDのようなLiveを選択するメニューはありませんが、言語選択、キーボード選択後のsysinstメニューから[x:Exit Install System]を選択すれば、メニューを抜けてシェルプロンプトに移行、その時点でCLIベースのNetBSD Liveとして利用できます。(ブートオンリーなboot.isoだとコマンドが少ないですが、NetBSD-`uname -r`-`uname -m`.isoは比較的豊富。)

 自身は、インストールに超軽量boot.iso(bootonly)を好んで使い、他のISOディスクイメージには目もくれず、NetBSDをインストールする以前から気になっていたGUIベースのNetBSDのLive CDやLive USBは、なんだかんだで入手できないまま、NetBSDユーザーになり、それからだいぶ経ってレスキューUSBに凝ってCLIベースでよいんだけどNetBSD Liveもないしなと勝手に思い込んでいたところに、比較的最近、build.shでLive USBイメージ(デフォルトはCLIベース、オプション指定か環境変数設定でGUIベース)を作成できるようになったようで、これに気づき、使わせて頂いているわけですが、GUIが必要ならUSB live-imageも、そもそもCLIで良いのであればNetBSD-`uname -r`-`uname -m`.isoをdd埋め込みで使えばよい(80数MBのboot.isoより容量大きめの400数十MBのものが併せて用意されているのだから半ば当たり前の)ことに今頃気づき、これもレスキューUSBに入れることにしました。。。

 たいていのケースではCLIで十分、更にインストーラ・アップデータも付いてる、一方、端末を複数使いたいと思うこともある為、仮に気づく順番が逆だったとしても併用していたと思いますが、USB 2.0でも快適でXとX標準のtwmは入っていてbuild.shで生成できるNetBSD Liveイメージも重宝しています。

 尚、OSに関わらず、ISOディスクイメージは基本、HDDよりも高速なメモリに読み込まれる為、CPUとメモリに余力があればGUIベースのLiveでも快適ですが、USBメモリ用イメージを書き込んだUSBメモリを通常のHDD同様に使おうとすると特にHDDに比し、読み書きの転送速度が極度に遅いUSB 1.1では非現実的、相当遅いUSB 2.0で快適に利用できるのは、せいぜいCLIベース、とはいえ、さすがにインストール・アップデート・アンインストールなどを行なおうと思うとUSB 2.0では、現実的とは言い難いレベルであり、USB 3.0、更にUSB 3.1なら、そこそこ快適でしょうが、マシン自体も対応が求められるという点でUSB 3.0/3.1一色ではない過渡期の今、常に条件が満たされるとは限らないというのが現状なのでUSB 2.0であっても併用は有用でしょう。

勘違いに次ぐ勘違いから遠回り

 執筆時点でNetBSDのバージョンは、7.0.2が最新であり、NetBSDを入れてある手持ちのマシン3台も既に7.0.2にアップグレードしてあります。

 そんな中、なぜLive版がNetBSD 7.0.1なのか。。。恥ずかしながら、NetBSDユーザーであるにも関わらず、当初、生成されたイメージのsd0版はUSBメモリ用、wd0版はHDD向けという認識が薄すぎたことに起因します。

 NetBSDのLive版については、NetBSDインストール前からi386版かつX不要のCLI版でOK、軽量なら軽量なほどよいという視点で探し求めていましたが、全ての条件に合致するものがなく、NetBSDのインストールに至り、その後、mklivecdパッケージで作成できると知ってやってみたら、何度やっても失敗。。。ふと思い出したかのように探しても状況は変わらず。。。そんな中、遅まきながらbuild.shでlive-imageターゲットがあることを知り、build.sh初心者ながらやってみたら簡単にできたという。。。

 簡単にできたはできたのですが、先の認識不足と勘違いからQEMUでsd0版を試してしまい、失敗、他方、以前、Groovy UD-500SAで壊れかけHDDをUSB接続、NetBSDをそこから起動させた後、PC内臓SSDのNetBSDでwd0、sd0の判別ができないことに起因する不調が発生したトラウマからQEMUでwd0版を試すことなく、何か失敗したかな。。。と思って半ば諦めて放置してしまったのが、今年の8月。。。

 数か月経った今日になって、ふと、あれってwd0版でやればQEMUで起動できたんじゃ・・・と思い、やってみたら、あっさり起動。。。ちょっと(ホントは結構)感動しつつ、wd0版は使えるが、sd0版は使えないんじゃんと更なる勘違いをしたまま、今度は、USBメモリにwd0版をddしてしまうという失態。。。ただ、幸い、『netbsd "live-image" usb』をキーにgoogle検索、Re: How to install NetBSD on a USB stickで"the sd0 image will work on USB drives, and the wd0 image will work on SATA drives"という一文を発見、使い分け方が判明。

 続いて先日来、あまり使う機会はないものの好奇心からレスキュー用Live USBをGPT形式とMBR形式の2種類仕込むに至っていてMBR形式の空き領域が微妙に不足していたことからGPT形式を使うことになり、前述のように延々、遠回り。

 途中、新たにNetBSD 7.0.2のソースを取得、イメージも作成してみたものの、GPT形式で試していたところ、rsyncするにあたり、イメージをマウントしようとしたらなぜかできず、改めてNetBSD 7.0.1のソースを取得、イメージを作成してみても、やはり、マウントできなかった為、マウントできた当時作ってあった7.0.1のイメージを使っていました。

 そんな中、別途、余っていてテスト用に使っていたMBR形式でフォーマットしたUSBメモリ1本まるごと使って(これなら今日作った7.0.2でよかったのに)以前作った7.0.1のsd0版をdd、その後、後からfdiskで追加できることに気づき、マルチブートできることを確認するに至った次第。

 長い1日だったし、あっさりLive版が生成されてからだと数か月。。。道のりはとても長かった。。。ホントは簡単だったのに・・・勘違いはしないに越したことはないし、したとしても早く気づきたいものだ。。。

ホーム前へ次へ