Raid 1 не загружается windows

Обновлено: 04.07.2024

Хочу рассказать поучительную историю, которая случилась со мной на днях. На одном из серверов в ЦОД вышел из строя диск в составе рейда mdadm. Ситуация типовая, с которой регулярно сталкиваюсь. Оставил заявку в техподдержку на замену диска с указанием диска, который надо поменять. В цоде заменили рабочий диск и оставили сбойный. Дальше история, как я решал возникшую проблему.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на . Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Цели статьи

Рассказать поучительную историю о том, какие могут быть проблемы при аренде серверов в ЦОД.
Показать на примере, как надо действовать при выходе из строя диска в рейде mdadm.
Простыми словами объяснить, в чем разница между программным и аппаратным рейдом.

Введение

Когда первый раз сталкиваешься с рукожопством сотрудников техподдержки дата центра, впадаешь в ступор и думаешь, ну как так то? Сейчас я спокойно отношусь к таким ситуациям и действую исходя из самых худших ожиданий. На днях я столкнулся с ситуацией, когда мне заменили не тот диск в сервере с RAID1. Вместо сбойного диска вынули рабочий и заменили чистым. К счастью все закончилось хорошо, но обо всем по порядку.

Не скажу, что у меня прям большой опыт аренды серверов, но он есть. Я регулярно обслуживаю 10-15 серверов, расположенных в разных дата центрах, как российских, так и европейских. Первый негативный опыт я получил именно в Европе и был очень сильно удивлен и озадачен. Я, как и многие, был под влиянием либеральной пропаганды на тему того, что у нас все плохо, а вот Европа образец надежности, стабильности и сервиса. Как же я ошибался. Сейчас отдам предпочтение нашим дата центрам. По моему мнению и опыту, у нас тех поддержка и сервис в целом лучше, чем там, без привязки к стоимости. В Европе дешевле схожие услуги, так как там масштабы сервисов в разы больше.

Приведу несколько примеров косяков саппорта, с которыми сталкивался.

Было много всяких инцидентов помельче, нет смысла описывать. Хотя нет, один все же опишу. Устанавливал свой сервер в ЦОД. Решил пойти в маш зал и проконтролировать монтаж. Если есть такая возможность, крайне рекомендую ей воспользоваться. Местный рукожоп неправильно прикрепил салазки и сервер во время монтажа стал падать. Я его поймал, тем спас его и сервера других клиентов. В итоге помог с монтажом. Сам бы он просто не справился. Я не представляю, что было, если бы я не пошел в машзал. К чести руководства, я написал претензию, где подробно описал данный случай и попросил бесплатно месячную аренду. Мне ее предоставили. Советую всем так поступать. Зачастую, руководство может быть не в курсе того, что происходит в реальности. Надо давать обратную связь.

Уровень моего доверия к тех поддержке дата центров и хостингов вы примерно представляете :) Ну и вот случилось очередное ЧП. Подробнее остановлюсь на этой ситуации, так как она случилась вчера, свежи воспоминания.

Замена диска в рейде mdadm

Речь пойдет о дешевых дедиках от selectel. Я их много где использую и в целом готов рекомендовать. Это обычные десктопные системники за скромные деньги. Свое мнение об этих серверах, а так же сравнение с полноценными серверами сделаю в конце, в отдельном разделе.

На сервере была установлена система Debian из стандартного шаблона Selectel. Вот особенности дисковой подсистемы этих серверов и шаблона.

2 ssd диска, объединенные в mdadm
/boot раздел на /dev/md0 размером 1G
корень / на /dev/md1 и поверх lvm на весь массив

В целом, хорошая и надежная разбивка, чему будет подтверждение дальше. На сервере был установлен proxmox, настроен мониторинг mdadm. Мониторинг дисков не сделал. В какой-то момент получил уведомление в zabbix, что mdadm развалился. Сервер при этом продолжал работать. Ситуация штатная. Пошел в консоль сервера, чтобы все проверить. Посмотрел состояние рейда.

Убедился, что один диск выпал из массива. В системном логе увидел следующее.

Попробовал посмотреть информацию о выпавшем диске.

