SQLite Database Browserを日本語対応してみる

 ふと、SQLiteを、任意のSQL文を発行していろいろしてみようかと思って、GUIツールを調べてたところ、SQLite Database Browserというものがソースが公開されていて、かつ、派生を作ってもよさそうだということでいじってみました(ソースのライセンスは、パブリックドメインのようです。実際、派生もいくつかあるようです)
 このツールはQtとC++できているっぽいので、Qt(今のQtは商用、GPL以外にLGPLでの利用可能)とVisual Studio C++ Express 2010で環境を作ってみました。

 QtもC++も初めてですが、QtのライブラリによってC++の煩雑さがない感じです。ライブラリのリファレンスもQtの環境と一緒にインストールされるツールから簡単に参照できるので、知らない部分を調べながらでもわりとやりやすい感じでした。継承したクラスを使っているとき、利用可能なMethodやPropertyを参照するために、継承元のクラスの説明(リンクはある)をたどってゆかないと、Mehotdがあるのかないのかわからないのが、ちょっと不便でした。

 とりあえず、Qtの文字列であるQStringの文字コードと、OSの文字コード(日本語WindowsならばShiftJIS)と、DBとやり取りするときの文字コードの、それぞれの変換があいまいな部分をだいたい切り分けました(英語圏だとでたらめでも動いてしまうのか、おかしな実装になっていて)
 あとは、Qtがローカライズの方法が結構しっかりしているようだったので、メニューやメッセージを和訳しました。
 あと、本来、SQLiteはUTF8なんですが、わりと、EUC-JPやSJISでごまかしながら作成したデータベースが存在するっぽいので、UTF8を用いる代わりにEUC-JPやSJISでデータベースを走査するオプションも付けました。
 ついでに、日本語ファイル名もちゃんと使えるようにしました。

 元のつくりの不便さはそのままなものの、日本語ファイルが扱えなかったとか、日本語データが扱えなかったという部分が対応できたので、試してみるのも良いかと思います。ソース付。
(自分で直してしまう という選択肢があるのは、プログラムを読める/書ける人からすると、重要。)

ソースと合わせて、自サイトに載せました。
うぇいくのラボラトリのSQLite Databse Browserのページ

プログラムの変更なしで、言語ファイルを特定のフォルダに置くだけで日本語以外の他の言語も対応出来るようにできたらいいなぁ というのが次の予定(でも、未定)
機能の追加改善もいじりどころがおおいんですが、国際化対応を維持するためには追加変更部分のメッセージは英語で書かなければならないので、二の足。

| | コメント (0) | トラックバック (0)

USB3.0のLinuxをいかに起動しようか・・・(思案中)

 onBoardにUSB3.0のチップを持つMBを購入した(以前のが壊れたので買い替え&あっぷぐれーど)ので、USB3.0なUSB Memoryも合わせて購入して、Ubuntu10.10をセットアップ。
だめだろうなぁ と思いつつ起動してみるとやっぱりだめ。理由はBIOSが起動するデバイスとして対応していないから。
(チップセットに含まれてないからBIOSが対応していない という話を耳にしますが、それは間違い。BIOSもソフトウェアなんだから、対応しようと思えば(容量さえ足りれば)なんとでもなるし、対応していないのはMBのメーカ(BIOSメーカ)が単にそうしないからというだけ。)

そこで、以下の条件、
・内蔵HDDにインストールしたMS-Windows7(64)のMBRやPBRには変更を加えない。
・FDやCDやUSB2.0等の他の起動可能なデバイスは用いない(手間かけてまでは使わない)
・MS-Windows7のファイルシステム上にファイルを配置するのはOK。
・Ubuntu側の(kernelの)updateの際に、手間を必要としない方法にする(つまり、カーネルイメージと別ファイルでinitrdを取り出して置く方法はとらない)
でいろいろ探し回ってみたんですが・・・そもそも、USB3.0にアクセスできるものが異様に少ない。起動したMS-Windowsと、起動したLinuxぐらいっぽい。

と、すると、
・MS-Windowsの起動メニューからgrub4dosを呼ぶ。
・grub4dosから、NTFS上に配置したちっちゃなlinux+initrdを呼ぶ。
・ちっちゃなlinux+initrdから、USBを探してkexecする。
という感じなのかあぁ と。探すUSBのUUIDをgrub4dosから起動する際のカーネルオプションにできれば最高?
(UUIDは、initrd内に固定で書けば楽っぽいんですが、変わっちゃったら、アウトというのは避けたい)
もしくは、UUIDではなく、USBが1つならそのまま起動、2つ以上なら選択して起動とかなら、便利なのかも。
※ターゲットの調査はos-proberが役立つのかも。grub2の派生プロジェクトなのかな。
普段使いの起動なので、1つしかないもんを毎回選択するのは避けたいところ。まぁ、BIOSが対応し始めるまでの過渡期だけの話なんでしょうが・・・他メーカがチップ作っても結局intelの天下なんだなぁ。

