最近の変更サイトマップ

FreeBSD 11-STABLEでVirtualBox復活(`・ω・´)

3回に渡ってお送りしてきたFreeBSD 11.0-RELEASEでkern.proc.pathnameに失敗してVirtualBoxが動かない問題だが、無事解決。予想通り11-STABLEで問題なく動いた。

うちのデジタルデータ保管を一手に担っている結構重要な家鯖だし、STABLEを追いかける元気もないので、早いところ11.1-RELEASE出ないかしらー。これまでのマイナーリリース間隔から見るに、まだまだ先っぽいけど……。

FreeBSD 11.0RでZFSの特定プロパティ条件下でkern.proc.pathnameが失敗する

FreeBSD 11.0-RELEASEでVirtualBoxが起動しない問題、もといKERN_PROC_PATHNAMEのsysctlに失敗するのは、どうやらZFSが原因っぽい。ZFSのcasesensitivityないしnormalizationプロパティがデフォルト値以外になっていると、VFS絡みでうまく動かない模様。うちはnormalization=formCにしてるので、どう見てもこいつのせいです。本当にありがとうございました。

幸い、既にパッチが投稿されており、10/7付けでstableにも取り込まれているので11.1では直ると思われる。

が、それまでVirtualBoxが使えないのは地味に辛いなぁ。うちの環境では今のところVirtualBoxしか表面化してないけど、割と影響受けるソフト多いんじゃないかしら?久々にカーネルを自前ビルドしてみましょうかね。

参考サイト

FreeBSD 11.0RにしたらVirtualBoxが動かなくなった(´・ω・`)

先日、家鯖をFreeBSD 11.0-RELEASEに更新してからVirtualBoxが動かなくなった。起動しようとするとVirtualBox: supR3HardenedExecDir: sysctl failedとエラーを吐いて終了する。sysctlに失敗するってどういうこっちゃ。

当該ソースはSUPR3HardenedMain.cppの1243行目付近で、VirtualBox自身の実行ファイルパスを取得してる部分。

# else /* RT_OS_FREEBSD */
    int aiName[4];
    aiName[0] = CTL_KERN;
    aiName[1] = KERN_PROC;
    aiName[2] = KERN_PROC_PATHNAME;
    aiName[3] = getpid();
 
    size_t cbPath = sizeof(g_szSupLibHardenedExePath);
    if (sysctl(aiName, RT_ELEMENTS(aiName), g_szSupLibHardenedExePath, &cbPath, NULL, 0) < 0)
        supR3HardenedFatal("supR3HardenedExecDir: sysctl failed\n");
    g_szSupLibHardenedExePath[sizeof(g_szSupLibHardenedExePath) - 1] = '\0';
    int cchLink = suplibHardenedStrLen(g_szSupLibHardenedExePath); /* paranoid? can't we use cbPath? */
 
# endif

何の変哲もないコードだし、特に最近変わったような雰囲気もない。原因切り分けのため、上記コードと同じ事をする簡単なテストコードをでっちあげて実行してみたら、同じように失敗する。

#include <sys/param.h>
#include <sys/sysctl.h>
#include <stdio.h>
 
int main(void)
{
    int pid = getpid();
    int mib[4] = { CTL_KERN, KERN_PROC, KERN_PROC_PATHNAME, pid };
 
    printf("pid = %d\n", pid);
 
    size_t bufSize = 1024;
    char buf[bufSize];
    int result = sysctl(mib, 4, buf, &bufSize, NULL, 0);
    if (result < 0)
    {
        perror("sysctl");
    }
 
    return 0;
}
-------- 実行結果 --------
$ ./sysctltest
pid = 66245
sysctl: No such file or directory

supR3HardenedExecDirでググるとprocfsをマウントし忘れてんじゃね?という投稿が出てくるが、今回の問題箇所はprocfsを不要とするための部分なのでprocfsをマウントしようがしまいが変わらない(大体今までprocfsマウントしてなくても動いてたし…)、と思いつつ藁をも掴む思いでマウントしてみたけど、やっぱり何の解決にもならなかった\(^o^)/

