[FIXED] не грузится винда
попробуй
может быть, поможет...
по крайней мере, у меня так винда грузилась (когда еще была) правда с fat32...
root (hd0,4)
makeactive
chainloader +1
может быть, поможет...
по крайней мере, у меня так винда грузилась (когда еще была) правда с fat32...
Для не-linux разделов, точнее, для разделов, которые grub не распознает, вроде, надо писать не 'root', а 'rootnoverify' - последняя команда означает отказ от проверки данного раздела, т.к. grub такой раздел не понимает и все равно понять на нем ничего не сможет (это я уже начитался 
)
Ну, не суть дела.
Короче, я пробовал по-всякому грузиться с hd0,4: с hide, c unhide и т.п. (кстати, hide - штука, в должная быть охуенно осторожно употребляема, т.к. она тип раздела меняет, сцуко, на hidden - приходится руками обратно переставлять нихера не получилось.
Тут на меня сошло озарение, и я написал:
в результате меня пустили в виндовый загрузчик (там, где список операционных систем).
Ну, в принципе, и правильно. chainloader +1 - команда передачи загрузки дальше по цепи ,т.е. следующему загрузчику, каким и является виндовый, стоящий на диске C: в загрузочной записи.
Но на этом приключения не закончились.
)Ну, не суть дела.
Короче, я пробовал по-всякому грузиться с hd0,4: с hide, c unhide и т.п. (кстати, hide - штука, в должная быть охуенно осторожно употребляема, т.к. она тип раздела меняет, сцуко, на hidden - приходится руками обратно переставлять нихера не получилось.
Тут на меня сошло озарение, и я написал:
rootnoverify (hd0,0)
chainloader +1
в результате меня пустили в виндовый загрузчик (там, где список операционных систем).
Ну, в принципе, и правильно. chainloader +1 - команда передачи загрузки дальше по цепи ,т.е. следующему загрузчику, каким и является виндовый, стоящий на диске C: в загрузочной записи.
Но на этом приключения не закончились.
О чудо!
Я вижу знакомое microsoft'овское загрузочное меню!
Здесь последует небольшая библиографическая справка. Если Вам неохота читать всякую хуйню, то следует пропустить курсивный текст.
Ваш покорный слуга иногда бывает падок на плохо обдуманные действия. В моей жизни недавно был период, когда grub сбросил виндовые разделы на какой-то такой уровень, откуда они даже не монтировались и не присутствовали в списке разделов /dev/sda (это произошло от неосторожного обращения с grub'овскими командами hide/unhide; более подробно можно прочитать , но это вряд ли кому-либо нужно, поэтому не стоит).
Так вот, в период глубокой депрессии, граничащей с помешательством, я предпринимал отдельные лихорадочные попытки удостовериться, что у меня эти разделы сохранились. У меня был виден DOSовский диск, но там DOS7.0, и его fdisk эти разделы неправильно видел. Точнее, он их видел очень криво (писал вместо них один, но говорил, что занято 40Гб, что несколько обнадеживало. Но недостаточно. Поэтому глубокой ночью, когда мозги работают с перебоями, я решил запустить виндовую инсталляцию, чтобы из-под нее посмотреть, остались ли разделы. Правда, я ее прервал (решил хуй забить, это решение объяснить сложно, т.к. я щас не в том состоянии нахожусь не успела она даже все файлы скопировать. Тем не менее она успела прописаться в microsoft'овский загрузчик и насрать на диске C: временными файлами. Я их удалил и вообще сделал все, как раньше было.
Но не тут-то было.
Блиа!
Я смотрел, на ntfs-диске есть файл \WINDOWS\system32\hal.dll, имеет размер 131968 байт.
boot.ini вот (он находится на диске C:) :
Нумерация тоже вроде правильно (разделы с первого, ведь, начинаются? винда стоит, получается, на втором; хотя хз, винда на расширенном стоит, который по счету идет вторым после досовского - может, в этом дело?)
Я вижу знакомое microsoft'овское загрузочное меню!
Здесь последует небольшая библиографическая справка. Если Вам неохота читать всякую хуйню, то следует пропустить курсивный текст.
Ваш покорный слуга иногда бывает падок на плохо обдуманные действия. В моей жизни недавно был период, когда grub сбросил виндовые разделы на какой-то такой уровень, откуда они даже не монтировались и не присутствовали в списке разделов /dev/sda (это произошло от неосторожного обращения с grub'овскими командами hide/unhide; более подробно можно прочитать , но это вряд ли кому-либо нужно, поэтому не стоит).
Так вот, в период глубокой депрессии, граничащей с помешательством, я предпринимал отдельные лихорадочные попытки удостовериться, что у меня эти разделы сохранились. У меня был виден DOSовский диск, но там DOS7.0, и его fdisk эти разделы неправильно видел. Точнее, он их видел очень криво (писал вместо них один, но говорил, что занято 40Гб, что несколько обнадеживало. Но недостаточно. Поэтому глубокой ночью, когда мозги работают с перебоями, я решил запустить виндовую инсталляцию, чтобы из-под нее посмотреть, остались ли разделы. Правда, я ее прервал (решил хуй забить, это решение объяснить сложно, т.к. я щас не в том состоянии нахожусь не успела она даже все файлы скопировать. Тем не менее она успела прописаться в microsoft'овский загрузчик и насрать на диске C: временными файлами. Я их удалил и вообще сделал все, как раньше было.
Но не тут-то было.
Windows could not start because the
following file is missing or corrupt:
<Windows root>\system32\hal.dll
Блиа!
Я смотрел, на ntfs-диске есть файл \WINDOWS\system32\hal.dll, имеет размер 131968 байт.
boot.ini вот (он находится на диске C:) :
DOS грузится нормально.
[Boot Loader]
Timeout=5
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[Operating Systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows XP"/noexecute=optin /fastdetect
C:\ = "DOS 7.0 (from Windows 98)"
Нумерация тоже вроде правильно (разделы с первого, ведь, начинаются? винда стоит, получается, на втором; хотя хз, винда на расширенном стоит, который по счету идет вторым после досовского - может, в этом дело?)
Хм... У меня файл D:\Windows\System32\hal.dll весит 279 552 байта. Но наверняка это просто от того, что винда другая.
А по поводу boot.ini — вот что:
Ну или если не пойдет, то поперебирай соседние варианты, или вообще попробуй fixboot из консоли восстановления.
А по поводу boot.ini — вот что:
Disk /dev/sda: 200.0 GB, 200049647616 bytesТеперь у тебя NTFS раздел на sda5, так что видимо надо писать так:
255 heads, 63 sectors/track, 24321 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 256 2056288+ 6 FAT16
/dev/sda2 257 22526 178883775 f W95 Ext'd (LBA)
/dev/sda3 22527 24184 13317885 83 Linux
/dev/sda4 24185 24321 1100452+ 82 Linux swap / Solaris
/dev/sda5 257 2933 21502971 7 HPFS/NTFS
/dev/sda6 2934 22526 157380741 c W95 FAT32 (LBA)
multi(0)disk(0)rdisk(0)partition(5)\WINDOWS="Windows XP"/noexecute=optin /fastdetect
Ну или если не пойдет, то поперебирай соседние варианты, или вообще попробуй fixboot из консоли восстановления.
Теперь у тебя NTFS раздел на sda5, так что видимо надо писать такДа, мне тоже это показалось логичным. Но результат опять оказался негативным.
Начал перебирать строки вида
multi(0)disk(0)rdisk(0)partition(n)\WINDOWS
где n - от 0 (решил подойти к вопросу основательно) и далее.
И подошло... 4
Какова тут логика - я не понимаю (можт без линуксового свопа? но оно так.
2: большое спасибо за идею, а то я б до сих пор без винды сидел
Еще вопрос для общего развития - куда конкретно обращаются fixboot и fixmbr? (видимо, первая - просмотр boot.ini).
Несколько более конкретный вопрос: дают ли они хотя бы посмотреть, что делается, перед тем, как все херачить?
Скорее всего винда пропустила ext-раздел sda2. То есть сначала идут три primary-раздела(sda1, sda3, sda4 а потом четвертым для нее идет sda5.
Про fixboot и fixmbr ничего толком сказать не могу, так как очень давно не пользовался, а последний опыт работы с ними был весьма плачевным
fixboot вроде должна поискать на всех разделах все винды и просто добавить их в boot.ini. В любом случае стоит сначала запускать их с ключами типа /? и думать, стоит ли продолжать
Про fixboot и fixmbr ничего толком сказать не могу, так как очень давно не пользовался, а последний опыт работы с ними был весьма плачевным
fixboot вроде должна поискать на всех разделах все винды и просто добавить их в boot.ini. В любом случае стоит сначала запускать их с ключами типа /? и думать, стоит ли продолжать
Про fixboot и fixmbr ничего толком сказать не могу, так как очень давно не пользовался, а последний опыт работы с ними был весьма плачевным+1 - что касается fixmbr. Ничего он не дает посмотреть, просто выполняется и все. Частенько перед своим выполнением (у меня так всегда) честно предупреждает, что то ли нестандартная таблица разделов, то ли нестандартная геометрия диска, и спрашивает, продолжать ли. При нажатии "да" у меня похерил как загрузчик, так и таблицу разделов в mbr. Я бы пять раз подумал прежде чем выполнить fixmbr.
ясно. Значит, правлильно я не стал им пользоваться.
Вообще, вроде как, в линуксе для таких вещей есть цивильные средства: можно создать линуксовую загрузочную дискету, скопировать загрузочный сектор в файл и записать этот файл на дискету.
Потом можно экспериментировать со всякими агрессивными средствами восстановления, и, в случае, если все похерят - восстановить с дискеты.
Вообще, вроде как, в линуксе для таких вещей есть цивильные средства: можно создать линуксовую загрузочную дискету, скопировать загрузочный сектор в файл и записать этот файл на дискету.
Потом можно экспериментировать со всякими агрессивными средствами восстановления, и, в случае, если все похерят - восстановить с дискеты.
Для не-linux разделов, точнее, для разделов, которые grub не распознает, вроде, надо писать не 'root', а 'rootnoverify' - последняя команда означает отказ от проверки данного раздела, т.к. grub такой раздел не понимает и все равно понять на нем ничего не сможет (это я уже начитался )У меня отлично работает такая конструкция, как у тебя в первом посте, с ntfd-разделом.
Короче, я пробовал по-всякому грузиться с hd0,4: с hide, c unhide и т.п. (кстати, hide - штука, в должная быть охуенно осторожно употребляема, т.к. она тип раздела меняет, сцуко, на hidden - приходится руками обратно переставлять нихера не получилосьА разве на etended-разделе может находиться загрузчик?
Имелось в виду следующее:
У меня отлично работает такая конструкция, как у тебя в первом посте, с ntfd-разделом.
"rootnoverify" tells GRUB to boot from the Windows partition, but not to attempt to mount it, and "chainloader +1" tells GRUB to chain to Windows' bootloader which will start Windows.
Взято с http://www.tldp.org/HOWTO/Linux+Win9x+Grub-HOWTO/proc.html
Смотря какой.
А разве на etended-разделе может находиться загрузчик?
Оставить комментарий
tihon972009
ЛУЧШЕ СРАЗУ СМОТРЕТЬСцуко GRUB не грузит винду
И дальше ничего не происходит.
Я порылся в документации на tldp.org, попробовал немножко поковыряться, но не вышло ни фига.
Подскажите, как сделать, чтобы нормально винду грузил?
И еще advanced question: как, чтобы еще и DOS мог грузить?
----------------------------------
Информация:
До установки linux Диск был разбит на следующие разделы:
C: 2 Гб, FAT16 Первичный Тут установлен DOS
D: 20 Гб, NTFS Первичный С него грузилась Windows XP
E: 150 Гб, FAT32 кажется, был логический; хранилище данных, ничего не установлено
неразмеченная область: ~15 Гб было оставлено для установки Linux
На неразмченной области создал раздел ext3 ~13 Гб и linux swap ~1 Гб, поставил Fedora 5 и вместе с ней GRUB.
При установке GRUB'а вроде выбрал "установить на /dev/sda3" (это там где линукс хотя точно не помню.
MBR, вроде, на диске C:. Если чо, вот ссылка на содержимое MBR
(файл двоичный, получен командой расширение .zip добавлено для совместимостью с upload-функцией форума).
Как известно, если при загрузке GRUB'а полезть к нему в консоль, то можно получить информацию о том, как он видит разделы. Видит он их вот как:
При этом нынешняя структура разбиения диска:
Конфигурация GRUB: