grubコマンドを使いながらマルチブート環境構築ログ

すでにWindows98,2000,XP,VineがインストールされているPCにFreeBSD7.0をインストールした時の記録です。

FreeBSD7.0をインストールする前のハードディスク構成は下の図のようになっていました。 ハードディスクは3台あります。Cドライブには98と2000が、ZドライブにはXP、Zの左となりの3つがVineです。EとFはただのデータです。これらをインストールした順番は98,2000,XP,VineでブートマネージャにはVineインストール時にインストールされたgrubが使われています。

hdd

今回G:のところにFreeBSD7.0を新規にインストールしました。インストール時のブートマネージャの選択のところは、[None]を選択しました。

よってインストールしたあとも自動でFreeBSD7.0をブートすることはできません。以下のような手順で、このFreeBSD7.0をブートできるようになりました。

まずVineを起動して、/etc/grub.confの内容をメモしておきます。

—————————————————————————————–

default=0
timeout=5

title Vine Linux (Current kernel)
root (hd1,0)
kernel /vmlinuz ro root=LABEL=/1 resume2=swap:/dev/hdb5 vga=0x314 nosmp noapic nolapic
initrd /initrd.img

title Vine Linux (Previous kernel)
root (hd1,0)
kernel /vmlinuz.old ro root=LABEL=/1 resume2=swap:/dev/hdb5 vga=0x314
initrd /initrd.old.img

title Other
rootnoverify (hd0,0)
chainloader +1

—————————————————————————————–

次に、ここのやり方をまねして、ここからgrub-0.97-i386-pc.ext2fsを落として、grubフロッピーを作りました。

以下がこのフロッピーで起動した画像です。ここで上記のメモにしたがってコマンドを入力し、最後にbootを実行すると、ちゃんとVineがブートできることを確認しました。

grubfdlaunch


つぎにここを参考に、以下のようなコマンドを実行すると、FreeBSD7.0がブートできました。

afterfreebsd7install


最後にVineを起動して、/etc/grub.confにFreeBSD7.0用のブートコマンドを追加しました。

———————————————————–

default=0
timeout=5

title Vine Linux (Current kernel)
root (hd1,0)
kernel /vmlinuz ro root=LABEL=/1 resume2=swap:/dev/hdb5 vga=0x314 nosmp noapic nolapic
initrd /initrd.img

title Vine Linux (Previous kernel)
root (hd1,0)
kernel /vmlinuz.old ro root=LABEL=/1 resume2=swap:/dev/hdb5 vga=0x314
initrd /initrd.old.img

title Other
rootnoverify (hd0,0)
chainloader +1

title FreeBSD7.0
root (hd2,2,a)
kernel /boot/loader

———————————————

以下のようになり、FreeBSD7.0がブートできるようになりました。

hddbootafter

Visual Studioが落ちたときの復活法

Visual Studioがたまに落ちる。しかも落ち方がすごくて他のアプリも巻き込んで、OS再起動しかなくなるときがある。

しかしなぜかコンソールアプリだけは生きていることが多い。そこでCygwinをあらかじめ起動しておけば、CygwinからVisual Studioを強制終了することで、OSの再起動をまぬがれることができる。

CygwinでVisual Studioを殺す方法は以下のとおり。


$ ps -W | grep -i msdev
3640 0 0 3640 ? 0 16:35:33 C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin\MSDEV.EXE

$ /usr/bin/kill.exe -9 -f 3640

ここではexeの名前はmsdevとしたが、それぞれ置き換えてください。

Linuxのファイラー?が使いづらい?

Windowsを使っていた人がLinuxのgnomeなんかを始めるとやたらとファイラーが使いづらいと感じるきがします。

私はタブ式のファイラーであるMDIEを使っていたので、これと似たようなそふとをGTK環境で探したがなかなか見つかりませんでした。konquerorはMDIEに近いですが、これはQtベースなのでgnome環境ではあんまり使いたくない感じです。そもそもLinuxの世界ではD&Dの統一的な規格もないので、ファイラーの実装にも限界があるようです。

