Mounting root filesystem from /dev/ad0s1a...
Fatal trap 12: page fault while in kernel mode

И через 15 секунд машина уходила в ребут, после чего все повторялось. Попытки загрузиться в сингл-юзер и сейфмод ничего не дали. Тихо матерясь, лезу втыкать сд-привод в сервер. Гружу лайв-сд Frenzy BSD. При загрузке вбиваю параметр nohdmnt (мало ли что). Далее, делаю mount /dev/ad0s1a /mnt/ad0s1a.ufs… и система падает в тот же 12й трап с 15-секундным ребутом.
Охренев от такого поворота событий, гружу френзи заново, на этот раз без параметров. К моему удивлению, теперь проблемный раздел смонтировался, но с таким варнингом:


/mnt/da1s1a.ufs: bad dir ino 2 AT OFFSET 512: MANGLED ENTRY

Ага, значит падает только при маунте его в read-write. Уже что-то. Гугление вывело на солюшен. Вкратце: затираем проблемный инод вручную с помощью fsdb, далее проходим fsck -y. Сделал. Попробовал смаунтить в rw… получилось. Однако, на смонтированном разделе вместо привычного корневого дерева каталогов я увидел лишь одинокий lost+found. Тихий мат незаметно перешел в громкий.
От безысходности решил порыться в lost+found. Ага, вот они, данные. Только вместо привычных usr, bin, home и т. д. имена каталогов имели вид #2260992. Пришлось создавать каталоги вручную, на глаз определять, что где лежало, и переносить на место.
Нюанс: права на /tmp должны быть 666. Поскольку дерево воссоздавалось от рута, права на корневые папки, соответственно, ставились rw-r—r—. Обнаружил, когда по этой причине отказался стартовать mysql.
После проделанных манипуляций, система загрузилась как положено. Чтобы обезопасить себя от таких сюрпризов в дальнейшем, решил прикрутить к серверу интерфейс ИБП для корректного отключения. Об этом — в следующий раз.

Вообще, странно — NTFS за всю мою практику никогда не падал намертво всего лишь из-за какого-то сбоя питания. Неужели фряшная UFS настолько ненадежная?