Вот, не кажется мне MS Windows такой дружественной, как утверждают её пользователи. Ничего удивительного, впрочем: сам я её пользователем практически не являюсь, и сталкиваюсь с ней преимущественно тогда, когда не только клиент, но и ближайший win-администратор не может получить от компьютера под управлением этой ОС то, что им бы хотелось. Безусловно, я не являюсь знатоком MS Windows, а с MS Office (да ещё каким-нибудь модерным) и вовсе не знаком, но зато я неплохо знаю, как организуется хранение информации, происходит загрузка IBM PC, определяются PCI-устройства, осуществляется сетевой обмен, «работают» вирусы и ещё чуть-чуть. Так вот и оказываюсь время от времени «последней инстанцией» для своих win-коллег. Ну, что ж, бывает. Интересно даже...

Довольно часто поводом для таких прецедентов являются проблемы загрузки. Лично я их источником полагаю завуалированное желание MicroSoft видеть на отдельном компьютере только одну ОС. Или даже только одну инсталляцию (если речь об инсталляциях MS Windows). Ну, не существует объективных трудностей для наличия на одном компьютере нескольких загружаемых систем. Не считая аппетитов M$, разумеется.

Почти также упорно MicroSoft сопротивляется клонированию разделов со своей ОС. Я понимаю: есть EULA и «дух» её (если не «буква») убеждает нас, что ОС покупается для однократного и исключительно личного использования (как некоторые товары медицинского назначения — не будем уточнять какие). Но никто не убедит меня, что пользователь не имеет права добавить к предустановленной на ноутбуке Vista честно купленную пару лет назад XP. Или перенести всё это «хозяйство» на винчестер большего размера.

Вот тут-то и требуются «независимые» от MS приёмы: мультизагрузка, способы маскирования разделов, копирование внесистемными средствами и т.д. и т.п. И всё бы хорошо (чего-чего, а этого добра в мире open-source предостаточно), да только заканчивается всё, в конечном счёте, загрузкой всё той же MS Windows, а, значит, на последнем этапе мы опять «отдаёмся» на милость этой ОС. А она, сердешная, имеет «родимое пятнышко» ещё от CP/M — именование устройств и разделов буквами алфавита. Зачем? Понятия не имею. Но тысячи абсолютных ссылок в registry — это таки «класс». Ну, не хотят они использовать единую файловую систему, ладно. Так нумеровали бы устройства, что ли. И далась им эта вертикальная совместимость с «зародышевыми» ОС...

Всё бы ничего, пока на IBM PC один активный первичный раздел, но если нет... Известное правило «загружаемый раздел — С:, логические начинаются с D:, остальные первичные — после» даёт самые неожиданные результаты в зависимости от количества primary разделов, CD-приводов, способов маскирования, использовавшихся при инсталляциях второй и последующих, соотношения SATA/IDE винчестеров, наличия RAID-ов и т.д. Именовать берутся все: BIOS, загружаемые системы, все эти PQMagic-и и Acronis-ы... Нетрудно догадаться, что эти именования часто не совпадают. И вот «буква» таким образом поименованного раздела «впечатывается» в registry эксплуатируемой системы. Уже, возможно, нет ни устройств, ни разделов, заставивших присвоить системному разделу имя Е: (и так далее), а абсолютные ссылки — есть. Ну, не прелестно ли?

По мнению одного остроумного админа, подобного рода случаи есть «извращения, нарушения правил безопасного секса. Расплата — обычная, переустановка, точнее, установка с нуля». Извращения эти, однако, не так уж редки в среде «продвинутых» пользователей. Помимо уже упомянутой мультизагрузки это может быть и инсталляция в новый раздел (без уничтожения старого, системного), «распад» RAID-а — мало ли? Так можно всё-таки перенести на новый винчестер системный раздел E: (F: и т.п.)? Пробуем...

При всём уважении к «старым-добрым» PQMagic/Ghost, работающим из-под DOS, использовать их смысла не вижу: отсутствие в DOS полноценной поддержки SATA-устройств, USB, NTFS... Знаю, что есть «костыли» и для DOS, но — зачем? Не импонируют также всевозможные Reanimator-ы — у меня, признаться, никогда не хватало терпения дождаться окончания их загрузки. Не проще ли использовать в качестве инструмента какой-нибудь Linix rescue-cd? Например — RIP Кента Роботти.

