Как загрузчик BIOS узнает, какой диск использовать?
Вы можете использовать флаг -fдля поиска всех строк в FileB:
grep -v -f FileB FileA
Это почти то, что вы хотите. Но это также удаляет строки, в которых шаблоны из FileBявляются , а не в конце, и вы явно указали, что они должны совпадать только тогда, когда они находятся в конце. Поэтому нам нужно соответствующим образом изменить FileB. Мы можем использовать sed, чтобы добавить regexдля конца строки, который является знаком $:
sed 's/$/$/' FileB
Это выглядит так, как будто ничего не заменяется, но на самом деле это добавление $в каждый конец строки.
Теперь мы можем использовать подстановку процессов, чтобы объединить все это:
grep -v -f <(sed 's/$/$/' FileB) FileA
The first part (stage 1) is stored in the first 448 bytes, which is responsible for passing control to the so-called stage 1.5, located a little later in memory. This stage finally loads stage 2 from the /boot folder, and transfers control to it.
Имена «stage1», «stage1.5» и «stage2» принадлежат GRUB Legacy, то есть версиям GRUB 0.xx. При записи этапа 1 в MBR (или PBR )установщик также запишет в него фактический номер блока диска, где будет расположено начало следующего этапа. Первый блок следующего этапа будет содержать дополнительный программный код и блок-лист , описывающий, где находится остальная часть этапа. Записи черного списка имеют форму «загрузить X блоков, начиная с дискового блока #Y». Если следующий этап был записан на диск как непрерывный (не-нефрагментированный )файл, обычно требовалась только одна запись в черном списке.
Stage1.5 на самом деле был необязательным :было вполне возможно вообще не устанавливать stage1.5, а просто загрузить stage1 напрямую для stage2. Стадия 1.5 будет содержать ровно столько кода, чтобы понять один тип файловой системы; stage2 будет содержать все поддерживаемые драйверы файловой системы, что сделает его намного больше. Таким образом, stage1.5 может быть встроен в обычно -неиспользуемое пространство между MBR и началом первого раздела.
(Современные диски с разделами MBR -теперь начинают первый раздел ровно с 1 МБ от начала первого диска, то есть с блока #2048, чтобы обеспечить оптимальное выравнивание данных для больших систем хранения. Это оставляет гораздо больше неиспользуемого пространства между MBR и началом первого раздела, чем старое соглашение начинать первый раздел с C/H/S 0/1/1.)
Как stage1.5, так и stage2 имели в себе предварительно -выделенное пространство, чтобы установщик мог записать в него идентификатор диска GRUB и имя пути. В случае stage1.5 это идентифицирует раздел и имя файла, в котором фактически находится stage2; в случае stage2 он идентифицирует расположение файла конфигурации GRUB.
GNU GRUB (, т. е. GRUB версии 1.xx и выше )в его BIOS-совместимой -форме полностью пропускает этап 1.5 и использует другие имена:
- то, что было раньше
stage1, теперьboot.img - то, что было раньше
stage2, теперьcore.img
boot.imgпо-прежнему составляет 448 байт, которые встраиваются в MBR, но core.imgсоздается динамически во время установки GRUB из kernel.imgи набора модулей GRUB.
I can see this information being hard-coded into stage 1.5, but how does this deal with drives getting mounted in different orders (there's guarantee that (hd0) and (hd1) will always be the same drive, so hard-coding something like that seems like a brittle strategy.
Фактическое -стандартное соглашение BIOS состояло в том, что любому диску, выбранному в BIOS в качестве диска для загрузки, будет назначен идентификатор 0x80 для функций доступа к диску BIOS, и этот идентификатор будет напрямую сопоставлен с GRUB (hd0). (Древняя MS -DOS также всегда сопоставляла идентификатор диска BIOS 0x80 с диском C:.)
К счастью, BIOS обычно довольно детерминирован в том, как он перечисляет различные контроллеры дисков. Таким образом, пока аппаратная конфигурация и настройки BIOS остаются неизменными, порядок обнаружения дисков остается неизменным от одной загрузки к другой.
Но да, это определенно была хрупкая стратегия; К сожалению,не существовало универсального стандартного способа передачи информации BIOS об обнаружении диска из 16 -битных подпрограмм BIOS в операционную систему, использующую 32 -бит защищенный -режим программирования (или даже 64 -бит ). ]. В результате все 32 -бит или более поздние ОС будут повторно -обнаруживать свои диски с нуля после переключения с загрузчика на основе BIOS -на полный 32 -бит или 64 -бит режим.
Да, BIOS Enhanced Disk Drive Services (EDD для краткости )включает в себя расширение BIOS, которое можно использовать для сообщения основных сведений об обнаружении диска BIOS в ОС с защищенным -режимом... но это расширение было введено довольно поздно, а отчетная часть была необязательной , так что ее доступность далеко не гарантирована.
В системах на основе BIOS -с более чем одним дисковым контроллером это было в основном стандартной головной болью.
Выигрышной стратегией обычно является тщательная проверка параметров загрузки BIOS при первом знакомстве с конкретной моделью оборудования (, возможно, несколько пробных установок ОС ), и как только будет найдена подходящая конфигурация, запишите его и после этого не трогайте настройки загрузки биоса .
Современный GNU GRUB включает команду search, которую можно использовать для выбора разделов диска по их метке, UUID и/или по наличию определенного файла. В современномgrub-mkconfig-сгенерированном конфигурационном файле GRUB 2.xx фиксированные идентификаторы обычно должны быть крайним средством, которое следует использовать только в случае сбоя более ранних searchкоманд.
Таблица разделов GPT стандартно включает уникальные UUID для каждого диска и раздела, а переменные UEFI NVRAM фактически указывают местоположение загрузчика, используя UUID раздела ESP + путь к загрузчику в разделе ESP. Это позволяет создать гораздо более надежную конфигурацию.Также имеется стандартный интерфейс для работающей ОС, позволяющий как считывать загрузочную информацию из прошивки UEFI, так и при необходимости изменять параметры загрузки.