Информации не было, утилита показывала ошибку обращения к диску. Получилось посмотреть модель и серийный номер только работающего диска.

Я не стал разбираться, что там к чему с диском. Если вижу проблемы, сразу меняю. Предупредил заказчика, что с диском проблемы, нужно планировать замену. Так как железо десктопное, "сервер" надо выключать. Согласовали время после 22 часов. Я в это время уже сплю, поэтому написал тикет в тех поддержку, где указал время и серийный номер диска, который нужно было оставить. Я сделал на этом акцент, объяснил, что сбойный диск не отвечает, поэтому его серийник посмотреть не могу. Расписал все очень подробно, чтобы не оставить почвы для недопонимания или двойного толкования. Я в этом уже спец, но все равно не помогло.

Я спокойно согласился на эту операцию, потому что часто делаются бэкапы и они гарантированно рабочие. Настроен мониторинг бэкапов и делается регулярное полуручное восстановление из них. Договоренность была такая, что хостер после замены дожидается появления окна логина, а заказчик проверяет, что сайт работает. Все так и получилось - сервер загрузился, виртуалки поднялись, сайт заработал. На том завершили работы.

Утром я встал и увидел, что весь системный лог в ошибках диска, рабочего диска в системе нет, а есть один глючный и один новый. Сразу же запустил на всякий случай ребилд массива и он вроде как даже прошел без ошибок. Перезагрузка временно оживила сбойный диск. В принципе, на этом можно было бы остановиться, заменить таки сбойный диск и успокоиться. Но смысл в том, что этот сбойный диск почти сутки не был в работе и данные на нем старые. Это не устраивало. Потом пришлось бы как-то склеивать эти данные с данными из бэкапов. В случае с базой данных это не тривиальная процедура. Созвонился с заказчиком и решили откатываться на рабочий диск, который вытащили накануне ночью.

Я создал тикет и попросил вернуть рабочий диск на место. К счастью, он сохранился. К нему добавить еще один полностью чистый. Хостер оперативно все сделал и извинился. В завершении прислал скриншот экрана сервера.

И самоустранился. Дальше решать проблему загрузки он предложил загрузившись в режиме rescue. Этот режим доступен через панель управления сервером в админке, даже если сервер не имеет ipmi консоли. Как я понял, по сети загружается какой-то live cd для восстановления. Я в нем загрузился, убедился, что данные на месте, но понять причину ошибки не смог. Может быть и смог бы, если бы дольше покопался, но это очень неудобно делать, не видя реальной консоли сервера. Я попросил подключить к серверу kvm over ip, чтобы я мог подключиться к консоли. Тех поддержка без лишних вопросов оперативно это сделала.

К слову, мне известны случаи, когда техподдержка selectel потом сама чинила загрузку и возвращала mdadm в рабочее состояние. Видел такие переписки в тикетах у своих клиентов до того, как они обращались ко мне. Но я не стал настаивать на таком решении проблемы, так как боялся, что будет хуже. К тому же это было утро воскресенья и специалистов, способных это сделать, могло просто не быть. Плюс, я не думаю, что они обладали бы большими компетенциями, чем я. Я бы за их зарплату не пошел работать в ЦОД.

После того, как я подключился к консоли сервера, восстановление загрузки было делом техники.

You are in emergency mode

У меня много примеров того, как я восстанавливал загрузку сломавшихся linux дистрибутивов.

В данной ситуации с mdadm я был уверен, что все получится, так как сам массив с системой жив, данные доступны. Надо только разобраться, почему система не загружается. Напомню, что ошибка загрузки была следующая.

Дальше нужно ввести пароль root и вы окажетесь в системной консоли. Первым делом я проверил состояние массива mdadm.

Состояние массива md0, на котором располагается раздел /boot - inactive. Вот, собственно, и причина того, почему сервер не загружается. Судя по всему, когда был подключен сбойный диск, mdadm отключил массив, чтобы предотвратить повреждение данных. Не понятно, почему именно на разделе /boot, но по факту было именно это. Из-за того, что массив остановлен, загрузиться с него не получалось. Я остановил массив и запустил снова.

