Полигон-2

Fe-Restorator написал:

[q]

Нет у него такой проблем

[/q]

Это я говорил про:

DamnBeavis написал:

[q]

у меня два привода DVD-RW, оба полурабочие и загрузиться с них нельзя

[/q]

Ну а если можно загрузиться хотя бы с CD - нужно попробовать всякие проги для восстановления проверки дисков - тот же chkdsk из консоли восстановления, как я писал. Или из Убунты подобную прогу запустить.

[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]

Интересно, не может ли быть корень проблемы в испорченном журнале?

uav1606 написал:

[q]

из-под Убунты-то раздел читается (ведь он как-то сравнивал ntldr по размеру?), так что...
...
Да, вот ещё что, нашёл статью:
...
Там, в частности, пишут:
...
Интересно, не может ли быть корень проблемы в испорченном журнале?

[/q]

Будет читаться, ибо повреждения не о наличия журналирования с индексацией ФС. которые, кстати очень полезны именно в такой ситуации, а от прохода головок по-спирали в момент записи через них неизвестно какой инфы. Через какие файлы прошла та спираль, низкоуровневую разметку каких секторов повредила - неведомо никому. Вероятность целенаправленного тотального стирания таблиц FAT или MFT ничтожна. пару файлов наверняка потёрты насовсем, остальные сохранили инфу о размере-положении, но не сохранили своего содержимого! Мне представляется именно такая картина.
Поскольку разметка раздела базируется на низкоуровневой разметке диска с добавлением кучи служебной инфы, есть смысл сперва проверить именно разметку диска на повреждения. Если повезёт, и разметка не задета - как в рекламе: "просто переставь винду", иначе - backup всего на другой диск и LLF.

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

Fe-Restorator написал:

[q]

Будет читаться, ибо повреждения не о наличия журналирования с индексацией ФС.

[/q]

???? Ничего не понял...