Автор Тема: RuntuLite10.04 с LiveCD не может проверить на ошибки ex4 на винте  (Прочитано 6177 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн vovchok

  • Постоялец
  • ***
  • Автор темы
  • Сообщений: 198
RuntuLite10.04 (свежая) перестала загружаться (ругается на initramfs). Загрузил ее же с LiveCD и запустил проверку на ошибки раздела ext4 (кроме него на винте лишь подкачка), но "e2fsck -f -y -v /dev/sda1" ругается "Устройство или ресурс занято при попытке открыть /dev/sda1", а "mount /dev/sda1" выдает "невозможно найти /dev/sda1 в /etc/fstab или /etc/mtab".
Точно такая же ситация описана здесь, вот только решение не найдено: http://forum.lissyara.su/viewtopic.php?f=47&t=31871
С железом все в порядке.

С этим как-то можно бороться, или таких глюков нужно ожидать на других компах тоже и не надеяться на сохранность информации в ext4 разделах?

Оффлайн HsH

  • Administrator
  • *****
  • Сообщений: 3468
но "e2fsck -f -y -v /dev/sda1" ругается "Устройство или ресурс занято при попытке открыть /dev/sda1",
   Что скажет эта команда?
sudo fsck -f /dev/sda1
   Дайте вывод
sudo blkid
sudo fdisk -l

"mount /dev/sda1" выдает "невозможно найти /dev/sda1 в /etc/fstab или /etc/mtab".
    Команда mount должна знать, что и куда монтировать. Если не указана точка монтирования, которая по-умолчанию есть в fstab, нужно задать её в явном виде, например
sudo mount /dev/sda1 /mnt
С этим как-то можно бороться, или таких глюков нужно ожидать на других компах тоже и не надеяться на сохранность информации в ext4 разделах?
    Не совсем понятна суть ваших опасений. Произошедшему предшествовала ситуация, которая привела к обозначенному поведению?

Оффлайн vovchok

  • Постоялец
  • ***
  • Автор темы
  • Сообщений: 198
Что скажет эта команда?
root@Runtu:/home/runtu# sudo fsck -f /dev/sda1
fsck from util-linux-ng 2.17.2
e2fsck 1.41.11 (14-Mar-2010)
fsck.ext4: Устройство или ресурс занято при попытке открыть /dev/sda1
Filesystem mounted or opened exclusively by another program?
root@Runtu:/home/runtu# sudo blkid
/dev/loop0: TYPE="squashfs"
/dev/ramzswap0: TYPE="swap"
/dev/sda1: UUID="3104593c-4f85-4475-a2fe-cc5072e71a6d" TYPE="ext4"
/dev/sda5: UUID="1c958b00-843f-4ebc-949d-ca72e3c43492" TYPE="swap"
root@Runtu:/home/runtu# sudo fdisk -l

Диск /dev/sda: 41.1 ГБ, 41110142976 байт
255 heads, 63 sectors/track, 4998 cylinders
Units = цилиндры of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0000851a

Устр-во Загр     Начало       Конец       Блоки   Id  Система
/dev/sda1   *           1        4907    39412736   83  Linux
/dev/sda2            4907        4998      731137    5  Расширенный
/dev/sda5            4907        4998      731136   82  Linux своп / Solaris

Произошедшему предшествовала ситуация, которая привела к обозначенному поведению?
Мне не понятно почему так, но на десяток компов у меня есть две мамки (i810 и via под Celeron800), на которых абсолютно стабильно работала win98, но все версии RuntuLite виснут мертво в самые непредсказуемые моменты (может не зависать несколько дней, а может виснуть по нескольку раз в час) - останавливается движение мыши и индикатора загрузки процика, после чего только reset.  В результате очередного сброса юзером такого зависшего компа я поимел эту тупиковую пока ситуацию. Установка винта на другой комп тоже не помогла.
Не совсем понятна суть ваших опасений.
Если возможна ситуация, в которой после reset к информации на разде ext4 при живом винте нельзя никак подобраться, то доверять ему важную информацию весьма рисковано...
« Последнее редактирование: Апрель 03, 2013, 18:23:20 от vovchok »

Оффлайн Fastor

  • Постоялец
  • ***
  • Сообщений: 143
vovchok, а /dev/sda1 точно не примонтирован в этот момент? Проверить так:
mount | grep /dev/sdaМожно попробовать запустить проверку к примеру с gparted, там будет видно примонтирован он или нет. Проверить права на ноду /dev/sda1.
Цитата: vovchok
Если возможна ситуация, в которой после reset к информации на разде ext4 при живом винте нельзя никак подобраться, то доверять ему важную информацию весьма рисковано...
Лучше ничего не хранить на таких старых винтах (я уж и забыл уже, что винты объемом 40Гб вообще есть, у меня такой последний года два наза навернулся, бэды посреди диска стали расти как грибы после радиактивного дождика). И если уж по необходимости что-то приходится на них хранить, то хоть раз в полгода, а при плохой ситуации чаще, делать смарттест.
Чтобы узнать, от чего зависает система (в реальности это kernel panic), то можно воспользоваться этой>>> статьей. Настроить автоматическую перезагрузку можно воспользовавшись этой>> информацией.
Бывает решение проблемы, и бывает проблема в решении!
Если не знаешь, что делать, то лучше ничего не делать. (А.А.Громыко)

Оффлайн ludoed

  • Местный
  • *****
  • Сообщений: 861
  • ludoed1970@jabber.ru
Полное зависание через рандомные промежутки времени - это однозначно bad-блоки на винте
Была такая ситуация в 9.04 еще на ext3 - понадобилось многопроходное сканирование fsck, чтобы вылечить, но винт был отнюдь не старый.
После перехода на ext4 ушло как сон.
Ситуация усугубляется тем, что бэды множатся с каждым зависанием
Винт 40 Гб проще похоронить с воинскими почестями.
все юниксы очень дружелюбны.. они просто очень разборчивы в друзьях ;)

