Выхлоп strace -- в студию. Точнее,

strace -f fsck -n /dev/то-самое-устройство

Дома посмотрю... Там дело в том, что раздел вместо ext3 волшеюным образом стал ntfs, да ещё и кривым (нечитающимся ни виндой, ни линуксом). Решил восстановить по давным-давно упоминавшейся здесь методике. fdisk прошёл, а fsck не получается :(

Да вполне может оно быть и занятым...

> девайс никак не может быть бизи - выдаётся мне это и при init=/bin/bash,
> и при загрузке с live-cd.

А б-г его знает, что там у этого liveCD initramfs творит... Некоторые особо
"умные" пытаются подмонтировать всё, что шевелится, а что не шевелится,
пошевелить и подмонтировать. И обвинить-то их сложно: им надо искать, где
образ находится (а иначе юзер должен будет указать root=blah-blah, а это
как-то не очень кошерно).

Потому вопрос: что будет, если сначала загрузиться, а потом устройство
подключить (если это возможно, конечно)?

> Там дело в том, что раздел вместо ext3 волшеюным образом стал ntfs,

Тут мне товарищи, использующие ext3, подсказывают, что иногда e2fsck тупит,
если не может прочитать основной суперблок. Тупость выражается в том, что
вместо того, чтоб честно пожаловаться, e2fsck выдаёт всякие идиотские
сообщения, одно из которых -- device or resource busy.

Потому запустите-ка

tune2fs -l /dev/то-самое-устройство

Если ругнётся -- наверняка запорот суперблок, и надо пользоваться резервными.

>А б-г его знает, что там у этого liveCD initramfs

Debian Lenny installer beta2 - достаточно кошерен?

Не. Съел, не подавился. Собственно, мануал по восстановлению: http://www.linux.org.ru/view-message.jsp?msgid=2588277

кусок strace: strace -f e2fsck -b 23887872 /dev/hda1

tat64("/dev/hda1", {st_mode=S_IFBLK|0660, st_rdev=makedev(3, 1), ...}) = 0
open("/dev/hda1", O_RDONLY|O_EXCL) = 4
close(4) = 0
open("/dev/hda1", O_RDONLY|O_EXCL|O_LARGEFILE) = 4
_llseek(4, 24461180928, [24461180928], SEEK_SET) = 0
read(4, "\337 \226;F\273\210\2\240\315\227\240\223\245\"\261^\376"..., 1024) = 1024
open("/dev/hda1", O_RDONLY|O_EXCL|O_LARGEFILE) = -1 EBUSY (Device or resource busy)
open("/dev/hda1", O_RDONLY|O_EXCL|O_LARGEFILE) = -1 EBUSY (Device or resource busy)
open("/dev/hda1", O_RDONLY|O_EXCL|O_LARGEFILE) = -1 EBUSY (Device or resource busy)
open("/dev/hda1", O_RDONLY|O_EXCL|O_LARGEFILE) = -1 EBUSY (Device or resource busy)
open("/dev/hda1", O_RDONLY|O_EXCL|O_LARGEFILE) = -1 EBUSY (Device or resource busy)
open("/dev/hda1", O_RDONLY|O_EXCL|O_LARGEFILE) = -1 EBUSY (Device or resource busy)

Как-то он странно себя ведёт. Сначала открыл, потом не открыл...

В потолке открылись люки...

> stat64("/dev/hda1", {st_mode=S_IFBLK|0660, st_rdev=makedev(3, 1), ...}) = 0
> open("/dev/hda1", O_RDONLY|O_EXCL) = 4
> close(4) = 0
> open("/dev/hda1", O_RDONLY|O_EXCL|O_LARGEFILE) = 4
> _llseek(4, 24461180928, [24461180928], SEEK_SET) = 0
> read(4, "\337 \226;F\273\210\2\240\315\227\240\223\245\"\261^\376"..., 1024) = 1024
> open("/dev/hda1", O_RDONLY|O_EXCL|O_LARGEFILE) = -1 EBUSY (Device or resource busy)

Глупо он действует. Открыл устройство с O_EXCL, а потом ещё раз пытается
его открыть. Естественно, что ядро пошлёт лесом. В общем, нужно пинать
автора (или дистроклепателей, если версия старая). А чтоб данные вытащить,
сбросьте на другой диск:

dd if=/dev/hda1 of=/где/много/места/hda1.img bs=512

и натравите e2fsck на образ.

Рутовый-то раздел он через каждые 30 загрузок проверяет, и ничего. Чудеса какие-то.

Ладно, поставлю вечером ещё один хард... всё равно уже две недели лежит, руки не доходят привинтить :)

>дистроклепателей, если версия старая

Только вчера в сиде обновилась :) 0.1.41 или как-то так. В общем, 41 :)

Не волнуйтесь, это глюки, так бывает иногда.

> Только вчера в сиде обновилась :) 0.1.41 или как-то так. В общем, 41 :)

Тогда сохраняйте мета-данные:

e2image -r /dev/hda1 dumpe2fs | bzip2 -9 > hda1.e2image.bz2

и пинайте автора (он заодно и maintainer пакета):

reportbug --severity normal e2fsprogs

Нужно вписать:

1. Выхлоп

LC_ALL=C e2fsck /dev/hda1

2. Тот самый strace

3. Объяснить, что проблема именно с проверкой ФС, которая живёт на "настоящем"
блочном устройстве.

У Вас могут попросить образ с мета-данными. Если названия файлов и директорий
не засекречены, лучше таки послать его.

> Рутовый-то раздел он через каждые 30 загрузок проверяет, и ничего.

Видать, не обрабатывает (или неправильно обрабатывает) какую-нибудь ошибку, которая бывает только при каких-то уж очень изощрённых повреждениях.

Глаза не видят, руки делают.

> e2image -r /dev/hda1 dumpe2fs | bzip2 -9 > hda1.e2image.bz2

Фигню написал. Правильно так:

e2image -r /dev/hda1 - | bzip2 -9 > hda1.e2image.bz2