Заставить fsck терпеть неудачу при загрузке
Я работаю на встроенном устройстве Debian Linux. Из-за отключения питания в любое время, которое приводит к внезапной потере питания, мы установили FSCKFIX с "нет" на "да" в файле /etc/default/rcS. Без этого я столкнулся с ошибками, когда система переходит к терминалу, ожидающему, пока пользователь (в последовательном режиме) вручную запустит fsck для восстановления диска (так как устройство не имеет терминала в нормальной работе, это эффективно блокирует окно). Также карта была сделана RO, будучи перемонтированной RW по мере необходимости для обновлений, но это не связано с моей проблемой, я не думаю.
Я пытался сделать модульный тест для этого, который повредит SDCard, тогда мы должны быть в состоянии вставить карту обратно во встроенное устройство, и она должна восстановить и загрузить себя как обычно.
Изначально меня интересовало только надежное создание сбоя, который я иногда вижу с FSCKFIX= нет, т.е. переход на терминал для исправления карты вручную через fsck. Я попробовал предложения здесь и здесь, но эти методы либо делают карту полностью не загружаемой, либо кажутся игнорируемыми / исправленными, и система загружается нормально, не выводя меня на терминал для запуска fsck. Таким образом, мне кажется, что нужно повредить диск очень специфическим способом, чтобы fsck потребовал ручного вмешательства с помощью FSCKFIX=no. Может кто-нибудь сказать мне, как это сделать????
Приветствия.
1 ответ
Хорошо, так технически я получил свой ответ от той ссылки, которую опубликовал Iain (ура!), Мне просто нужно было увеличить счетчик и убедиться, что я вызвал e2fsck с опцией -f & -F, а также -p, чтобы fsck увидел проблему.
sudo dd if = / dev / zero = = dev/mmcblk0p4 bs=1 счет =4096 поиск =10000; синхронизировать sudo e2fsck -f -F -p /dev/mmcblk0p4; echo $? /dev/mmcblk0p4: изменение размера inode недействительно.
/ dev / mmcblk0p4: НЕОЖИДАННАЯ НЕПРЕРЫВНОСТЬ; ЗАПУСТИТЕ fsck ВРУЧНУЮ. (т.е. без параметров -a или -p) 4
Хотя это дало мне результат, который я искал (обанкротившаяся SD-карта), мне бы очень хотелось узнать, как fsck на самом деле обнаруживает, что раздел ext3 поврежден, когда он не использует контрольные суммы данных, и если он использует журнал, то как это работает для журналов ext2 или ext3 wo?
Ура снова