Крах кореневої файлової системи

[vanessa]

Залашили вчора наніч один комутер ввімкненим. Вночі пропало живлення, а ДБЖ, звісно, довго не витримав. Коротше він потух, цей комп. А наранок включити ми його просто так не змогли. e2fsck -f -y ну дуже довго колбасив. спочатку пробували без -y но втомились натискати кнопку 'Y' . пасля перезавантаження запустилось наче але ще невідомо що пропало.
Питання: що в такій ситуації робити і як взагалі попередити такі ситуації? Варіант "вимикайте компутер" не підходить.
Чи, як хтось тут писав, робити як справжні джедаї: кореневу файлову систему в режис RO ставити ?

[Михайло Даниленко(Guest)]

А чого там, це не складно. Принаймні, якщо комп'ютер не потребує змін у встановлених програмах та конфігурації.

Оскільки мені це доводилося робити в аварійній ситуації, я просто симлінками загнав /var, /tmp, /home та /srv на /usr/src/LINKED_WRITABLE (там було вільне місце), після чого додав ro до fstab. Здається й усі зміни...

Хоча ще треба перевірити, чи в даному конкретному випадку ніхто не намагається писати до /etc. /etc симлінкувати не вийде, лише його підтеки.

... ага, ще # mv /etc/mtab /etc/mtab- && ln -s /proc/mounts /etc/mtab.

В будь-якому разі ви можете повернутися до rw "на льоту" - # mount -o rw,remount /

P.S. Але все ж таки краще мати під рукою живчик.

[Михайло Даниленко(Guest)]

Можете глянути на http://www.linuxfromscratch.org/hints/downloads/files/readonly_rootfs.txt , хоча воно трохи специфічне й дещо застаріле, наприклад, там ще нема udev, тому /dev кожен раз копіюється до тимчасової фс.

...і ще /root.

[vanessa]

А якщо варіант з монтуванням кореневої файлової системи в режимі РО не підходить то що робити ?
Це ж хвалена ubuntu впала. І, доречі, впала все-таки добряче. вчора на цьому компі збирались ядро перекомпілювати, не встигли. Почали це робити сьогодні, пімсля того як воно падало. а не тут то  й було. gcc матювається File io error на частину файлів із /usr/include.

[Михайло Даниленко(Guest)]

Якщо ups підтримує моніторинг (підозрюю, що ні) - можете спробувати щось на кшталт NUT.

Якщо система під час відсутності наглядачів не дуже багато пише на диск, можливо, може трошки допомогти (принаймні, зменшити вірогідність втрати даних) sync у кронтабі, втім, це вже, НМД, шаманство - коли дані важливі, краще нормальний ups...

[vanessa]

Та долампочки всі ті дані. компро просто стояв, із всіх програм, які на ньому в цей час виконувались був тільки скрінсейвер.  і це мене більше всього якраз хвилює що нічого не робилося, а піднятися він нормально незміг

[cadca]

Є підозра, що з компом ще щось сталося крім запущеного скрінсейвера - про такі пошкодження кореневої файлової системи перший раз чую. Тьфу-тьфу-тьфу...
/me стукає по дереві/лобі

За аналогічних обставин пошкоджувалась тільки /home і то не сильно.

А скрінсейвер не від рута був запущений

[Михайло Даниленко(Guest)]

А невідомо, коли саме це сталося? бо приблизно о шостій ранку Деб'ян починає щось активно робити.

Хм. Якщо трапляються i/o errors - значить треба перевіряти ще раз.

[Михайло Даниленко(Guest)]

Хм. Якщо трапляються i/o errors - значить треба перевіряти ще раз.

Або (тук-тук-тук) # badblocks /dev/hd...

[vanessa]

Або (тук-тук-тук) # badblocks /dev/hd...

нажаль коли це сталося вже немає можливості подивитись, мій колега, а це на його компі сталося, довго не думаючи перевстановив систему. але на той-же /dev/hd так що це точно не тут проблема.

Хм. Якщо трапляються i/o errors - значить треба перевіряти ще раз.

а які ще корисні параметри у команди e2fsck  є ?