Итак, исходные данные: есть новый винчестер, на котором предполагается разместить пару-тройку ОС, одна из которых — MS Windows. Причём, перенести оную нужно со старого винчестера, где она находится, по странному стечению обстоятельств, в разделе, скажем, E:. По порядку:
размечаем новый диск каким-нибудь cfdisk/fdisk — кому что нравится;
копируем раздел Е: с помощью partimage. Куда? Да куда хотим: на флэшку, на не-целевой раздел нового винчестера, присоединяемый через USB IDE-драйв, etc.;
восстанавливаем с помощью всё той же partimage нужный раздел на новом диске;
подгоняем его размер с помощью ntfsresize (на новом диске выделенный раздел, полагаю, больше старого?);
устанавливаем на новый диск grub и загружаем с его помощью ОС из вновь созданного раздела. Не забудьте о флагах активности (загружаемости). В связи с тем, что нынешний grub читает и NTFS, то помимо известного ранее способа загрузки «по цепочке», можно загружать и непосредственно загрузчик XP: boot (hd0,X)/ntldr.

Все упомянутые утилиты из состава RIP и, разумеется, open source.

Не тут-то было, однако... Это Вам не Linux какой-нибудь, где достаточно исправить пару символов в fstab. Старая «новая» система при загрузке полагает себя находящейся на С:, а ссылается, сплошь и рядом, на E:. Практически, происходит следующее: система при загрузке обнаруживает новый том и описывает его в registry (новый параметр HKLMSYSTEMMountedDevices??Volume{...}). Для этого тома выделяется первая незанятая «буква» и создаётся ещё один параметр (HKLMSYSTEMMountedDevicesDosDevicesбуква:). Происходит это без вашего участия, причём позаботиться об этом заранее невозможно: уникальный идентификатор тома MS Windows создаёт по каким-то неведомым (мне, во всяком случае) алгоритмам. На новом винчестере все разделы для данной инсталляции Windows — новые, так что вероятность присвоения разделу гордого имени «C: » — 100%-ная. Ничего хорошего из этого не получается.

Первый выход — выполнить для этого раздела восстановление системы с инсталляционного диска. В результате все критичные для загрузки «стрелки» будут переведены на C:. Добившись загрузки, приводим полученную систему к работоспособному состоянию (все дальнейшие операции выполняются уже под целевой ОС):
проверяем местонахождение swap-файла — он теперь должен быть на C:;
исправляем в registry все ссылки с «E:» и «e:» на «C:». Причём имеются в виду как имена (Value) параметров, так и их значения (Date). Поскольку ссылок этих тысячи, то ни о каких ручных операциях речи быть не может. Все значения исправить одной командой поможет regfind.exe из «Windows 2000 ResKit», а вот для изменения имён придётся загрузить Registrar Registry Manager (Light-версия бесплатна);
не могу, к сожалению, гарантировать, что на этом всё кончится: наверняка окажутся программы, заблокировавшие изменение собственных параметров в registry (всевозможные файрволы/антивирусы славятся этим), а также программы, хранящие настройки в конфигурационных файлах (эдакие unix-приверженцы). В любом случае, их число будет много меньше, чем количество исправлений в registry.

Мне, однако, более симпатичен выход иной: создать на новом диске ещё один раздел и в него также скопировать раздел исходный. Диск-то — новый, а восстановление ещё одного раздела с помощью partimage — дело 10..15 минут. Только создавать раздел нужно так, чтобы запущенная с C: ОС полагала его E:. Это не так и трудно. Если C: — системный, то очередной win-раздел получит имя D:, а следующий — как раз E:. Это при условии, что в исходной системе CDROM назывался буквой «постарше». Если же CDROM назывался D:, то первый же, созданный помимо системного, раздел будет E:. Местоположение и размер создаваемых разделов значения не имеют: всё это временно.

Вот, теперь загрузка проходит без заминки: мы удовлетворили противоречивые желания ОС быть и на C:, и на E: одновременно. Система загружается, обнаруживает новый диск и новые разделы на нём, но их имена теперь уже работоспособности системы не препятствуют. Обнаружение нового диска и разделов приводит к появлению в registry ключей вида HKLMSYSTEMMountedDevices??Volume{...} — по одному на раздел. И это нас устраивает. А вот пресловутое именование заключается в создании соответствующих ключей вида HKLMSYSTEMMountedDevicesDosDevicesбуква:, и оно-то как раз нас не устраивает категорически. Решение очевидно: удалить или переименовать параметр ...DosDevicesE: (буква E:, таким образом, «освобождается») и переименовать параметр ...DosDevicesC: в ...DosDevicesE:. Вспомогательный раздел (вторую копию) можно, разумеется, теперь удалить.

В обоих случаях полагается, что на новом винчестере создаваемый раздел имеет тот же номер, что и на старом. Если это не так, то потребуется ещё и отредактировать boot.ini (хочется верить, что вам известно назначение этого файла в NT). Альтернатива — использование bootcfg/fixboot из состава Recovery Console XP.

Всё, собственно. Умышленно не привожу командные строки ни для linux, ни для windows: «--help» для первых и «/?» для вторых всегда снабдят необходимой информацией. Если же этого окажется не достаточно, то не стоит утруждать себя: следуйте коммерческой парадигме MicroSoft — полагайте инсталляцию ОС товаром разового использования.

Автор: Владимир Попов