| | コメント (1) | トラックバック (0)

ブートローダまわりであれこれ

ブートローダについてちょっと考えてみました。

 ブート(ストラップ)ローダは目的のOSを起動するためにあるんですが・・・・使われ方が大きく2つあると思っています。
1.OSに付属させて、普段OSを起動するのに用いるもの。
2.普段使用している起動方法でOSが起動しなくなったときに、起動を試みるもの。
3.OSと独立して設定して、普段OSを起動するのに用いるもの。

1.の場合、
・そのOSのupdateや更新とともにメンテされてゆく必要がある。
・本体となるOSを起動できることが必要。
・起動オプション等をOSのupdateや更新とともに変更する必要がある。
・他のOSも起動できると便利。
・追加のパーティションは要求しないほうが良い(分けるくらいなら、OSのパーティションに乗せたほうが良い)
・早いに越したことは無い(OSの性能の一部と見られるため)
・HDD等の固定HDDに入れて使える必要がある。
・起動するOSの種類は場所の構成は保存できると便利。

2.の場合、
・起動可能とされる複数のデバイスに対応していると便利。特にCD-R/DVD-Rは重要。
・HDDにインストールすることなく使えると便利。
・BIOSの力を借りずにできる範囲(USBやATAやSATA等)が広いほうが便利。
・PBRへのchainloadだけではなく、個々のOSを直接起動できたほうが良い。
・上のは、MBRやPBRといった部分が破損していても起動できると良い ということ。
・パーティション内のファイルから設定を取り込めると良い。

3.の場合、
・OSが複数なら、どのOSのパーティションにも依存しないほうが便利。
・いろんな種類のOSが起動できないといけない(chainloadも必要。chainloadだけでも、まぁなんとかなる)
・早いに越したことは無い。
・おそらくは、HDD等の固定HDDに入っていたほうが便利。
・独自のパーティションを要求しないほうが便利。
・起動するOSの種類は場所の構成は保存できると便利。
・異なる複数のOSからメンテできると便利。
・設定の変更はブートローダのメニュー上でできると便利。

1のケースで考えるなら、
・Linuxに取ってのliloは自身のOSに対してはまぁまぁよい。が、他のパーティションのOSへは弱い。x86アーキテクチャ依存で、PC-BIOS頼り。LBAは32はではある模様。48があるかは不明。
・Linuxに取ってのGrubは自身のOSに対してはまぁまぁよい。他のパーティションのOSにもまぁまぁ良い。x86アーキテクチャ依存で、PC-BIOS頼り。LBA48は未対応かも。
・Linuxに取ってのGrub2は自身のOSに対してはまぁまぁよい。他のパーティションのOSにもまぁまぁ良い。PC-BIOS環境でのBIOSの機能への依存は高め。LBA48に対応。この場合、MSDOS PARTITIONだと問題のある可能性もあるけど、GPT PARTATIONにも対応しているのでOK。
・MS-Windowsにとって、NTLDRやbootmgrは自身のOSに対しては良い。が、起動可能な構成に制約ある(起動できない環境にはインストールもできないので問題は無い)。また、他のOSに非常に弱い。LBA48、GPT対応(OSのバージョンしだいですが)
※どれも、OSのあるパーティションに関連ファイルがあるので、単純にOSのパーティションを削除(開放)すると、ブートマネージャ事態が起動できなくなります。

2のケースで考えると、
・SuperGrubDiskをCDで利用。CD起動を基本として、WindowsやLinux等のOSを解析して起動可能。
・PLoPをCDで利用。cianload可能なら対応可能。
・GAGをCDかFDで利用。cianload可能なら対応可能。

3のケースなら、
・MBM(MutlBootManager)は大体OK。MBR+Afterに設定可能。ただし、いくつかの点で古いです(HDDが4台までとかれてたり、シリンダ境界を前提にしたエディッタだったり)。ターゲットはChainLoadでの起動が必要。メリットはドキュメントが日本語?。opensorceなGPL。
・PLoPも大体OK。MBR+Afterに設定可能。ターゲットはChainLoadでの起動が必要。USBやPC-Card USBへのサポートが強み。free。not opensorce。
・Grub4Dosは、メインをMS-Windowsにする(MS-Windowsのパーティション上に関連ファイルを置いてしまう)なら有効。気難しいMS-Windowsの環境をそのままにできます(メーカ製PCでは重要)。opensourceなGPL。
・GAG Boot Managerは、グラフィカルで選択言語が多い。が、日本語はローマ字。ターゲットはCinalLoad必須。グラフィカルなのが強み。Linuxからのインストーラは、MBRのNT Signatureを上書きしてしまうのでVistaユーザは注意(MS-Windowsからのインストーラは大丈夫)。opensourceなGPL。