После этого массив вышел из режима inactive и стал доступен для дальнейшей работы с ним. Я перезагрузил сервер и убедился, что он нормально загружается. Сервер фактически был в рабочем состоянии, просто с развалившимся массивом mdadm, без одного диска.

Если вам это не поможет, предлагаю еще несколько советов, что можно предпринять, чтобы починить загрузку. Первым делом проверьте файл /etc/fstab и посмотрите, какие разделы и как там монтируются. Вот мой пример этого файла.

Вам нужно убедиться, что указанные lvm разделы /dev/mapper/vg0-root и /dev/mapper/vg0-swap_1 действительно существуют. Для этого используйте команду:

Подробно об этой команде, о работе с lvm и вообще с дисками я рассказываю в отдельной статье - настройка диска в debian. Если с lvm разделами все нормально, проверьте /boot. У меня он монтируется по uuid. Посмотреть список uuid всех разделов можно командой.

Как вы видите, у меня uuid раздела для загрузки полностью совпадает с тем, что указано в fstab. Если по какой-то причине uuid изменился (разобрали и собрали новый массив), отредактируйте fstab.

Все дальнейшие действия я делал уже по ssh. Скопировал таблицу разделов с рабочего диска sda на чистый sdb.

Проверил таблицы разделов и убедился, что они идентичные.

Скопировал раздел BIOS boot partition с рабочего диска на новый.

Потом добавил разделы диска sdb2 и sdb3 в рейд массив.

Дождался окончания ребилда и убедился, что он прошел. Проверил состояние массива.

В завершении устанавливаем загрузчик на оба диска.

После этого я перезагрузился и убедился, что все работает нормально. По хорошему, теперь надо было бы поменять загрузочный диск с первого на второй и убедиться, что со второго тоже нормально грузится. Я не стал этого делать, и так простой и так был велик. Главное, чтобы массив был на месте, а починить загрузку, если что, дело техники.

Вот и все по замене диска в массиве mdadm. После доступа к консоли сервера, мне потребовалось минут 10, чтобы вернуть сервер в рабочее состояние.

В чем отличия программного и аппаратного рейда

Сейчас расскажу, чем принципиально отличается программный рейд контроллер (mdadm) от аппаратного, для тех, кто этого до конца не понимает. Если бы у меня вышел из строя диск на аппаратном рейд контроллере, установленном в полноценный сервер, проблема по замене сбойного диска в RAID решалась бы в следующей последовательности:

Рейд контроллер оповещает о том, что с диском проблемы и выводит его из работы. В случае с софтовым рейдом система может зависнуть в случае проблем с диском, прежде чем пометит его как проблемный и перестанет к нему обращаться.
Я оставляю тикет в тех поддержку, где прошу заменить сбойный диск. Информацию о нем я посмотрю в панели управления рейд контроллером.
Сотрудник тех поддержки видит сбойный диск, так как индикация на нем, скорее всего, будет мигать красной лампочкой. Это не гарантия того, что рукожоп все сделает правильно, но тем не менее, шансов, что он ошибется, меньше. Я сталкивался с ситуацией, когда и в этом случае диск меняли не тот.
При появлении нового диска raid контроллер автоматически начинает ребил массива.

Если же у вас в сервере уже установлен запасной диск на случай выхода из строя диска в составе raid массива, то все еще проще:

При выходе из строя диска, контроллер помечает его как сбойный, вводит в работу запасной диск и начинает ребилд.
Вы получаете оповещение о том, что вышел из строя диск и оставляете тикет в тех поддержку на замену запасного диска.

И это все. В обоих случаях у вас вообще нет простоя. Вот принципиальная разница между mdadm и железным raid контроллером. Стоимость полноценного сервера с контроллером и постоянным ipmi доступом к консоли в среднем в 3 раза выше, чем у сервера на десткопном железе с софтовым рейдом при схожей производительности. Это все при условии, что вам достаточно одного процессора и 64G памяти. Это потолок для десктопных конфигураций. Дальше считайте сами, что вам выгоднее. Если возможен простой в несколько часов на замену диска или других комплектующих, то смело можно использовать десктопное железо. Mdadm обеспечивает сопоставимую гарантию сохранности данных в сравнении с железным контроллером. Вопрос лишь в простое и производительности. Ну и своевременные бэкапы добавляют уверенности в том, что вы переживете неполадки с железом.