そこでWindows風の使い方を改めて、べつの視点から使う方法を考えてみました。

基本的にファイラーを使いたいときは、あるいくつかのディレクトリが見えている状況さえあればいいので、状況ごとにシェルスクリプトを書いてnautilusを起動するようにしてみました。

#/bin/sh
nautilus --browser smb://192.168.0.3/Data &
nautilus --browser ~/Data &

とかを状況によってスクリプトを書きました。また幸いなことにnautilusには-qオプションがあって、これを使うとすべてのnautilusを閉じてくれます。

$ nautilus -q

こんな感じでLinuxでは使っていこうと思います。

あとは関連付けですが、これについてはまだあんまりよく分かってません。もう一回よく調べてみることにします。

ファイラーって書きましたが最近は聞き慣れませんね。ファイルマネージャというべきでしょうか?

rpm 覚え書

・.rpmを新規にインストール
#rpm -i rpmfile.rpm

・インストールされているパッケージをアンインストール
#rpm -e package

・インストールされているパッケージを検証
#rpm -V pacakge

・インストールされているすべてのパッケージを検証
#rpm -Va

[表示されるエラーの種類]
S: ファイルのサイズ (Size) が異なる
M :モード (Mode; 許可属性とファイルの種類) が異なる
5 MD5 チェックサムが異なる
D デバイス (Device) のメジャー/マイナー番号が一致しない
L readLink(2) したパスが一致しない
U 所有者 (User) が異なる
G グループ (Group) が異なる
T 修正時刻 (mTime) が異なる

あるファイルが含まれるパッケージを表示
#rpm -qf somefile

・インストール済みのパッケージがもつファイルを一覧表示
#rpm -ql package

・.rpmファイルの中のファイルを一覧表示
#rpm -qpl rpmfile.rpm

・インストール済みのパッケージの情報を表示
#rpm -qi package

・ソースrpmをダウンロードしてソースを取得
# yum install yumdownloader
# yum install rpmdevtools
$ rpmdev-setuptree
$ yumdownloader --source xxx
$ rpm -i xxx.src.rpm
$ cd ~/rpmbuild/SOURCE

参考:http://memo.blogdns.net/rpmbuild.html

pkg-config

pkg-configはあるライブラリ(例えばlibdrm)を使うプログラムをコンパイルする際に必要になる各種コンパイルフラグを出力するツール。

$ pkg-config --cflags libdrm
-I/usr/include/drm
$ pkg-config --libs libdrm
-ldrm
$ pkg-config --cflags --libs libdrm
-I/usr/include/drm -ldrm

pkg-configは /usr/lib/pkgconfigにあるlibdrm.pcからこれらの情報を得る。またはPKG_CONFIG_PATHが設定されていれば、ここからもlibdrm.pcを探す。

fedoraではlibdrm.pcは通常のlibdrmのインストールではインストールされず、develパッケージをインストールすることによりインストールできる。よってあるパッケージのconfigureなどでlibdrm関係のエラーが出たら、以下のようにしてdevelパッケージをインストールすればよい。

# yum install libdrm-devel

VC6でつくったソースのON_COMMANDがVC7,8,9でエラーになる

ハンドラ関数の宣言が間違っていることが原因。

VC6の場合は、宣言が間違っていてもコンパイルがとおるが、VC7からそうではなくなった。

ON_COMMAND(ID,func)においてfuncは以下のように宣言されていなければならない。

void func();

またON_MESSAGE(MSG,func) においては以下のように宣言されていなければならない。

LRESULT func(WPARAM wParam, LPARAM lParam);

find コマンドの使い方

上のようにすると、カレントディレクトリのすべてのファイルを表示する。 通常すべてのファイルを表示する必要はないのでここから条件をつけていって表示を絞っていく。

上のようにするとファイル名に aaa という名前が含まれるものが表示される。

