Windowsなどの使い慣れたOS上でUNIX variantのOSを試しまくるというのも普通の光景になった。つまりLAMP(もう古いか?この言い方)環境を 一気に揃えたり、自社のアプリをインストールする母体を作ってから、そのイメージを配布するというやり方だね。
VMWare製品版にはvdiskmanagerというツールがついていて、可変長がデフォルトの仮想イメージをハードディスクの実イメージに変換したりできるので、同容量のHDDにddコマンドで上書きして 大量複製 なんてことも可能になる。エンタープライズ用途では大変重宝する。
VMWareのディスクイメージがMBR/パーティションテーブル付きの ディスクイメージそのものであることは既知の情報。
そう思ってLinuxの仮想イメージをHDDにコピーしてブートしようとしたら すごい苦労した。 当たり前なんだけどデバイスドライバやカーネルは自動移行するわけじゃないんだな(笑)
どうしてもgrub(ブートローダ)がError15で止まる。Stage2段目に入れないもよう。仕方なくUbuntu Desktopを起動してgrubを再インストール。
# cd /tmp # mkdir root # mount /dev/sda3 /tmp/root # vi /tmp/root/boot/grub/device.map (hdaをsdaに) # vi /tmp/root/boot/grub/menu.lst (root,(hd0,0)などを変更) # vi /tmp/root/etc/fstab # /tmp/root/usr/sbin/grub-install --no-floppy --root-directory=/tmp/root /dev/sda
根本的にはVMWareの標準デバイスをIDEエミュレーションにしてたのが敗因。しかしこれでもエラーが出まくって正常に起動しない。
Loading, please wait... hda: drive not ready for command hda: drive not ready for command hda: drive not ready for command BUG: soft lockup - CPU#0 stuck for 11s!
みたいなの・・・ だからhdaはないんだってば! そのくらい分かれよう。initが起動する前に出るからinitrdの中身みたいなんだが・・・
# mkdir /tmp/initrd # cd /tmp/initrd # cp /tmp/root/boot/initrd.img-2.6.24-etchnhalf.1-486 initrd.gz # gzip -d initr.gz # cat initrd | cpio -i
とかやってinitrdの中身を解析したんだが、どうも/conf/conf.d/resumeというファイルに/dev/hda5と書き込んであるのが原因みたい。
# cd conf/conf.d/ # cat resume RESUME=/dev/hda5
これ、要するに ハイバネーション機構 が余計なことをするみたいだ。昔のLinuxはもっと単純だったんだがな・・・
現状タイムアウトすれば一応起動するんだけど、make-kpkgしてしまうのが簡単だろうか。というかDebianのinitrdを作る正式な作法ってなんじゃろね。
Debian系のinitrdはinitramfs-toolsパッケージの中のmkinitramfsとかupdate-initramfsの中身(シェルスクリプト)を見れば見当つきますよ。お作法としてはユーザーのカスタマイズは/etc/initramfs-tools以下をいじってねということのようです。
ワオ!ありがとうございます。さっそく調べてみます。
会社だと超古いMontavistaを後生大事に使っているので
世間から取り残され気味れす(汗;