這個標題聽起來有點聳動
不過看了以下敘述，便之所言不假…

kmd.twbbs.org 這台主機的作業系統本來是原生的 FreeBSD
版本從 4.6 一路走到 4.12，後來又升級到 6-STABLE (6.1~6.3)

本次事件的主角，就是這台主機的系統碟

近一年來，為了使這台機器的硬體達到最佳使用率
(其實就是嫌 SETI@home 在 FreeBSD 底下跑的不夠快，一切都是為了 BOINC crunching 啊!!)
便將閒置的 80G 硬碟裝了上去，並安裝 Windows XP x64
原 FreeBSD 的硬碟則不做更動，保留開機方式的彈性，選擇有二：
1. 搭配 VMware 以虛擬機器掛載實體硬碟開機
2. Host machine POST 時，直接由實體硬碟開機，而不經過 Windows

話說 VMware 對 guest VM 的硬碟存取模式可分為兩種
一種是磁碟映像，另一種則是實體硬碟：
前者的好處是徹底虛擬化，虛擬磁碟存取的對象其實只是個映像檔
道理有點像 Alchol 120% 或 Daemon Tools 這一類的虛擬光碟
只是多了寫入的功能，模擬的對象改為虛擬機器中的硬碟
後者則由於直接存取系統裝置，在磁碟效能部分有明顯優勢

以上兩種模式本無太大缺點
但 VMware 對儲存媒體的存取機制，是 lock then commit (write)
當錯誤發生時 (通常是裝置停止回應，或是意外終止 VMware)
對前者而言，頂多是映像檔內容沒有更新
但對後者，就容易發生 MBR 遺失的狀況

這次的意外，就是發生在這樣的情境
套一句鄉民時興的話：『沒想到真的發生在我身上!!』
結果就是：

Damn!! VMware kills my HDD/MBR!!

照理說，內部資料原封不動，只是磁碟分割 (disklabel/bsdlabel & slice) 資訊遺失
要救回來只要用 disklabel 重新指定分割方式即可
問題是百密總有一疏
原先分割方式早已遺忘，更沒有檔案紀錄，情況才會顯得如此驚險

詳細的救援情形，請看下一篇 “Disklabel Recovery under FreeBSD: Using scan_ffs”