上のようにすると普通のファイルのみ表示される。

上のようにすると普通のファイルで、aaaが含まれるファイルが表示される。

上のようにすると、10メガバイト以上のファイルを表示される。

上のようにすると、24時間以内に更新されたファイルを表示する。

findの引数をどんどん付け足すと見つけるファイルを絞り込める。

上のようにすると、拡張子がzipでサイズが10M以上で24時間以内に更新されたファイルを表示する。

-execを使うと、検索結果を受け取ってコマンドを実行できる。検索結果は{}で受け取る。-execの終わりは;を置く。;はシェルによって解釈されないようにエスケープしておく。

上のようにすると~で終わるファイルを~/.gomi/に移動させる。

vmwareでゲストのLinuxの時計がやたらとくるう

ゲストLinuxの時計がやたらにくるうので調べてみました。

Vineの場合はカーネルパラメーターに
nosmp noapic nolapic
を追加したら直りました。

(例)/etc/grub.conf
kernel /vmlinuz ro root=LABEL=/ resume2=swap:/dev/hda3 nosmp noapic nolapic

(注)Fedora8でnosmpをつけるとブートできなくなる

これをつける前の/proc/interrupts
CPU0
0: 1643398 IO-APIC-edge timer
1: 2573 IO-APIC-edge i8042
7: 0 IO-APIC-edge parport0
8: 2 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
12: 240437 IO-APIC-edge i8042
14: 22592 IO-APIC-edge ide0
15: 61737 IO-APIC-edge ide1
16: 21 IO-APIC-level BusLogic BT-958
17: 36950 IO-APIC-level eth0
18: 185967 IO-APIC-level Ensoniq AudioPCI
NMI: 0
LOC: 1643457
ERR: 0
MIS: 0

つけた後
CPU0
0: 44155 XT-PIC timer
1: 146 XT-PIC i8042
2: 0 XT-PIC cascade
7: 0 XT-PIC parport0
8: 1 XT-PIC rtc
9: 112 XT-PIC acpi, Ensoniq AudioPCI
10: 56 XT-PIC eth0
11: 21 XT-PIC BusLogic BT-958
12: 4049 XT-PIC i8042
14: 5567 XT-PIC ide0
15: 1152 XT-PIC ide1
NMI: 0
LOC: 0
ERR: 0
MIS: 0

タイマー割り込みがやたら多かったのが減りました。

以下覚書

まずvmwareのことはされおいて、OSがどうやって時刻を管理しているか。

・OS起動時には、BIOSやNTPDで時刻を設定する。

・その後は定期的にやってくる割り込みによって、 時刻を増やす。

つまり1秒に100回の割り込みがくることになっていれば、割り込み処理において、時刻を1/100秒増やせばよい。しかしOSが忙しいと、この処理に1/100秒以上かかってしまい次の割り込みが無視される。その結果時刻が遅れることになる。

VMは本来ならこの割り込みを発生させなければならないが、そんなことしてると大変らしいので、うまくごまかしているらしい。そのごまかし方の1つがホストのタイマー割り込みが来るまで、VMから割り込みを発生させない方法のようです。 しかしそれだと当然ゲストOSの時刻が遅れるので、そのときにこれまで溜まっていたはずの割り込み(backlog)を一気に発生させるようです。しかしホストが重かったりして、充分に割り込みをさせることができない場合、それが60秒を超えると、ホストの時刻と動機を実行する(vmware toolsの機能が有効な場合)ようです。

ちなみにWindowsの場合1秒に1000回、Linux2.6の場合も同じ、ただしLinuxでSMPが有効だともっと増えるらしいです。

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1420

そしてこれを直すには、ゲストのレートを減らすか、ホストのレートを増やすかだそうです。

自分の環境だとくるうのは、システムクロックだけで、ハードウェアクロックは正常でした(ゲストOSのハードウェアクロックはホストマシンの時刻を見ているからかも)