При использовании железного рейда на hdd дисках, есть возможно получить очень значительный прирост скорости за счет кэша контроллера. Для ssd дисков я особо не замечал разницы. Но это все на глазок, никаких замеров и сравнений я не делал. Нужно еще понимать, что десктопное железо в целом менее надежное. К примеру, в том же селектеле на дешевых серверах я ловил перегрев или очень высокую температуру дисков. Прыгала в районе 55-65 градусов. Все, что ниже 60-ти, тех поддержка футболила, говоря, что это допустимая температура, судя по документации к дискам. Это так и есть, но мы же понимаем, что диск, постоянно работающий на 59 градусах с бОльшей долей вероятности выйдет из строя.

Вот еще пример разницы в железе. Если у вас в нормальном сервере выйдет из строя планка памяти, сервер просто пометит ее как сбойную и выведет из работы. Информацию об этом вы увидите в консоли управления - ilo, idrac и т.д. В десктопном железе у вас просто будет постоянно виснуть сервер и вам придется долго выяснять, в чем же проблема, так как доступа к железу у вас нет, чтобы проще было запланировать тестирование сервера. А если вы закажете это у тех поддержки, то есть ненулевая вероятность, что станет хуже - сервер уронят, перепутают провода подключения дисков и т.д. В общем, это всегда риск. Проще сразу съезжать с такой железки на другую.

Заключение

Надеюсь, моя статья была интересной. Для тех, кто никогда не работал с ЦОДами будет полезно узнать, чего можно от них ожидать. Я скучаю по временам, когда все сервера, которые я администрировал, были в серверной, куда никому не было доступа и куда я мог в любой момент попасть и проверить их. Сейчас все стало не так. И твои сервера уже не твои. Их может сломать, уронить, что-то перепутать сотрудник тех поддержки дата центра.

Сейчас большой тренд на переход в облака. Я смотрю на эти облака и не понимаю, как с ними можно нормально взаимодействовать. Заявленная производительность не гарантированная, нагрузка плавает в течении суток. Упасть может в любой момент и ты не будешь понимать вообще в чем проблема. Твои виртуалки могут быть по ошибке удалены и кроме извинений и компенсации в 3 копейки ты ничего не получить. Каждое обращение в ТП как лотерея. Думаешь, что сломают в этот раз. Если сервера железные, то когда пишу тикет на доступ к железу, я морально и технически всегда готов к тому, что этот сервер сейчас отключится и я больше не смогу к нему подключиться.

В целом, опыт работы с облаками у меня негативный. Несколько раз пробовал для сайтов и все время съезжал. Нет гарантированного времени отклика. А это сейчас фактор ранжирования. Для очень быстрого сайта остается только один вариант - свое железо, а дальше уже кому какое по карману. Зависит от надежности и допустимого времени простоя.

Я про облака заговорил, потому что тенденции к тому, что от железных серверов надо отказываться и все переносить в облака. С одной стороны удобно должно быть. Как минимум, не будет указанных выше в статье проблем. А с другой стороны добавляется куча других проблем. Я пока сижу на железяках разного качества и стоимости. А у вас как?

Проблема, с которой можно столкнуться после отказа первого диска в программном массиве RAID-1 — со второго диска система не загружается. Вот как это может выглядеть:

Да, ничего особенного, просто чёрный экран с мигающим курсором в углу. Но система не загружается. Многие сразу начинают обвинять кого угодно — плохой Microsoft, плохие программные RAID, плохой диск, плохой компьютер и т.д. На самом деле, дело в элементарном незнании порядка загрузки компьютера. Механизм этот работает следующим образом:

Компьютер включается, BIOS firmware выполняет процедуру самотестирования (Power-On Self-Test, POST); BIOS ищет главную загрузочную запись (Master Boot Record, MBR) указанного в CMOS загрузочного устройства. В данном случае, жёсткого диска; Считанный с жёсткого диска MBR ищет и передаёт управление загрузочному сектору (boot sector) активного первичного раздела (active primary partition) этого диска; Загрузочный сектор передаёт управление находящемуся на этом же разделе загрузчику операционной системы; Загрузчик ОС загружает ядро операционной системы с соответствующего раздела (как правило, всё того же); Происходит загрузка драйверов устройств (device drivers) и интерфейса пользователя (user interface).

