Внимание! Это временный неофициальный архив старой версии форума Полигон Призраков, созданный сочувствующим форуму участником. Этот сайт просуществует лишь до тех пор, пока администрация Полигона не сдержит своё обещание и не откроет официальный архив по адресу old.sannata.org.

Полигон-2

Форум о старых компьютерах

Объявление форума

Если пользуетесь личными сообщениями и получили по электронной почте оповещение о новом письме, не отвечайте, пожалуйста, почтой. Зайдите на форум и ответьте отправителю через ЛС.

Полигон-2 »   Технический флейм »   Cофтовый или "железный" trouble?
RSS

Cофтовый или "железный" trouble?

Проблема из разряда "WTF?"

<<Назад  Вперед>> Страницы: 1 2 *
Печать
 
Fe-Restorator
Гость

Ссылка

uav1606 написал:
[q]
Это я говорил про:
[/q]
Более поздний пост автора:

DamnBeavis написал:
[q]
Подрубил заведомо рабочий сидюк, при начале загрузки с установочного диска - мертвый зависон при строке "Проверка конфигурации оборудования...".
[/q]
От которого весь сыр-бор и возгорелся. :cool:
Сейчас на форуме
uav1606
Advanced Member


Откуда: Енакиево
Всего сообщений: 4373
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
16 янв. 2008
[q]
1) Испорчен экземпляр виндового MBR. -> Восстановить с дистриба в режиме Recovery, затем восстановить GRUB и всё настроить заново.
2) Испорчен загрузчик форточек ntldr. -> перезаписать заведомо рабочим файлом
3) Испорчена разметка первого(он-же виндовый) раздела жёсткого диска, причём, на низком уровне. -> А вот здесь как-бы не понадобился LLF всего диска! Если убита сервисная инфа и сектор, например №2537, физически невозможно обнаружить по сервометке - всякая ось встанет колом.
И не только ось - контроллер винта будет крайне удивлён ведь это его работа - разыскивать сектора.
[/q]
1) - тогда почему винда виснет при установке с CD?
2) - тот же вопрос, ntldr с винта при загрузке с CD не нужен вообще.
3) - но ведь, как я понял из постов DamnBeavis'а, из-под Убунты-то раздел читается (ведь он как-то сравнивал ntldr по размеру?), так что...

Помню, на одном компьютере тоже была такая странная неполадка, ничем не лечилось, пока я не начал вместо XP туда ставить Семёрку. Семёрка не поставилась, застопорилась на середине (диск с дистрибом оказался дефектным), но вот после этого XP стала нормально грузиться. %-)
(Кстати, XP в этом случае тоже у меня не ставилась с дистриба - висла с похожими на DamnBeavis'овские симптомами)
Но всё равно, думаю, нужно сначала раздел проверить чем-нибудь типа chkdsk, если удастся, потом можно и что-то вроде MHDD запустить и просканировать поверхность.
Или вот ещё описание Linux'овой проги ntfsfix:
http://quizz.bhome.ru/556-ubuntu-ntfsfix/
Неплохо было бы проверить ею проблемный раздел...

Да, вот ещё что, нашёл статью:
http://www.xakep.ru/magazine/xa/116/130/1.asp
Там, в частности, пишут:
[q]
Вместе с индексацией рекомендуется отключить и журналирование. Как известно, NTFS – журналируемая файловая система, что выдается Microsoft за достоинство, хотя это, скорее, недостаток. Журнал не только занимает место и отнимает драгоценное время, замедляя интенсивные дисковые операции, но и в некоторых случаях приводит к полному краху. В коде, связанном с поддержкой журнала, за историю существования NTFS в релизных версиях WinNT/200x было обнаружено, по меньшей мере, три ошибки, приводящие к BSOD при попытке монтирования NTFS тома. Знающие люди использовали загрузочные диски с Linux, поддерживающие NTFS на базовом уровне (то есть, без журналирования), перегоняя все ценные файлы по сети на соседний компьютер или уничтожая журнал в дисковых редакторах/системных утилитах.
[/q]
Интересно, не может ли быть корень проблемы в испорченном журнале?
wrenchrox
Advanced Member
Inhale

Откуда: Москва
Всего сообщений: 1888
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
11 нояб. 2009
О, а тут ещё продолжение разговора, однако.

Вообщём, снёс я винду, да и дело с концом. Конфигурация с двумя разделами (C:-винда, D:-файлопомойка) решает.
Проблема
DamnBeavis написал:
[q]
Подрубил заведомо рабочий сидюк, при начале загрузки с установочного диска - мертвый зависон при строке "Проверка конфигурации оборудования...".
[/q]
решилась удалением системного раздела через убунту. Таки Fe-Restorator был прав насчёт повреждения разметки раздела, наверное.
Fe-Restorator
Гость

Ссылка

uav1606 написал:
[q]
из-под Убунты-то раздел читается (ведь он как-то сравнивал ntldr по размеру?), так что...
...
Да, вот ещё что, нашёл статью:
...
Там, в частности, пишут:
...
Интересно, не может ли быть корень проблемы в испорченном журнале?
[/q]
Будет читаться, ибо повреждения не о наличия журналирования с индексацией ФС. которые, кстати очень полезны именно в такой ситуации, а от прохода головок по-спирали в момент записи через них неизвестно какой инфы. Через какие файлы прошла та спираль, низкоуровневую разметку каких секторов повредила - неведомо никому. Вероятность целенаправленного тотального стирания таблиц FAT или MFT ничтожна. пару файлов наверняка потёрты насовсем, остальные сохранили инфу о размере-положении, но не сохранили своего содержимого! Мне представляется именно такая картина.
Поскольку разметка раздела базируется на низкоуровневой разметке диска с добавлением кучи служебной инфы, есть смысл сперва проверить именно разметку диска на повреждения. Если повезёт, и разметка не задета - как в рекламе: "просто переставь винду", иначе - backup всего на другой диск и LLF.
Сейчас на форуме
Fe-Restorator
Гость

Ссылка

uav1606 написал:
[q]
из-под Убунты-то раздел читается (ведь он как-то сравнивал ntldr по размеру?), так что...
...
Да, вот ещё что, нашёл статью:
...
Там, в частности, пишут:
...
Интересно, не может ли быть корень проблемы в испорченном журнале?
[/q]
Будет читаться, ибо повреждения не о наличия журналирования с индексацией ФС. которые, кстати очень полезны именно в такой ситуации, а от прохода головок по-спирали в момент записи через них неизвестно какой инфы. Через какие файлы прошла та спираль, низкоуровневую разметку каких секторов повредила - неведомо никому. Вероятность целенаправленного тотального стирания таблиц FAT или MFT ничтожна. пару файлов наверняка потёрты насовсем, остальные сохранили инфу о размере-положении, но не сохранили своего содержимого! Мне представляется именно такая картина.
Поскольку разметка раздела базируется на низкоуровневой разметке диска с добавлением кучи служебной инфы, есть смысл сперва проверить именно разметку диска на повреждения. Если повезёт, и разметка не задета - как в рекламе: "просто переставь винду", иначе - backup всего на другой диск и LLF.
Сейчас на форуме
uav1606
Advanced Member


Откуда: Енакиево
Всего сообщений: 4373
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
16 янв. 2008
DamnBeavis, ну, рад, что всё удалось исправить, жаль, что такими радикальными методами. :-)
Хотелось бы всё-таки разобраться в причинах этого сбоя, раз он, судя по всему, достаточно частый (раз и у меня такое было).
Не знаю насчёт разметки - ясно, что повредилась какая-то служебная структура на разделе, но вот какая... Моё предположение насчёт журнала NTFS исходило из того, что Linux раздел читала, а Windows - нет. А отличие их драйверов NTFS в основном в том, что Linux'овые не поддерживают журналирование... Может быть повреждённый журнал и вводил NTFS.sys в ступор.

Fe-Restorator написал:
[q]
Будет читаться, ибо повреждения не о наличия журналирования с индексацией ФС.
[/q]
???? Ничего не понял...
<<Назад  Вперед>> Страницы: 1 2 *
Печать
Полигон-2 »   Технический флейм »   Cофтовый или "железный" trouble?
RSS

0 посетителей просмотрели эту тему за последние 15 минут
В том числе: 0 гостей, 0 скрытых пользователей

Последние RSS
[Москва] LIQUID-Акция. Сливаются разъемы CF
МС7004 и 7004А на AT и XT
Пайка термотрубок
Проммать s478 PEAK 715VL2-HT ( Full-Size SBC)
Подскажите по 386 материке по джамперам.

Самые активные 5 тем RSS