portsでソースからのインストールも試みたけどビルドがコケるし、もぅマヂ無理。リスカしょ…。

参考サイト

FreeBSDでVirtualBoxを動かしていると巨大ファイルの転送でCannot allocate memoryが出る

FreeBSD 10.1-RELEASEな自宅ファイルサーバからMacにファイルをコピーすると「予期しないエラーが起きたため、操作を完了できません(エラーコード -50)。」が発生してコピーに失敗する現象に長らく苦しめられていた。経験的にファイルサイズが大きいほど発生確率が高く、数百MBくらいまでのファイルなら問題ないが、2GBを超えるとまずアウトっていう。鯖→Macの場合AFP(Netatalk 3.1.7)でもCIFS(Samba 4.2.5)でも発生し、鯖→Windowsの場合は言うまでもなくCIFSしか使えないが、所々詰まりながらも一応成功するといった具合。

失敗時はNetatalkのログに「Cannot allocate memory」が必ず記録されている。発生場所は大体{fork.c:913} (error:AFPDaemon): afp_read{dsi_stream.c:424} (error:DSI): dsi_stream_read_fileのどっちか。メモリたんねーと言われましても、32GB積んでるtopで見ても余裕のよっちゃんイカで数GBレベルで残ってますし…。もう全くわけがわからないよ!本格的に原因を探ろうとsshで各種情報をモニタリングしながらコピーしたら、今度はsshdまでCannot allocate memory吐いて接続切れるし……。

ドライバの不具合?NIC/L2SW由来の不具合??もしかしてケーブルが腐ってる???などなど、疑心暗鬼ロードを爆走していたが、ようやく、ついに!遂に!!原因がわかったッ!!!!

犯人はヤス何とVirtualBox VirtualBox実行中はnetgraph関連のメモリが不足しやすく?なるっぽい。ここここで同症状が報告されており、/boot/loader.confnet.graph.maxdata=65536を追加すればおkと書いてあった。

このカーネルパラメータはnetgraphのデータキューの最大確保数を表すものらしい。同様に非データ用のnet.graph.maxallocなんてのもある。それぞれ/usr/src/sys/netgraph/ng_base.cで定義されていて、コメントが若干怖いことが書いてあった。

static int maxalloc = 4096;/* limit the damage of a leak */
static int maxdata = 512;  /* limit the damage of a DoS */

下手に大きくすると問題発生時に被害が拡大しそうな雰囲気。ま、外部公開してなきゃそんなに気にしなくてもいいだろうけど。

ついでにdmesgLimiting open port RST response from 208 to 200 packets/sec.なるログも出ていたので、/etc/sysctl.confに以下を追加。

net.inet.icmp.icmplim=2000

肝心のloader.confも一応。

net.graph.maxdata=65536
net.graph.maxalloc=65536

上記設定で1~6GBほどのファイルを100GB分くらいコピーしてみたら、何の問題もなく完了した。普通に動くって素晴らしい。

参考サイト

家鯖をESXi 5.1U2からV2P, V2Vマイグレーション

家鯖をESXiによる仮想サーバから物理サーバにマイグレーションする事にした。

ESXi上で動いているのはFreeBSDとWindows 7の2つ。元々FreeBSDが物理的に動いていたが、Windowsで録画鯖を作ろうと思ってESXiを導入したという経緯がある。結局、nasneを買っちゃったし、そもそも元からテレビを見ないという致命的な不具合(笑)が発覚したので、録画鯖を仕立てる理由もなくなってしまった。ESXiの雲行きも怪しいし、良い機会なのでV2Pしちゃおうと考えた次第。

FreeBSDは物理サーバ時代からのHDDを全てRDM&PCIパススルーで動かしてた為、マイグレーションもへったくれもない。ESXiのUSBメモリを引っこ抜けば、何もしなくてもBSDが起動する素敵仕様。V2Pいっちょあがりっと。

