301 Moved Permanently

Moved to https://vow.g.hatena.ne.jp/vow/

4207869677

てぬき

(続き)

この忙しいときに限って露店留守番機がお亡くなりになる罠。普通なら代替機を新規構築するところだけど、今回は時間がなかったので手抜きをして、HDDを引っこ抜いて新しい機体にそのまま移植してみた。まあ特段に目新しい話もないのだけど何となくへろっとメモっておく。なお以下はNT5系での話であって7とかには当てはまらない。

  • 起動ディスクまでの経路のデバイスが変化する場合はそのままでは起動できない。この状態から回復するにはレジストリの編集とドライバのファイル追加が必要である。
  • 今時のACPIなPCであれば基本的にはHALの非互換が原因で起動不可に追い込まれるることは無いが、やられた場合には boot.ini の編集とHALのファイル追加が必要である。

移植元の機体の損壊が激しく既に再起不能な場合には外で編集するしかないが、まだ稼働可能な状態であれば事前にこれらの準備をしてから移植すればすんなり起動させることができる。念のためハードウェアプロファイルを複製してから作業にかかれば幾分安全であろう。なおNICがOS標準ドライバで動かないものに変わる場合は、移植後に起動できても陸の孤島っぽい状態になるので、ついでにインストール用のファイルを先にディスク上に用意しておくと楽である (インストール自体は移植先で起動してからで良い)。

最初に起動ディスクまでの経路のデバイスに関して。ATAディスクの場合、コントローラとIDEチャネルがこれに該当する。といってもチャネルのドライバはチップセットに依存せず共通なので気にする必要はない*1。また常識的なPCIチップセットIDEコントローラならば標準のPCIIdeで最低限の稼働は可能なので、とりあえず移植先のチップセットが何であってもPCIIdeにしてしまえばよい。

まず system32\driverspciide.syspciidex.sys のいずれかが欠けていれば expand して追加し、その上でPCIIdeをサービス登録する。

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PCIIde]
"ErrorControl"=dword:00000001
"Group"="System Bus Extender"
"Start"=dword:00000000
"Tag"=dword:00000003
"Type"=dword:00000001
"ImagePath"=hex(2):53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,44,00,\ 
52,00,49,00,56,00,45,00,52,00,53,00,5c,00,70,00,63,00,69,00,69,00,64,00,65,\ 
00,2e,00,73,00,79,00,73,00,00,00

さらにチップセットの PnP ID からPCIIdeサービスに紐付けする。(XXXX は移植先のコントローラの PCI ID)

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase\pci#ven_XXXX&dev_XXXX]
"ClassGUID"="{4D36E96A-E325-11CE-BFC1-08002BE10318}"
"Service"="pciide"

とにかく移植先でひとまず起動さえしてしまえば、後はPnPで普通にベンダ固有ドライバを拾えるので、細かいことを気にする必要はない。

HALの不適合により起動しないことがわかっている場合は、system32 に正しい halXXXX.dllexpand して追加しておき、boot.ini で起動オプションに /hal=halXXXX.dll を指定してオーバーライドする。ただし最低限の起動に支障がない限りはHALのオーバーライドは避けておいた方が間違いが少ない。ひとまず起動さえしてしまえば正面から デバイスマネージャ>コンピュータ で変更することができる。

シングルプロセッサな移植元の機体でPICっぽいHALが稼働していた場合、マルチプロセッサな移植先でPnPが完了してもシングル動作のままとなる*2。NT5.1以降でこの状態になるとデバイスマネージャがAPIC系のHALを選択肢として提示してくれないので表から切り替えることは不可能である。この場合は前述のHALのオーバーライドを用いて一旦 ACPI ユニプロセッサ PC、つまり halaacpi.dll で起動するのが正しい。すると直ちにPnPにより自動的にカーネルごとマルチプロセッサで再構成されるので、HALのオーバーライドを解除してから再起動すれば切り替えが完了する。HALのオーバーライドでHALだけマルチプロセッサにしてもカーネルが切り替わらずハマり状態に陥るので注意。

ここまででそれなりに起動するようになったら、移植元で使われていた不要なドライバを登録抹消する。まあぶっちゃけると掃除なんかしなくてもいうほど問題はないのだが、起動するたびに開始できなかったサービスが云々と文句を言われる場合は掃除をしたほうが良いだろう。アンインストーラのあるドライバはまずアンインストールを試み、次に環境変数 DEVMGR_SHOW_NONPRESENT_DEVICES1 に設定してから デバイスマネージャ>非表示のデバイスの表示 を使って非実在バイスを抹消する。一部の非PnPなドライバサービスはなぜか消しても消しても再起動すると復活する謎状態になることがあるので、その場合はレジストリエディタで HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services から当該キーを直接抹消すると良い。

Prefetcherの再スキャンはタスクスケジューラを停止→Prefetchの中身を抹消→再起動後2分放置→タスクスケジューラを起動→.pfができるのを待つ→ rundll32 advapi32.dll,ProcessIdleTasksLayout.iniができるのを待つ→タスクスケジューラはもう止めても良い。


まあそんなこんなで水面下ではモゾモゾしているのです。もう少しです。

だといいなあ。

*1:移植元が純SCSI環境でSDAT変換にぶら下がっていたATA玉を剥いて移植先でIDEに直結するとかいうような変態的場合を除く

*2:この時点でデバイスマネージャ上のCPUは既に2個になっているが実際には稼働していない