Так вот вся проблема заключается в том, что программное зеркалирование Windows Server или клонирование типа partition-to-partition дублирует не весь диск целиком, а только указанные разделы. MBR в территорию разделов не входит, так как находится в совершенно отдельном месте — в первом секторе нулевого цилиндра, поэтому программным зеркалированием разделов на второй диск может не скопироваться. Когда новый диск поставляется с завода, MBR на нём тоже отсутствует — это же новый, абсолютно чистый диск:

Вообще, существуют три способа попадания главной загрузочной записи на диск:

Установка операционной системы. Как правило, ОС создаёт MBR в момент начала инсталляции себя; Дублирование диска целиком (клонирование либо аппаратный массив RAID-1); Восстановление с помощью установочного компакт-диска Windows или сторонними средствами типа LiveCD.

На самом деле, программное зеркалирование системного раздела в Windows Server дублирует и MBR. Но я видел ситуации, когда этого по каким-то причинам не происходило. Поэтому, если столкнётесь с подобной проблемой, а MBR заранее на диске не приготовили, не спешите расстраиваться — проблема загрузки решается достаточно просто и быстро с помощью установочного компакт-диска Windows.

Update 06-Dec-2011:

Boot Failed. Press any key to reboot.

Авторизуясь в LiveJournal с помощью стороннего сервиса вы принимаете условия Пользовательского соглашения LiveJournal

Всем привет. Может кто сталкивался с такой проблемой.
Есть сервер с мамкой Asus P5E-VM DO, к которой подключено три SATA винча (2xWD 500Gb Raid Edition и Seagate 80Gb) + DVD привод(тоже SATA).
Отключаю вестерны, на сигейт ставлю Win2003, устанавливаю драйвера для чипсета, сети, ACHI. Далее выключаю машинку, подключаю два вестерна и не загружая винды лезу в биос, где ставлю режим с IDE на RAID, после чего WD объединяю в RAID1 и гружу винды.
Проблема в том, что при попытке загрузить win2003 (в безопасном режиме та же фигня) происходит перезагрузка. Если отключить RAID, то винды загрузятся на ура.

В принципе, обращаюсь к людям имевшим дело с данной мамкой, ибо проблема, как мне кажется, именно в драйвере ACHI(на диске не нашел, на сайте только одна версия драйверов выложена). Если у кого была такая проблема, как решили?

а дрова на рейд в винду подсунуть? и посмотреть код BSOD - скорее всего 0x0000007B. На сайте asus'а не нашел дров на рейд. только на achi

контроллер в таком режиме требует другой драйвер.

правильно было бы создать рейд0 из одного диска для системы, и рейд1 из двух дисков для всего остального, а потом устанавливать винду

Вы не пробовали сперва собрать рейды, а потом уже ставить систему? Пробовал. Винда при установке просит драйвер с диска A. У меня флопиков уже не осталось. :) Да и проблема не столько в флопиках, сколько найти сам драйвер для рейда.

флопик при установке или интеграция дравов в дистриб + установка при вкл рейде.

рейд включается глобально для всех сата разъемах

Интеграция драйверов помогает далеко не всегда, если есть один и тот же драйвер для разных режимов контроллера (разница лишь в inf), как например у Intel в ICH7-10, то можно легко словить BSOD 7e, помогает только подсовывание дискеты по F6 c USB-FDD и выпор правильного режима работы ICH.

А может не извращаться с фейковым рейдом на этой матери, и банально построить софтовый рейд средствами ос?

Недумаю что вы много потеряете в скорости в данном случае.

+1 к софтовому рейду, ага
а для подсовывания флопиков все современные винды умеют этот флопик видеть даже если он usb-шный. цена вопроса - 600р. плюс дискетка.
предусмотрительные админы обязательно имеют usb-флоповод в куче остального хлама. аватар походу с БОРа. познания в компьютерах оттуда же. пускай там и остаётся.