どれにも属さないケースとして、緊急時ではないけど、BIOSがサポートしていないデバイス上のOSを起動するというのがあります。大抵は、内蔵HDDのどこかに配置するか、CDで利用というケースになります(USB Memoryから起動できるなら、おそらく、他に起動に困るデバイスは無い)
・PLoPはUSB1.1/2.0で「USB hubを介さなければ」その先のHDDを起動可能。BIOS Extensionも提供するので、起動されるOSがBIOSに頼っていてもOK。CD起動が基本なんですが、いろんな環境から呼び出せる(grub/lilo/boot.ini等)ので、内蔵HDDのOSから3段bootと選択肢もあり。
・SuperGrubDiskを常用。


どれにも属さないケースとして、緊急時ではないし、BIOSがサポートしていないわけでもないけど、内蔵HDDに変更無しで外部のHDDからbootしたいというのがあります。確実性ならちょっと遅いですがCD、昔ながらのFDなら確実かつ保存が可能(ドライブが付いてなかったらアウト)、お手軽さならUSB-Memoryなんですが本体が未対応だとアウト。
・PLoPをCDかUSBMemoryで利用。CDだとメニューの保存はできません。USB-HDDの拡張があるので、BIOSで対応無くても起動できるかもという可能性があるのが良い点?
・SuperGrubDiskを常用(結構、オールマイティだなぁ)
・GRUB2をCDに入れて使う(ターゲットがLinuxなら他のローダを覚えなくてもよいのは利点?)

「どれにでも便利っ」というのは無い(機能の多さとインストール場所と起動の早さを目的にあわせてバランスを取る必要がある)ので、ターゲットを絞るか、汎用さを目指すのかで結構違ってきますね。個人的には・・・
・緊急の起動ディスクなら、SuperGrubDisk。
・緊急で要件が起動だけではないなら、Knoppix。
・緊急でない起動には、USBサポートの厚いPLoP。
・個人的な趣味は、GAG。ソースが巨大ではないので自分でいじれそうな点が魅力。
あたりでしょうか。

実は、MultiByte文字が苦手っぽいGAGよりも、日本原産のMBMをいじるのが良いのかも。2TBytesを超えるHDDも出てきて、msdos partisionではないものも出てきた今、それらに対応してないと(対応するために開発が継続して行われてないと)、厳しいですね。
このへんの、boot方式やパーティションの管理方式という点だと、grub2の機能がダントツなのかな。PC-BIOS+MSDOS PARTIONに限定すれば、みな土俵に乗ってこれるんだけど。


他、結構いろんなツールやらなにやらあるんですが、ある程度以上の知名度があるか、opensourceで複数の目による確認がなされてないものはリスクの評価ができないので、候補に乗りません。


蛇足。
 正しくはbootstrap codeで「自分の靴紐をもって自分を持ち上げる」(自分自身を起動するためのコード)というあたりから来ているようなんですが・・・肝心なstrapを省略しちゃうと、なにがなんだかという気が少し。

| | コメント (0) | トラックバック (0)

grub2のusbms周りとそれに付随指定調べた情報

 最初に注意点。以下は全て、ソースから読み取ってないようであって、実際の確認は一部しか行っていません。試す前の参考程度や、試した後の確認には使えますが、ここに書いてあるからこの方法を取ろう・・・というのは、わなにはまるかもしれないので注意。

grub2のusb周り。
・サポートしているのは1.1のみ(chipに互換があるので2.0/1.1のハード(chip)でも利用可能。3.0はドライバレベルの互換は無いので不可能。)
・usb.modがモジュールの中心。
・下位にohci.modか、uhci.modのいずれかが必要。echiやxhciは未だ無い。
・上位には、現状ではusb_keyboard(キーボード)と、usbms(大容量記憶装置)がある。
・usbmsはストレージとしてはscsiの下位になる。ディスク名は(usbX)。
 (ちなみに、scsi本家は(scsiX,Y)っぽい)
・ohciやはuhciをロードすると、BIOSからUSBのコントロールを奪う(ohci/uhciが初期化してしまう)形になるようなので注意。結果、BIOS経由でのUSBキーボードは使えなくなる(usb_keyboardを入れれば、そちらは有効になるはず)


grub2のDisk Device
・biosdiskとataは混ぜるな危険。なので自動的に排他されます。
 biosdiskの後からataを入れるとbiosdiskは自動的にunloadされる。
 ataの後からbiosdiskを入れようとするとbiosdiskの初期化の途中で抜け、biosdiskはロードされない(debug messageはあるけどエラーは出ないので注意。lsしてもataしかで無いので首をかしげた・・・。よく考えると、1度制御を奪っちゃうのでata→biosdiskは無理。)