Настоящее труЪ: самописное ядро, выращенные на кухне кристаллы и программирование перемычками :)

Оффлайн ivm ®

  • Местный
  • *****
  • Сообщений: 934
  • ivm@jabber.at
    • Matuntu
А с каким ядром загружается LiveCD?
То-то, поддержка файловой системы ext4 была в наличии, но по факту не работала до появления ядра 2.6.39. Если хочется поработать, то в 10.04 была возможность установить ядро 3.0.0-15, у которого есть поддержка ext4 и исправлены другие ошибки.
Из-за отсутствия поддержки ext4 в то время многие по привычке до сих пор её не используют, продолжая "дуть на воду".
PS: возможно более правильно пересобрать образ RuntuLite 10.04 с упомянутым выше ядром.
© ivm 1991 - настоящее время. All Rights Reserved.
OS Matuntu-Best/Matuntu-Trusty/Matuntu-TT64-M16

Оффлайн HsH

  • Administrator
  • *****
  • Сообщений: 3468
То-то, поддержка файловой системы ext4 была в наличии, но по факту не работала до появления ядра 2.6.39.
    На чём основывается ваше утверждение?

PS: возможно более правильно пересобрать образ RuntuLite 10.04 с упомянутым выше ядром.
    Для установки нового ядра не нужно пересобирать образ, достаточно установить пакет с ядром в существующую систему.

Оффлайн Fastor

  • Постоялец
  • ***
  • Сообщений: 143
Ситуация усугубляется тем, что бэды множатся с каждым зависанием
Вообще да, но больший урон все-таки наносит жесткая перезагрузка, когда контроллер IDE заставляет контроллер винта со всей дури парковать головки в исходное положение, чтобы успеть к моменту инициализации биоса. Именно поэтому на серверах и ответственных компах устанавливают таймаут для мягкой перезагрузки при kernel panic, а не для автоматизации как многие пишут (хотя если сиадмин недалекий, то может и для автоматизации).
ivm ®, в 2.6.32 она полностью работала по факту, у меня сервера на этом ядре бегали с ext4. Проверка при каждом старте системы нареканий не вызывала. А вообще поддержка появилась с 2.6.28 (насколько я помню), до этого файловая система называлась ext4-dev и поддерживалась в тестовом режиме.
Бывает решение проблемы, и бывает проблема в решении!
Если не знаешь, что делать, то лучше ничего не делать. (А.А.Громыко)

Оффлайн vmf

  • Местный
  • *****
  • Сообщений: 587
  • vmf000@yabber.ru
У меня была такая ситуация на одном компе (дважды!):
После внезапного выключения (зависаний не было, просто отрубилось электричество) система перестала загружаться (10.04 на ext4)
При этом комп отказывался грузиться с iso-образов на флешке, с помощью которых обычно устанавливаю/восстанавливаю системы. С LiveCD загруить удалось, но при проверке раздела fsck сообщал, что раздел ext4 занят и проверить невозможно. Гугление на эту тему привело меня к тому, что в ядрах ubuntu вплоть до 12.10 есть такой баг (ссылки под рукой нет, но попробую найти, что бы не быть голословным).
Решение простое - проверить раздел с помощью любого liveCD (только не ubuntu), я загружался с какой-то спецсборки для восстановления. fsck без проблем проверил раздел и даже не нашел на нем ошибок. После этого пострадавшая система как ни в чем не бывало загрузилась.

Оффлайн vmf

  • Местный
  • *****
  • Сообщений: 587
  • vmf000@yabber.ru
А вот обещанная ссылка на баг
Еще забыл сказать: инсталятор убунты тоже не может ничего сделать с проблемным разделом, поэтому переустановка не прокатывает.
Тут есть способ решения без применения сторонних дистров. Я им  не пользовался (на тот момент мне он не попался) подтвердить работоспособность не могу.
« Последнее редактирование: Апрель 04, 2013, 10:07:00 от vmf »

Оффлайн HsH

  • Administrator
  • *****
  • Сообщений: 3468

        vmf, большое спасибо за информацию.

vovchok, попробуйте предложенное решение -
проверить раздел с помощью любого liveCD (только не ubuntu), я загружался с какой-то спецсборки для восстановления.
В качестве инструмента возьмите например Parted Magic.

Оффлайн vovchok

  • Постоялец
  • ***
  • Автор темы
  • Сообщений: 198
Спасибо всем, кто откликнулся! Наконец-то у меня руки (и ноги) дошли до этого компа...
Тут есть способ решения без применения сторонних дистров. Я им  не пользовался (на тот момент мне он не попался) подтвердить работоспособность не могу.
Это помогло - система заработала.

So here is the solution:

Boot from a live Ubuntu CD
Remove the first inode

sudo debugfs -w /dev/sda1
debugfs 1.41.11 (14-Mar-2010)
debugfs: clri <8>
debugfs: quit
Restart into Live CD again and do

sudo fsck -yv /dev/sda1
It will work this time.

После выполнения этих шагов система запустилась с винта. LiveCD использовал всё тот же - RuntuLite10.04.
« Последнее редактирование: Май 14, 2013, 16:01:27 от vovchok »