Как верно заметили выше, контроллер весь переходит из легаси в другой режим, со всеми хардами, которые к нему подключены, независимо от того, создан из этих дисков рейд или нет.

Но дело в том, что если сменить режим контроллера "на лету", винда при старте не обнаруживает того устройства, с которого она последний раз грузилась - это раз. Дальше она пытается прикрутить к нему драйвер (который вы перед этим, предположим, поставили) - откуда? Правильно, из system32. А где он? Правильно, на том разделе, который находится на физическом устройстве, драйвер к которому она хочет найти, чтобы уметь с ним работать. Ну почему нельзя было этого предусмотреть? )

Поэтому, надо сразу ставить систему на контроллер в raid- или ahci-режиме, даже на одиночный диск. Посредством дров на флопике, на юсб-флопике, или интегрированных в дистрибутив. Иначе потом вы получите те проблемы, которые получили.

Альтернативный вариант - использовать софт-рейд не полуаппаратный, а полностью софтовый. Благо, у вас не ХР, которая не умеет делать зеркало (не помню насчет рейд5, но кажется, тоже нет), у вас 2003. И вам не нужно ставить системный раздел на рейд0 (чего тоже нельзя сделать в полностью софтовом варианте). К тому же, если вам нужно будет (ну вдруг:) подключить этот рейд к другой машине, вам не придется искать машину с таким контроллером. А по производительности они будут абсолютно идентичны (по крайней мере, в вашем случае).

Есть домашний компьютер, на котором стоит Win7.
Есть желание перенести всю систему целиком на RAID 1, не переустанавливая Windows.
Для этого из 2-х новый дисков (таких же, как тот на котором система) в биосе сконфигурирован рейд 1(его мама поддерживает).
При клонировании диска с системой Acronis видит рейд как рейд 1 и позволяет туда склонировать диск.
Но после клонирования система с рейда не грузится.
Если в биосе выключить рейд, то с дисков, которые стояли в рейде, система грузится отлично.

Значит ли это, что клонировать систему на диски рейда так, чтобы она потом грузилась с рейда нельзя в принципе?
Если есть другой способ, которой позволяет это сделать, подскажите, пожалуйста, кто знает.

было сделано:
1) Подключаем 2 чистых диска, строим РЭИД,
2) грузимся (BootCD Acronis True Image Home 2012 (full)), смотрим, что РЭИД виден - значит, драйвера встали.
3) Запускаем Acronis True Image Home - Утилиты - Клонирование жесткого диска. С рабочего диска на чистый РЭИД.
Все это получилось.

Не получилось загрузиться с рейда.
Вопрос очень конкретный, пожалуйста, не нада общих ссылок, я их смотрела.

Кто-нибудь знает в чем разница между системой, установленной на рейд 1 и системой, установленной на обычный хард. И как это обойти при клонировании?

У меня в биосе есть опция работать с рейдом или без него.
Когда выбран рейд, то я могу войти в отдельную утилиту работы с ним. В этой утилите я создала из 2 хардов raid 1 и он по умолчанию сразу стал загрузочным. (Кажеться, что это изменить нельзя, но я еще раз сегодня дома проверю) Да и если поменять, то зачем мне рейд, с которого я не смогу загрузиться?

Разве то, что Acronis видит рейд не значит, что "драйвера встали" туда, куда они должны были встать?
Просветите, в чем разница, пожалуйста.

В мануле для мамы написано, что драйвера под Win7 и Vista для рейда 1 отдельно ставить до установки системы не нужно, т.к. они уже в них есть. Но после установки системы, в случае, если она установлена на рейд, нужно доставить что-то с диска, который идет в комплекте с мамой специально для рейда.

На самом деле все оказывается гораздо проще и хуже.
Отключила одиночный диск и для проверки работы рейда проинсталировала винду 7 на рейд. Все встало и грузится замечательно. Подключаю одиночный диск и оставляю рейд подключенным. Пока в биосе выбран режим поддержки рейда система не грузится ни с рейда ни с одиночного диска.