・usbmsは、ataやbiosdiskと混ぜてload可能。が、USB bootをサポートしたBIOSの場合、双方で同一のデバイスを指している可能性があるので注意。ただし、BIOSからのUSB Diskは、(ochi/uhciで初期化されちゃうので)制御から外れる可能性あり。だとすると安全(未確認)
・ataは、ata/atapiを汎用的に制御可能・・・と、すると、IDE互換モードのSATAも制御が可能かも?(未確認)
・AHCIモードのSATAは、今のところ、BIOSを経由する以外には打つ手無し(ahci.modは無い)
 (ehci/xhciやahciは、BIOSの実装が不足していたり、初期に拡張ボードが出回ったりする、過渡期の需要とも考えられるので実装はされないのかも
。古いリソースでがんばろうとすると必要なんですが)
※usb diskを、usbmsとbiosdiskの両方がある状態でsearch系コマンドで全体を通してアクセスしてみて、OKかNGかで判断できそう。

まとめ(の予想)
・usbmsを使いたい場合、usbの基本となるusbと、自分の環境のohciもしくはuhciを指定すること。
 (私の環境では、異なる方のドライバをロードしたらhangupしました。応答時間が長かっただけの可能性もあり。)
・さらに、キーボードがusb接続の場合、usb_keyboardも指定して、入力をconsole/keyboardから変更するのを忘れないこと。
 (たぶん、ps2接続なら必要なし)
・biosdiskは有っても無くても良い。あれば、usb以外のDiskにアクセスが可能になるので、いざというときに楽。

・biosdiskを使わないなら、以下でインストール。
grub-install --disk-module="usbms" --modules="uhci usb usb_keyboard" /dev/sd_

・biosdiskを使う(usbmsと併用)なら、以下でインストール。
grub-install --modules="uhci usb usbms usb_keyboard" /dev/sd_

・以下を設定
/etc/default/grub
GRUB_TERMINAL_INPUT=usb_keyboard

※/etc/default/grubの、GRUB_PRELOAD_MODULESもモジュールを優先的に読み込む機能なんですが、ここでの優先は、core.imgが読めて、/boot/grub/grub.cfgが無事読めてからinsmodで行われる。grub-installに指定するものは、/boot/grub/*を読むのに必要となるモジュールで、grub rescueに落ちても使える。


grub> insmod uhci; insmod usb_keyboard; terminal_input usb_keyboard
grub> insmod usbms

付録。
grub2のdebugメッセージの使い方
・環境変数のdebugを利用する
・環境変数debugは、setコマンドで設定可能(setはgrub rescueでも利用可能)
・デバッグメッセージを表示したい対象をスペースで区切って並べる。
・「all」だと全部。
・大抵のデバイスやパーティションのモジュールは、そのモジュールの読み込み時にいろいろするので、insmodの前にdebugを有効にする。
・対象は基本的にモジュール名(usbms.modなら、usbms)
・grub-installに--debug-imageを指定し対象を指定すると、stage1.5の先頭でset debug=にてその対象が定義され確認デバッグ可能。


probeコマンド
device(driver),partmap,filesystem,fs-uuid,labelは、probeコマンドで指定したデバイス/パーティションの属性を取得可能。
-d driver(debice)の名前を取得
-p partmapの名前を取得
-f filesystemを取得
-u fs-uuidを取得
-l labelを取得
※-sオプションとあわせて使うと、結果を環境変数に設定することが可能。
・・・searchシリーズと似ているような気が?


terminal_inputの設定
キーボードとして扱うモジュールは以下。
・console PC/AT biosのキーボード。grub-pcのデフォルト。
・usb_keyboard grub2のusbモジュールを使用したusb接続のキーボード。
・at_keyboard grub2でPS2接続のキーボードを直接制御。
・serial COMポート。
consoleの最大の利点は、BIOSで使えるよう設定すればPS2でもUSBでも繋がっているほうで使える。

| | コメント (1) | トラックバック (0)

ubuntuのgrub2のLVM over RAID

ubuntuでgrub2での、LVM over RAIDの周りをつらつら眺めていたのでメモに。

 grub2のモジュールのうち、disk deviceとして動作するもののうちのいくつかが、moduleを読み込むときに、その時点の一覧をキャッシュするために、入れ子構造にできるdisk(仮想disk相当)については、入れ子のどこまで見えるかは、modulesを読み込む順序に依存するようです。
# 問題なのは、raidとlvmの2つ。biosdiskは要求されるつどBIOSをチェックするので問題なし。loopbackやmemdiskは任意に定義して使うもので読み込み時点では何もしないので問題なし。

 そのため、grub-mkimgeに渡すmodulesのリスト(元はgrub-installが--modulesとgrub-probeの結果で生成するモジュールのリスト)の順序に依存していそうです。
 もし、これが原因でうまくゆかない場合、「--modulesにて正しい順序で全て明示する」というのが1番のようです。もし、grub-installに頼るなら(大抵はそれで十分のはず)、逆に、--modulesに下手に指定しない ということになります。
# 結果、HDD-RAID-LVMの構成と、HDD-LVM-RAIDの構成を同時に扱えるものは作れません。起動したい環境の/boot(分割していないなら、/)に合わせて、正しく指定する。

 この認識の順序は、grub-mkimageの時点(grub-installの場合は、その中で自動的に実行)で決定され、(grub-setupによって)HDDの先頭領域に書き込まれる為、構成に失敗したgrubのgrub rescueからは、見えなくなってしまったところを認識されるのは困難なようです。
# 先に書いた通り、読み込み時にキャッシュする構造の為に、この順序の問題にひっかかった状態で作成されてアgrubにて、grub rescueの状態からあとから認識させるのは難しそう。そもそも、insmodも使えませんし。

LVM over RAID(RAIDを構成した上にLVMを確保した場合)の場合でmodulesを指定する場合。
grub-install --modules="biosdisk part_msdos part_gpt raid mdraid lvm" '(md0)'
・raidは明示しなくてもOK。mdraidの依存モジュールなので、勝手に直前に追加されます。
・SoftRAIDではないなら、mdraidは要らない。
・part_*の部分は、必要なものだけでOK。
・chainlodaerも含めるなら、「chain」を追加。場所はどこでも。
・ファイルシステムを追加する場合、ext2/3/4は全て、モジュールは「ext2」。名前はext2ですが、ext4まで読めます。ext3とかext4とかの存在しないモジュール名を指定しないように注意。
・あまりいろいろ指定すると、サイズオーバーでエラーになるので、ほどほどに。ここで指定したモジュールは、grub rescueの状態でも読み込まれます。
・インストール先の指定について、RAIDの場合はRAIDの名前で指定する。こうすると、RAIDに属しているHDDにひととおり設定してくれる。昔のGRUBは物理デバイスを指定する必要があった。
・/boot/grub/device.map が正しくないなら、--recheckにて強制的に再作成。

RAIDoverLVM(lvmの論理ボリュームを組み合わせてSoftRAIDを構成した場合)の場合、「raid mdraid」と「lvm」の指定順序を逆にする。

こういった細かい操作の場合、grub-installを使うよりも、grub-mkimageとgrub-setupをそれぞれ用いて、必要最低限のgrub.cfgを自分で設定したほうが楽かも。

| | コメント (1) | トラックバック (0)

GRUB2とPLoPとUSB

 PLoPというのは、いわゆるブートローダ/ブートセレクタと呼ばれるもので、CDやFDなどの起動デバイスや最近であればUSBフラッシュや、HDDのMBRにインストールして使います。
 他のブートローダに対して、以下の点が特徴(たぶん。)
・ここからさらに、CDブートにつなげたり、FDブートにつなげたり、MBRにつなげたりといった、chainが可能。
・USB-HDDをアクセスするBIOS拡張を残したまま、他のローダを呼び出すことが可能。これにより、本来、BIOSがサポートしないUSB-HDDからの起動をサポートしないブートローダでUSB-HDDから起動できる可能性がある。

Ubuntu関連だと、以下のような感じで利用しているケースもあります。
・CD-ROMに、CD起動のPLoPを設定。これを起動に用いる。
・USB-HDDに、Ubuntuをインストールし、GRUBはUSB-HDDのMBRに設定。
・BIOSがUSB-HDDからの起動をサポートしていない場合でも、CDから起動したPLoPからUSB-HDDのデバイスのMBRにchainすることで、Ubuntuを起動する。
この方法は、本体のHDDには、一切、Ubuntuをインストールしていないことと、BIOSがUSB-HDD起動をサポートしていなくても使える という利点があります。

ただ、この便利機能、Ubuntuのローダが9.10から、GRUB2になったときから、起動失敗状態を管理する為に、GRUB2がHDDに値を書き込むようになって、PLoPの拡張BIOSが書き込みをサポートしていない(普通のローダには必要ない)ことが、問題になるように。

ここで、GRUB2。別記事で書いたように、GRUB2はgrub-shまでたどり着いていれば、GRUB2自身がBIOSを経由しないUSBデバイスを参照可能。と、いうことは、mbrと最初のステージを読み込むときにPLoPの提供する拡張BIOSを用いて、その後は自身のusb0とかを経由すればよいんじゃないかと。問題は、任意のタイミングでPLoPの拡張BIOSを外す方法が不明なこと・・・・Dos用のデバイスドライバはあるよなんですが。
あとは、GRUB2のproberで拾ってきた情報はどーしよー・・・・

| | コメント (0) | トラックバック (0)

GRUB-legacyがGRUB2になってのサポートデバイス増加

 Ubuntuの標準のブートローダが、GRUB(grub-legacy)から、GRUB2に変わって、まぁ、大半の人には影響が無く、残る人のうちの大半の人にはmenu.lstの編集による調整ができなくなったという印象しかないっぽいんですが・・・
 実は、機能的にはものすごーく拡張されているので、いろいろなことが出来そうです。☆が、新しい機能。たぶん。
# device syntaxの、(hoge0)で書ける分部。場合によっては、さらに、,nでパーティションを指定する場合もあるけど、それは別。
・昔ながらのhd/fdは、BIOSに対応。CD起動の場合の、cdという名称は無くなったぽいので注意。
☆scsiは、scsi。scsi0とか、scsi1とかになるっぽい。
☆linux raidの場合は、md。md0とかmd1になる。raidのタイプは0,1,4,5,6,10に対応。
 なお、実際に実装されているraid controlerは、nvidiaのraidの0,1,5に対応しているっぽい。
☆USB-HDDは、usb。usb0とかusb1になる。
・memdiskは、memdisk。番号無しの1つだけ。
・ata(IDE)に対して、直接、ataで可能。ata0からata3があるっぽい(BIOSを経由せずPIOで制御?)


以下のものは、他のドライバで参照可能なデバイスに対して効果があるもの。
☆LVMも認識可能。どうも、lvmで付けた名前そのまま使う形っぽい。
☆linux raidの場合は、md。md0とかmd1になる。raidのタイプは0,1,4,5,6,10に対応。
 上にもRaidがあるけど、こっちは、SoftRAID。どっちも、mdになる。
・loopbackは、自分で付けた名前そのまま。複数つくれるっぽい。
・UUID=書式が利用可能。見つかるのはパーティションのような?
・FILE=書式が利用可能。見つかるのはファイルなので、イメージファイルのように扱われるのだろうか・・・?

 これらはあくまでも、grub-shellが起動して始めて使えるようになることに注意。MBRやPBRの1レコード分のところでは、BIOSが用いられるので、注意。つまり、BIOSで指定する起動デバイスとして、使えると言う意味ではない(上記のusb0を用いて、BIOSで参照できないUSB-HDDのMBRから起動できると言うことではない)
 また、予め組み込ませていないデバイスでいろいろ行うには、grub2をインストールしたファイルシステムのモジュール群が見えるようにする必要があるので、それに必要なドライバは、正しく組み込ませる必要がある。

| | コメント (0) | トラックバック (0)

Ubuntu grub2のWindows領域の表示名あたり

 Linuxのディストリビューションの1つ、ubuntuで、2009/10にバージョン9.10が出てきました。このバージョンから、起動に用いている仕組みがgrubからgrub2に変わり、いろいろ、いろいろとあるんですが・・・その中でも、メニューの構成方法が大きく変わっています。
・grub-legacy(以前のgrub。grub1と呼ばれることも。)
 menu.lstというファイルで管理。このファイル内にマーカーとなる行と、コメントの形式で自動生成する項目へのオプションの指定が存在していて、それにより、ubuntuがkernelをアップデートした際などにエントリを書き換える。ユーザ固有のメニューはマーカーの外側に記述する。ubuntu自身以外のOSはインストール時に自動的に作れる以外は、基本的にユーザが指定する。ファイル内のマーカーが認識できなくなると、ファイルを総入れ替えされちゃう。
・grub2
 各ルールファイルと、オプションを指定する為のファイルで管理。最終的にはgrub.cfgというファイルが生成されるが、このファイルはユーザは変更しない(常に生成されなおされる)。ユーザ固有のメニューはルールファイルに追加する形。既存のルールファイルからの生成の制御はオプションで可能。ubuntu以外についても、見つかった全てのHDDとパーティションについて、起動可能っぽいところを、それらしい名称で自動登録する。

この自動登録の際、MS-Windowsの場合には、バージョンも表示するんですが・・・名称が確実では無い(マルチブートやアップグレードやアンインストールしたとき)という問題が。これは、MS-Windows側の構成のされかたに問題があるといえばあるんですが。まず、MS-Windowsの起動まわりから順に説明。
※IPLは、Microsoftのサイトでは「Master Boot Code」と呼ばれる分部になります。MBCだと、MBRと互換が似ているので、この記事ではIPLとしています(IPLは他の用途でも用いられることが多いですが、この記事の中では、IPLをPBRに設定されてOSとして最初に動く分部として定義します。なんか、他に良い語があれば指摘してもらえると)
MS系OSは、シングルブートでは、こんなかんじに起動されます。これは、(起動優先順位が1番高いHDDデバイス内の唯一の)Activeな基本パーティションになっているはずです。
・95/98をインストールすると、IO.SYS+MSDOS.SYSで構成される。
 95/98のカーネル(IO.SYS)の読み込みは、IPLが直接行う。
 bootsectでIPLを戻すことは出来ない(95/98のSYSコマンドを使用する)
 MSDOS.SYSがMS-DOS(の6.3まで)と異なり、テキストの設定ファイルであることに注意。
・NTをインストールすると、NTLDR+boot.iniで構成される。
 NTのカーネルの読み込みはntdetect.comが用いられる。
 bootsectで指定するIPLはNTLDR用なのでNT52。
 なお、NTのNTLDRは、NTFS5を解しないので、2000以降の起動の際は注意。
・2000/XPをインストールすると、NTLDR+boot.iniで構成される。
 2000/XPのカーネルの読み込みはntdetect.comが用いられる。
 bootsectで指定するIPLはNTLDR用なのでNT52。
・WindowsVista/7をインストールすると、bootmgr+BCDで構成される。
 Vista/7のカーネルの読み込みはwinload.exeが用いられる。
 bootsectで指定するIPLはbootmgr用なのでNT60。


ややこしいのは、さらにMS系OSをインストールしてデュアルブートしている場合(後ろの方は失敗しているケースですが)
・95/98系にさらに95/98は・・・試したことが無いので不明。IPLはIO.SYS用。
・NTLDR系にさらにNTLDR系を入れると、単純にboot.iniのエントリが増える。IPLはNTLDR用。
・bootmgr系にさらにbootmgr系を入れると、単純にBCDのエントリが増える。IPLはbootmgr用。
・95/95系にさらにNTLDR系を入れると、95/98のIPLがbootsect.dosというファイルに書き出され、NTLDRからそのファイルを用いるエントリが増える(2段になる)。IPLはNTLDR用。
・95/95系にさらにbootmgr系を入れると、95/98のIPLがbootsect.dosというファイルに書き出され、bootmgrからそのファイルを用いるエントリが増える(2段になる)。IPLはbootmgr用。
・NTLDR系にさらに95/98系を入れると、おそらく、95/98系のOSのインストーラはNTLDRを知らない為、IPLがIO.SYS用に置き換えられてしまい、NTLDRは呼び出されなくなる。
・NTLDR系にさらにbootmgr系をいれると、BCDにNTLDRを呼び出すエントリが作成され、ブートローダが2段になる。IPLはbootmgr用。
・bootmgr系にさらに95/98系を入れると、おそらく、95/98系のOSのインストーラはbootmgrを知らない為、IPLがIO.SYS用に置き換えられてしまい、bootmgrは呼び出されなくなる。
・bootmgr系にさらにNTLDR系を入れると、NTLDRを用いるOSのインストーラはbootmgrを知らない為、IPLがNTLDR用に置き換えられてしまい、bootmgrは呼び出されなくなる。

※ブートローダ(OSの選択画面まで)は、あくまでも、(起動優先順位が1番高いHDDデバイスの)Activeな基本パーティションにインストールされることに注意。インストールの際に選んだパーティションではありません。

grub2では、以下のように判定している模様。あくまでも、パーティション単位で判定されます。
・bootmgrがあり、bootディレクトリがあり、その中にbcdがあると、bootmgr系と判断。
 さらに、見つけたBCDの中にUnicodeで"Windows 7"の文字があると、タイトルを"Windows 7 loader"とする。
 もし、見つけたBCDの中にUnicodeで"Windows 7"の文字がないと、タイトルを"Windows Vista loader"とする。
・NTLDRがあり、ntdetect.comがあると、NTLDR系と判断。
 さらに、boot.iniの各行を解析して、有効な起動が1行しかないなら、default行のオプションを、default行のタイトルでをもってくる。default行のタイトルが使えない(非ASCII文字がある)場合は、タイトルは"Windows NT/2000/XP"とする。
 有効な起動が複数ある場合、"Windows NT/2000/XP loader"と判断(上記とはloaderの付く/付かないに注意)
・dosがあると、タイトルを"MSD-OS 5.x/6.x/Win3.1"とする。
・windowsがあり、その中にwin.comがあると、タイトルを"Windows 95/98/Me"とする。
・どれもちがったら、外れ。

上から順に判定する為、マルチブート環境において複数のファイルやフォルダがある場合には、より上にあるものが表示に用いられる。後から入れたOSのアンインストール(インストールしたパーティションの削除とか)等が無い限り、正しくなっているはず。

grub自身は、MS系のOSについて、個々のOSが起動できるわけではなく、IPLにchainロードする形になるので、明確な場合を除くと"loader"と表記するようです。また、どれ(IO.SYS/NTLDR/bootmgr)を呼び出すIPLなのか というところは見てないので、後から古いバージョンを入れたり、1度他のパーティションに入れた新しいバージョンを消した(そしてIPLを戻した)場合、より優先順位の高いゴミが残ることになり、正しくない情報になる可能性があります。これは、使わないファイルや使えない起動エントリのゴミ掃除すれば誤表示は直るはず。
# 誤表示されるのは、ケースとしては稀かと思うのと、より正確にするには結構な手間が掛かるので、落としどころとしては無難なところ・・・だと思います。はい(これ以上は、IPLの中身を見た上でBCDの中身やboot.iniの中の記述が本当に起動可能な領域を指しているのかどうかも見ないと判らない・・・)。あ、無理せず、「Windows NT/2000/XP Loader」と「Windows Vista/7 Loader」にしちゃえばIPLだけでよいのか・・・

| | コメント (0) | トラックバック (0)

Psystarの次の手(CNET-JPより)

 Psystarというのは、MAC OS Xを、自社で用意したパソコン(notApple)にインストールして販売している会社。Apple社は、MAC OS Xを、Apple社製のコンピュータ以外で実行することを禁止(*)していて(逆は禁止してない)、OS側にもハードウェアをチェックするようなプロテクトがかかってるんですが・・まぁ、それを迂回だか回避して動くようにして売っている と。当然のように、Appleから訴えられている真っ只中なわけですが・・・その真っ只中にまた新たなもを売り始めたよーです。
# (*)おそらく、MAC OSの利用者への許諾条項に、明記されていると思われる。
 今度のは、自分で持っているパソコン(MS-Windows用のもの)にて、MAC OSをインストールして使えるようにするAssistソフトウェアの販売。デモ版と言うか体験版というかも存在していて、購入せずとも、ハードウェアの性能を最大限に引き出せないものの、インストールして動かしてみることは可能とか。

 ものとしては面白いんですが、大きな注意点があって、前者のインストール済みパソコンと違い、ユーザが自身でインストールするということは、「自分で許諾条項に反してインストールを行って使用する(明らかにライセンス違反)」ということに。その禁止条項がほんとに有効かどうか というのを自身で争うつもりがないなら、避けておいた方が無難。
# 争うなら「ユーザの権利を害している」とか「これは抱き合わせの一種だ」とか、なんか理由つけて裁判起こして、勝ち取る必要が。
 以前、iPodやiTuneであったように、アップデートの度に使えなくなる(iTuneはつながらなくなる だが、OSなので起動できなくなる)可能性あるんで、OSを購入して試すにはちょっとリスクが高いような記も。
# Psystarが敗訴したら、絶対バージョンアップされなくなるだろうし。

 まぁ、CNETの記事や、このBLOGの記事も含めて、宣伝にはなってますね。

関連記事
Psystar、今度はMacクローンソフトウェアを発売

関連サイト
Psystar Online Store

| | コメント (0) | トラックバック (0)

マイリストを使ってみる(mixi)

 マイリストは、mixi内で、マイミクでは無いユーザをブックマークする機能・・・の、名前が改定された機能。
# なんでも、「マイ」がつきます。Appleの「i」のようなもん?
 その昔は、ユーザとサークルのどちらも合わせて、「お気に入り」(つまりブックマーク)となっていたのを、人とサークルで分けたもののうちの人の方。人に特化して、「自動マイミク承認」(リストに登録して、かつ、このフラグがONのユーザからマイミク申請があると、自動的に承認される)があるぐらいで、あとは、まぁ、ただのブックマーク。
 なぜにいまさらこんな機能を使っているのかと言うと・・・
 見ての通り、当方のマイミクは少ない(やっと2桁程度)です・・・というか、申請をしてくれた人への承認しかしてないのと、まぁ、もともと人脈もなく、付き合いのあった人も少なかったので。んで、最近ソーシャルアプリで利用していると、基本的にはマイミクのみにちょっかいを掛けられる構成になっているんですが(サンシャイン牧場とか)、たまに、マイミクをずりずりとたどれて直接のマイミクじゃなくてもちょっかいかけられるものがあったりします。そうすると、「あ、この人もmixiのアカウントあったんだ。あとで訪れよう」と思っても、マイミクを申請するほどでもないし、そのままだと、絶対忘れ去ってしまう・・・と言うとき、とりあえずリストにほおりこんでおく と。これで、戦闘可能回数回復時にはレンガでなぐれに行けます(たどれるゲームは、そーゆーゲームです。)

# つい最近、送信済みメッセージを見て、「・・・ああっ、この人居たの忘れれたっ」とゆーのがあったのがきっかけで、リストを利用することに。マイミクだと、たまにでも日記が出るんで判るんですけどね・・・

| | コメント (0) | トラックバック (0)

より以前の記事一覧