Windowsの方はFreeBSD上のVirtualBoxにV2Vする事にした。録画鯖にはならなかったものの、PS Vitaのコンテンツ管理アシスタントのホストになってたり、巨大な

エロ動画

ファイルのダウンロードとかで地味に役立つので。こっちは少し苦労したため、作業内容をメモっておく。

ESXiのWindows 7をVirtualBoxにマイグレーション

ファイルのコピー

まずはESXiのデータストアからファイルを取り出さない事には始まらない。色々やり方はあると思うが、今回はクライアント側からscpで転送した。

$ scp -rp root@esxiserver:/vmfs/volumes/path_to_datastore/Windows/ esxi_save/
Password:
Windows.vmx                                   100% 3142     3.1KB/s   00:00
Windows.vmxf                                  100%  262     0.3KB/s   00:00
Windows.vmsd                                  100%    0     0.0KB/s   00:00
Windows.nvram                                 100% 8684     8.5KB/s   00:00
vmware-36.log                                 100%  202KB 202.1KB/s   00:00
Windows-flat.vmdk                             100%   40GB  42.9MB/s   15:55
Windows.vmdk                                  100%  494     0.5KB/s   00:00
vmware-35.log                                 100%  202KB 201.6KB/s   00:00
vmware.log                                    100%  311KB 311.1KB/s   00:00
vmware-31.log                                 100%  176KB 175.8KB/s   00:00
vmware-32.log                                 100%   51KB  51.4KB/s   00:00
vmware-34.log                                 100%  202KB 201.9KB/s   00:00
vmware-33.log                                 100%  180KB 180.2KB/s   00:00

VirtualBoxに仮想マシンを作成

VMの詳細は割愛。

ストレージは既存の仮想ディスクを使う。上で転送したファイルで言えばWindows.vmdkを選択する。

接続するバスは、とりあえずESXiで使っていた物と同じのにして、Windowsが起動するか試してみる。正常に起動すれば後は何もする必要はないが、十中八九「Windowsを起動しています」の画面で“STOP 0x0000007B”ブルースクリーンが出て死ぬ。その時は、接続バスを好きなものに変えて(もちろん変えなくてもいい)、次の対策を行う。

“STOP 0x0000007B”対策

“STOP 0x0000007B”ブルースクリーンが出てWindowsを起動出来ない時は、レジストリを修正する必要がある。

  1. VM起動時にF8連打でWindowsの「詳細ブートオプション」を表示し、「コンピュータの修復」を選ぶ。コンピュータの修復が表示されていなければ、修復用のシステムがインストールされていないって事なので、WindowsのインストールCDから同等の事をする(詳細はググってくだしあ)。
  2. システム回復オプションのログイン画面が出るので、正常に動いてた時のアカウントでログイン。
  3. コマンドプロンプトを起動。
  4. コマンドプロンプトで「regedit」と打ち、レジストリエディタを起動。
  5. レジストリエディタの「HKEY_LOCAL_MACHINE」または「HKEY_USERS」を選択した状態[ファイル]>[ハイブの読み込み]を選択。
  6. d:\Windows\System32\config\SYSTEM を開く。
  7. マウントポイント名を聞かれるので、適当にattachedなどと入れる。
  8. attachedにSYSTEMレジストリが読み込まれるので、CurrentControlSet\servicesControlSetNNN\servicesの中にある下記リスト内の「Start」の値を0にする。ノードが存在しなければ飛ばしてOK。
    • aliide
    • amdide
    • atapi
    • ataport
    • cmdide
    • intelide
    • LSI_SAS
    • LSI_SAS2
    • LSI_SCSI
    • megasas
    • MegaSR
    • msahci
    • pciide
    • pciidex
    • viaide
  9. レジストリエディタ、コマンドプロンプトを終了し、再起動。

以上でマイグレーションしたWindowsが正しく起動するハズ。

参考サイト

start.txt · 最終更新: 2016-05-07 17:46 by decomo
CC Attribution-Noncommercial-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0