В мануале к маме сказано, что в Win7 и Vista дрова для рейда 1 (который мама поддерживает) до установки винды ставить предварительно не нужно, т.к. они есть в этих версиях винды по умолчанию.
Для уверенности, что с проблема не в дровах, я поставила Win7 на рейд с нуля.
Win7 встал на рейд без каких-либо предварительных установок дров. После установки винды, с DVD, идущего с материнской платой, доставлены дрова. Но это уже после того, как винда с рейда загрузилась. Без активного рейда (в винде на IDE диске) я эти дрова даже в меню установки не могу найти.

Но проблема в том, что как только я подключаю третий (не входящий в рейд) диск, система перестает грузиться с рейда. С подключенного третьего диска (на котором стоит другая Win7 без дополнительных дров для рейда) в режиме включенного рейда тоже не грузится.

Получается, что если у меня работает рейд, я не могу в комп добавить еще один отдельный (не рейдовый) жесткий диск?

Сделала описанному вами рецепту, в надежде, что процедура восстановления поможет.
Не помогла. Синий экран остался.
В отличие от XP на Win7 драйвер для рейда не доставлялся. Но что-то она там для исправления загрузки сделала, к сожалению это не помогло.

До сих пор не могу понять почему, когда
новая (установленая с нуля на рейд1) win7 грузится с рейда, при подключении еще одного (не входящего в рейд) диска система грузиться перестает (и с рейд и с отдельно стоящего диска).
Кто-нибудь с этим сталкивался?
Может какие-нить в биосе есть настройки специальные?

Добавлено:
Забороть не удалось, но хоть поведение стало более объяснимым.

Повторный эксперимент с установкой на чистый рейд новой win7, чтобы посмотреть, какие дрова там встают, показал, что система с рейда грузится и с подключенным отдельным диском. Значит 100% дело в драйверах.

Драйвера которые встают, когда Win7 устанавливается на рейд1 по умолчанию, приводят к тому, что я в системе вижу Raid-контроллер Intel(R) ICH8R/ICH9R/ICH10R/DO SATA. Когда доставляю с диска к маме родные драйвера для рейда вижу Intel(R) Desktop/Workstation/Server Express Chipset SATA RAID Controller.

Очевидно, что никаких драйверов в версии винды на моем старом харде, которую я пытаюсь клонировать на рейд1, нет, они туда не вставали при инсталяции. Как их добавить - не понятно.

Пробовала восстановление системы с бекапа на рейд с галочкой universal restore (с бут сектором на этот раз). На этапе universal restore справшивает диск с драйверами. Даю ему установочный Win7, не находит некоторые (по именам посмотрела, это драйвера для USB и аудио). Но восстановленная система с рейда не грузиться. Повторила восстановление, дав диск с драйверами к маме. То же самое. Не работает, зараза.

Удалось успешно клонировать систему на рейд, как и хотелось изначально.

Собственно есть сабж. Win7 x64 Pro. Лицензия ОЕМ.

Установлена обычными способом. Т.е. есть скрытый раздел на 100 мб, где лежат такие файлы и папки как:
boot/%памки с языками разными%
boot/bcd
boot/bootstat.dat
boot/%файлы логов%
bootmgr

Собственно в корне самого диска С нет ничего важного, кроме pagefiles и hiberfil.

Я установил рейд контроллер Promise 4310. Загрузил винду. Поставил драйвера на это устройствго. Установил консоль Promise web PAM. Собрал из двух хдд зеркало.

Потом загрузился с лайвсд, скопировал раздел диска С через Acronis. Раздел который 100мб я НЕ КОПИРОВАЛ. Ну не люблю я его. Считаю в общем случае бесполезным.

Потом развернул этот образ диска с на зеркало. Сделал его основным и активным. В корень нового диска С перенес фаил bootmgr.

И вот что делать дальше? Как дать понять компьютеру что нужно теперь грузиться с этого массива?

Т.е. я в биосе поставил что мол теперь первый в списке загрузочный диск это array1 (так назвал я своё зеркало). Но компьютер при загрузке просто останавливатьеся на надписи Verifing DMI pool data и все - дальше не пытается ничего грузить и ни откуда загружаться.

Я загружался с загрузочного диска с ОС. Подсовывал ему драйвера рейд контроллера и делал автоматическое восстановление параметров запуска. И все равно ничего.

Читайте также: