Почему boot.ini работает с разделом (1), но не с разделом (2), когда Windows на самом деле находится в разделе 2?
У меня есть диск MBR с установкой Windows XP в разделе 2, который загружается с использованием записи boot.ini, в которой указаноpatition(2). Таблица разделов изначально выглядит так:
1. Windows recovery partition
2. Windows XP
3. Linux
4. Linux
Затем я удаляю раздел №1 и заменяю его расширенным разделом, в результате чего получается следующая таблица:
1. Extended partition
2. Windows XP
3. Linux
4. Linux
Теперь Windows XP не загружается, жалуясь на отсутствиеhal.dll. Номер раздела в boot.ini не изменился, как и номер раздела в таблице разделов MBR. Тем не менее, когда я меняю загрузочную запись Windows XP в boot.ini сpartition(2)кpartition(1)Windows XP снова запускается без проблем. Я хотел бы знать, почему именно.
Я читаю https://neosmart.net/wiki/rebuilding-boot-ini-file/ , в котором говорится о нумерации разделов boot.ini:
раздел(y): номер раздела на диске rdisk(x). Раздел (y) начинает отсчет с 1, поэтому первый раздел — это раздел (1), второй — раздел (2) и т. д. Раздел (y) сначала считает первичные разделы, а затем логические разделы. Однако сам расширенный раздел («контейнер» для логических разделов) не учитывается. Эти номера взяты из таблицы разделов в основной загрузочной записи . Обычно это тот порядок, в котором они были созданы, но не обязательно совпадает с порядком, в котором они появляются на диске.
Это действительно правда? Потому что, с моей точки зрения, я, похоже, изменил номера разделов, просто заменив запись раздела 1 в MBR.
Для записи,partedсообщает мне, что раздел Windows XP действительно имеет номер 2, иfdiskговорит мне, что это/dev/sda2(хотя я не совсем готов доверять схемам нумерации устройств, которые точно соответствуют номерам разделов MBR). Даже если операция удаления и замены раздела 1 действительно привела к перезаписи всей таблицы разделов MBR , наверняка этот вывод должен подтвердить, что раздел Windows все равно действительно оказался в нужном месте?
Я что-то упускаю в своем понимании здесь?
2 ответа
Мне кажется, что ваш пост содержит все элементы для понимания ответа, хотя может быть применено более одного правила подсчета (как указано в вашем комментарии).
Если порядок создания раздела является определяющим при распределении номеров, то причина в том, что вы удалили раздел №1, превратив, таким образом, №2 в новый №1.
Новый раздел расширенного раздела, который вы создали, следует за всеми остальными записями в порядке создания, поэтому предположительно теперь у него больший номер (возможно, № 4, поскольку теперь он последний).
Чтобы уточнить, в приведенной вами цитате упоминается дата создания, хотя на самом деле она, вероятно, означает порядок разделов. Это будет то же самое, если записи удаленных разделов в таблице не будут повторно использоваться после удаления.
Алгоритм распределения номеров разделов кажется очень простым:Windows распределяет номера разделов по порядку в таблице разделов, а не по их положению. Таким образом, раздел № 1 можно найти в записи таблицы 2, если запись номер 1 пуста или тип, который BIOS будет игнорировать (я сомневаюсь, что такие типы существуют).
Имейте в виду, что вся возможность «ARC-путь» в boot.ini не является встроенной в системы BIOS/MBR. Он происходит из прошивки типа ARC, которая присутствовала в системах DEC Alpha — исходной платформы, для которой была создана Windows NT, и предшественника сегодняшней прошивки типа EFI — и весь NTLDR Windows (и boot.ini) просто эмуляция того, что обычно обеспечивается прошивкой на более продвинутых платформах.
Поэтому, когда загрузчик Windows интерпретирует пути ARC в системах BIOS, он пытается скрыть специфические особенности MBR, такие как «расширенные разделы», и представить общее, плоское представление томов внутри (из-за отсутствия лучшего термина). Поскольку расширенный раздел напрямую не представляет собой что-то, что могло бы содержать данные, здесь он игнорируется.
У меня ужасное ощущение, что мой ответ кроется в процитированном предложении "Однако сам расширенный раздел ("контейнер" для логических разделов) не учитывается"...
К счастью, просочившийся исходный код Windows XP по-прежнему доступен на GitHub от Microsoft. Покопавшись в нем, номер раздела из пути ARC в конечном итоге обрабатываетсяHardDiskPartitionOpen(), в котором есть код для намеренного пропуска слотов раздела MBR из подсчета, если они а) пусты (тип 0x00), б) защитный раздел EFI (0xEE) или в)IsContainerPartition()(0x05 или 0x0F). Другими словами, он не учитывает слоты разделов, предназначенные для других целей, кроме непосредственного хранения данных.
(Кроме того, положение «расширенного» раздела не имеет значения; он всегда обрабатывается после обработки основных слотов MBR.)