GRUB и проблемы переноса загрузочного раздела

[netch80]

Как сделать установку нового диска в десктоп незабываемой от полного непонимания, что вообще творится и на каком свете находишься? Надо всего лишь просочетать несколько факторов:

1. Если диск не упомянут в пункте "Hard drive BBS priorities" в настройке BIOS, то та его не отдаёт в I/O через int 13h. В результате GRUB не может его увидеть.

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

2. Простых надёжных способов собрать grub.cfg под новые условия (смена корневого раздела) нет, а замена UUID редактором не позволяет подсказать, что надо было ещё добавить "insmod part_gpt" (на старом такого не было).

3. На диске с GPT но без "BIOS boot partition" GRUB ставит свой core.img урезанным и неверно работающим. Но чтобы понять, что не так, его родной документации не хватает, там связь замолчана.

4. Если GRUB не нашёл по указанным UUID и пути типа (hd1,msdos5) раздела со своими модулями и конфигами, он хватает первый попавшийся, который нашёл.

4б. При этом он ещё перезаписывает UUID в параметрах загрузки, чтобы совсем уже никто не догадался.

5. Спросить, по какому пути GRUB прошёл и прочитал свои конфиги, откуда грузил модули - невозможно.

6. На то, загрузит ли BIOS внешнюю флэшку, если она была вставлена до перезагрузки, влияет погода на Марсе. Если нет - пункт в boot menu есть, но молча игнорируется.

Таки взлетел. Выдыхаю:)

Comments

[edo-rus.livejournal.com]

И не нужно на практике. Всё, что должен сделать код в MBR это прочитать "бутсектор" раздела с абстрактной операционной системой и передать ему управление. Код из этого первого сектора конкретной операционки уже умеет грузить свою операционку, универсальный читатель просто низачем не нужен.

а меню выбора вариантов загрузки тоже в mbr запихаем?

Код из этого первого сектора конкретной операционки уже умеет грузить свою операционку

и что в этом подходе хорошего?
кстати, а если раздел с zfs сделать активным, то это работает?

"отредактировал таблицу разделов" из-под загруженной операционной системы или перед загрузкой OS средствами мультизагрузчика из его меню - однохренственно это.

вот именно, что если у нас есть загрузчик с вариантами загрузки (а он есть, это удобно), то и признак активного раздела не нужен.

Десктопный дуалбут всегда таким был. Мы же сейчас не про гипервизор с виртуалками?

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

[dadv]

> а меню выбора вариантов загрузки тоже в mbr запихаем?

При таком подходе всё меню выбора вариантов это список непустых разделов с типами, подсказка кнопочки загрузки с другого (других) дисков, переход на PXE-загрузку средствами BIOS (если поддерживается). Всё это влезло в boot0, так что да, в MBR. Варианты загрузки операционки пусть рисует уже загрузчик этой самой операционки (NTLoader, фрёвый boot2/loader etc.)

> и что в этом подходе хорошего?

Что хорошего в том, что винду грузит виндовый загрузчик, фряху фрёвый, а линукс - линуксовый? Всё хорошо.

> кстати, а если раздел с zfs сделать активным, то это работает?

Да, работает - именно так у меня рабочая станция сделана, с ZFS-only в слайсе MBR, туда вместо boot2 прописывается zfsboot(8).

> признак активного раздела не нужен.

Признак активного раздела позволяет загрузчику в MBR хранить этот самый признак в самой MBR, влазя в 512 байт :-)

[edo-rus.livejournal.com]

Всё это влезло в boot0, так что да, в MBR.

нет, я не спорю с тем, что так можно сделать. но неужели вы считаете это правильным?

Да, работает - именно так у меня рабочая станция сделана, с ZFS-only в слайсе MBR, туда вместо boot2 прописывается zfsboot(8).

а теперь как это происходит в linux с каким-нибудь systemd-boot:
есть специальный раздел, отформатированный в fat32. bios монтирует эту файловую систему и запускает исполняемый файл. тот отображает меню, пользователь выбирает какой-то пункт, и, если это линукс, то запускается ядро линукса, которое, опять же, лежит на этой файловой системе и является запускаемым файлом efi.
никаких «умести код в 512 байт (на самом деле сильно меньше)», «распихай куски загрузчика в незанятое место на диске», «разбирай zfs из загрузчика чтобы прочитать файл ядра».

[dadv]

> BIOS монтирует эту файловую систему

В данном случае это делает EFI, но не будем придираться. Вот тут как раз самая мякотка - в дизайне GPT как таковой нету поддержки дуалбута, в отличие от MBR, потому что наличие в мультизагрузчика в единственном загрузочном разделе это не заслуга GPT. И вы наверняка знаете, почему так, и что в дизайне UEFI предусмотрены настройки environment и OS selection, только кривости реализации этого в конкретных прошивках UEFI будут чинить ещё лет десять. В то время как в MBR оно just works и работало изначально за счет флага active.

[edo-rus.livejournal.com]

В то время как в MBR оно just works и работало изначально за счет флага active.

не знаю, видимо, мы с вами в несколько разных мирах живём )
я привык, что grub ставится в mbr и наличие этого флага уже ни на что не влияет.

[netch80]

> потому что наличие в мультизагрузчика в единственном загрузочном разделе это не заслуга GPT

У GPT нет никакого "единственного загрузочного" фиксированного навсегда раздела.
Если ты про EFI partition, то он содержит список вариантов, а не один вариант.
Если ты про флаг активности, то см. вики: бит 2 в атрибутах. Legacy, как раз для любителей старинных извращений.

> В то время как в MBR оно just works и работало изначально за счет флага active.

Ну так свой загрузчик и сейчас ставится в пол-пинка. Есть GRUB для EFI, которому можно в тот же EFI раздел сложить конфиг с меню.

[dadv]

> распихай куски загрузчика в незанятое место на диске

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

> разбирай zfs из загрузчика чтобы прочитать файл ядра

И это работает хоть с UEFI, хоть без, и даже на ARM и MIPS без UEFI, где нет FAT32 и некому больше читать "файл ядра". Нет никаких причин не использовать то же самое и для случая с UEFI.

[edo-rus.livejournal.com]

И это работает хоть с UEFI, хоть без, и даже на ARM и MIPS без UEFI

на тех железках, что проходили через мои руки, бутлоадер умеет читать ядро/инитрамфс из отдельного места, чтения первого сектора раздела и запуска кода оттуда я не встречал.

[dadv]

> но неужели вы считаете это правильным?

Считаю ли я правильным, что мультизагрузчик просто читает основной загручик операционки из бутсектора выбранного раздела и запускает его? Да, считаю. Это позволяет не трогать код мультизагрузчика без крайней необходимости. Можно загружать разные версии разных операционок, установив однажды мультизагрузчик и практически его более не трогая. Именно так вообще должен работать хороший код.

[edo-rus.livejournal.com]

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

[netch80]

> так efi позволяет то же самое: каждая операционка оформляет свой загрузчик как efi executable.

А вот тут начинаются проблемы: написать и скомпоновать EFI executable это та ещё морока с отдельным комплектом средств разработки. Сначала тяжело громоздкая логика написания самого кода (которая слегка напоминает MS COM, с объектами - прокси интерфейсов, и вызовами методов через их GUIDы), не то чтобы сложная, а именно громоздкая. Потом отдельный комплект средств генерации выходных файлов в MS формате (подпиленный COFF); к счастью, стандартные binutils это умеют, но надо ключи задавать и ещё и собрать, чтобы это было в комплекте.
Специалисты по написанию под EFI не получатся за короткое время ни из линуксовых, ни из виндовых программистов; это по факту отдельный скилл.
Ещё и испытывать в эмуляторах сложновато (достаточно много разнообразия у реального железа в стилях реализации того самого EFI).

[dadv]

Да, в теории. Что на практике происходит в действительных реализациях EFI с этим меню - в курсе? А ещё, GPT бывает без EFI и тогда облом.

[netch80]

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

Согласно RBIL такому загрузчику передаётся:

(Table 00653)
Values Bootstrap loader is called with (IBM BIOS):
        CS:IP = 0000h:7C00h
        DH = access
            bits 7-6,4-0: don't care
            bit 5: =0 device supported by INT 13
        DL = boot drive
            00h first floppy
            80h first hard disk

Загрузчик второго уровня (как boot1) должен пересканировать таблицу заново, опознавая свой загрузочный раздел по двум признакам: 1) тип раздела (boot1 фрёвый ищет 0xa5), 2) признак активности (который отличает несколько таких разделов, если есть). Отсюда растёт костыль, что boot0 должен переставлять признак активности согласно выбранному варианту загрузки.

Никакого средства передачи дополнительно, какой же был сделан выбор и где начинается выбранный раздел, в этот протокол никто не ввёл.

Поэтому, загрузчик типа boot1, используя обращения d-1342 (AH=42h/int 13h) или, если не поддерживается, B-1302, перечитать корневую таблицу, вычислить что ему делать (какой раздел грузить) по описанной эмпирике и грузить с него. Или, если он вместо этого использует стиль LILO/GRUB, начать развёртку с заранее вписанных в него нескольких конкретных блоков, чтобы прочитать следующую фазу загрузчика, но тогда он вообще не будет опираться на данные от предыдущего загрузчика (даже косвенные в виде признака активного раздела).

[dadv]

> я привык, что есть меню загрузчика, где можно выбрать варианты загрузки.

Да сколько угодно. Загрузчик из MBR стартует код из бутсектора активного раздела, если никто не нажал кнопочку выбора другого раздела в течение указанного таймаута и сразу на экране появляется это самое ваше меню с вариантами загрузки, рисуемое нативным загрузчиком операционки, будь это NTLoader, фрёвый boot2 или дальше loader, или линуксовый загрузчик.