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

[dadv]

За что боролись, называется. И вот оно было надо? У тебя загрузочный диск больше 4GB, что создаёт трудности с MBR?

[netch80]

> У тебя загрузочный диск больше 4GB, что создаёт трудности с MBR?

Ты про весь диск или раздел?
Диск - 512GB.

Но GPT тут дал только малую часть проблем. Основное таки плохие манеры GRUB и интерференция с такими же у BIOS.

[dadv]

Я, конечно, имел в виду 2TB - ограничение MBR. В смысле, почему не использовать старый давным-давно отлаженный код для работы с MBR?

[netch80]

> В смысле, почему не использовать старый давным-давно отлаженный код для работы с MBR?

Код для работы с GPT тоже уже лет 15 как отлажен.

[dadv]

Пункты 2,3,4,4б это проблемы кода загрузчика в части работы с GPT. Остальное - проблемы кода BIOS.

[netch80]

> Пункты 2,3,4,4б это проблемы кода загрузчика в части работы с GPT.

Нет.
В 2 проблем нет только при идентичности таблицы разделов на обоих дисках (старом и новом), а не потому, что якобы с msdos разбиением всё отлажено, а с GPT нет.
В 3 наличие раздела в явном виде помогает избежать костылей типа "ставить в нераспределённую область и надеяться, что никто не затрёт".
4 никак не зависит от типа таблицы разделов, это универсальное свойство.

[dadv]

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

Ты хочешь сказать, что проблема 2 в GRUB есть как и с MBR, так и с GPT?

Проблема 3 это четкая проблема с кодом, почему-то фряха всю жизнь обходится без установки чего-либо в нераспределенную область, а ставит boot2 или zfsboot в область своего слайса.

[netch80]

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

Вообще я в начале поста сказал, что установка на новый диск. Значит, был и старый :)
Если подробнее - был старый с MSDOS разбиением и загрузкой через GRUB (GRUB2, Ubuntu 20.04), а я воткнул новый SSD и начал перенос части разделов на него.
И вот этот SSD я, кроме прочего, разбил в GPT стиле.

> Ты хочешь сказать, что проблема 2 в GRUB есть как и с MBR, так и с GPT?

Да. Потому что вот когда я сказал update-grub (который пересобирает конфиг) после устаканивания с новым, обнаружил, что в новом конфиге полно `insmod part_gpt` и нет `insmod part_msdos`.
Позже я нашёл опцию GRUB_PRELOAD_MODULES для /etc/default/grub, в которой можно заставить грузить оба, но это ещё её включить надо. Ну или руками исправить автогенерированный конфиг.

> Проблема 3 это четкая проблема с кодом, почему-то фряха всю жизнь обходится без установки чего-либо в нераспределенную область, а ставит boot2 или zfsboot в область своего слайса.

1. Ох уж эти мне сказки, ох уж эти мне сказочники...
Поищи по истории, когда /boot/boot0 был не 512 байт, а 1024. (Мог называться boot0ext.) Это было долго. Затем нашли, как его сократить. Но когда он был 1024 байта - он занимал сектора 0:0:1 (MBR) и 0:0:2. И вот 0:0:2 (LBA=1) это как раз начало неразмеченной области (по практическому стандарту primary 1 может начинаться с 0:1:1, иначе куча средств сойдут с ума).

2. Решение ставить загрузчик в конкретный раздел (не всегда слайс, слайсом во фряхе называются MSDOS разделы) это потеря 7.5KB на каждый раздел (заметь, неважно - он 'a', 'e' или любая другая буква). Да, это не проблемная цифра, но уже заметная. И то, даже в это место смогли впихнуть только чтение одной конкретной файловой системы (у тебя есть загрузка с UFS или ZFS, и загрузчик должен соответствовать). У тебя там нет возможности сделать универсальный читатель всего.
К тому же это принципиально не сработает с logical-разделами внутри extended, ты ограничен возможностью грузиться этим механизмом только с primary.
GRUB'у пофиг, он грузит любой раздел. Я ему выделил 128MB, он создал образ на ~33MB, зато впихнул все модули, какие нужны, вплоть до framebuffer.

3. Поверх GPT эту ерунду не стали делать и ввели отдельный тип раздела freebsd-boot.
Кстати, GRUB знает такой подход и с MSDOS partitioning.

Расхваливая подход фряхи, ты не замечаешь, насколько он ограничен. Ты можешь сделать какой-то другой тип FS загрузочной? Не можешь. В линуксе через initrd/initramfs можно хоть чёрта лысого грузить. Оно громоздко в управлении, но это следствие гибкости. В крайнем случае можно свой минимальный скрипт подсунуть...

[edo-rus.livejournal.com]

Я, конечно, имел в виду 2TB - ограничение MBR

так диски больше 2ТБ уже есть, и массово (во всяком случае у меня в хозяйстве уже достаточно машин, на которых просто нет накопителей меньше 2ТБ). проще везде использовать gpt, чем метаться между gpt и mbr.

пока к gpt у меня только одна претензия: в случае виртуалок при расширении диска приходится делать дополнительное телодвижение для исправления копии таблицы разделов, лежащей в конце диска.

[permeakra]

Все-таки, диск с системой (и, следовательно, загрузочный) - это, как правило, SSD не более 2TB, даже если в системе есть HDD большого объема. Поэтому скорее нет смысла пытаться использовать GPT без острой необходимости.

[netch80]

> Поэтому скорее нет смысла пытаться использовать GPT без острой необходимости.

А почему бы не сказать, что нет смысла использовать MSDOS partitioning без острой необходимости?

GPT, в среднем,
1) Проще в устройстве - плоская схема вместо безумных "матрёшек" вложенности разделов.
2) Гарантированно проще выравнивается (универсально совместимым образом) на границы типа 4KB и 1MB (важно для огромной доли HDD с физическими 4K блоками; для SSD; для LVM и RAID поверх дисков).
3) Не теряет дорожку (63 сектора в стандартной разбивке) на каждый вложенный раздел внутри extended раздела.
4) Не имеет тараканов с потенциальным противоречием CHS и LBA адресаций каждого раздела, не требует поддержки CHS эмуляции (на дисках больше 8GB с заведомо некорректными значениями).
5) Поддерживает широчайшее пространство типов разделов (одного байта в MSDOS очень быстро перестало хватать, начались конфликты).
6) Хранит UUIDы разделов для уникальной адресации.
7) Позволяет именовать разделы для лёгкого понимания, что в них.

Ну и накой тут нужна старая проблемная схема?

[dadv]

При этом минусов у GPT тоже хватает и на практике (а не в теории) они перевешивают теоретические плюсы. На практике extended-разделы MBR не нужны вообще, вместо этого можно и нужно обходиться менеджерами томов внутри единственного MBR-раздела (в ZFS встроенный, ещё есть disklabel/bsdlabel, ну и в линуксах своё). Проблемы выравнивания просто не существует, это вопрос качества кода и дефолтов софта для создания разделов. Проблемы "CHS-адресации" уже много лет как не существует на практике, никого не колышит "противоречие CHS" и вообще эмуляция CHS давно не нужна. На практике ограниченность типов разделов чисто теоретическая, реально никого не колышат конфликты, потому что все валидируют содержимое раздела, и GPT эту валидацию не отменяет. UUID-адресация вероятно хороша, но вынос её на уровень пользователя/админа это полный идиотизм, такие идентификаторы не должны юзера колебать от слова никак, на то есть номера от 1 до 4 в MBR и метки в GPT. Нумерация от 1 до 4 - ни разу не проблемная, а если кому-то она создаёт проблемы, то наверное ему нужно подумать о смене профессии :-)

[edo-rus.livejournal.com]

При этом минусов у GPT тоже хватает и на практике (а не в теории) они перевешивают теоретические плюсы.

так вы пока минусов не назвали )
я один назвал (служебная информация в конце диска требует дополнительных действий в случае изменения размера диска), но по мне он не особо существенен.
а вот поддержка дисков более 2ТБ всё-таки важна.

[permeakra]

Это все смотрится некрасиво, если смотреть изнутри. Типовой же пользователь же с этим просто не сталкивается. Для конечного пользователя главное - отсутствие чудес, т.е проблем с труднонаходимым решением, и с MBR чудес гарантированно меньше, потому что она древняя как говно мамонта, поддержку вынужденно встроили везде, а типовые проблемы вылезли еще в 1990х. Это особенно критично для загрузочного диска, потому что проблемы с ним могут вылезти в невозможности выйти в интернет и найти решение.

[edo-rus.livejournal.com]

Все-таки, диск с системой (и, следовательно, загрузочный) - это, как правило, SSD не более 2TB

раз (https://www.hetzner.com/dedicated-rootserver/ax101/configurator#/)
два (https://www.hetzner.com/dedicated-rootserver/sx64/configurator#/)

притом в первую конфигурацию ещё можно добавить диски меньше 2ТБ (но зачем?), во вторую же уже нельзя.

и да, локальные машины с ssd больше 2ТБ у меня тоже есть, вот пример с ещё не пущенной в прод:

root@debian:~# lsblk -d
NAME    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
nvme2n1 259:0    0   3.5T  0 disk 
nvme0n1 259:1    0   3.5T  0 disk 
nvme1n1 259:7    0   3.5T  0 disk 

P. S. предвижу возражение «ну это сервера, для десктопов это всё неактуально».
но зачем умножать сущности? тем более, что для десктопов это пока не очень актуально.

[dadv]

Если на сервере, подобном тем, что по ссылке, нет и нельзя добавить пару небольших SSD для загрузки операционки, то я делаю так в случае FreeBSD: средствами менеджера GRAID создаю из N больших дисков один массив из N+1 тома.

Первый том это мелкое зеркало, занимающее первые 8-10 гигабайт каждого из дисков, в нулевом секторе создаю MBR с единственным разделом, покрывающим весь этот зеркальный том, на разделе операционная система в виде небольшого отдельного пула ZFS (можно и UFS при желании). Для системы этот раздел виден в качестве устройства /dev/raid/r0. GRAID обеспечивает тупое поблочное программное зеркалирование этого тома, автоматически зеркалируются загрузчики всех уровней, бесплатно.

Оставшееся пространство каждого диска GRAID представляет в виде индивидуальных (SINGLE) томов /dev/raid/r1, ..., /dev/raid/rN и они отдаются ZFS под второй основной пул RAIDZ или RAIDZ2.

GPT на таком сервере просто низачем не нужен.

[netch80]

> P. S. предвижу возражение «ну это сервера, для десктопов это всё неактуально».
но зачем умножать сущности? тем более, что для десктопов это пока не очень актуально.

Ну вообще-то для десктопа, на котором склад накачанного видео, HDD на какие-нибудь 8TB это более чем актуально ;)

Хотя да, на такой лучше сейчас ставить SSD под систему и HDD под остальное.

(Вариант с персональным NAS подразумевается, но не обязателен.)

[edo-rus.livejournal.com]

0. а почему не efi?
по мне это куда более прямой способ загрузки: весь загрузчик ОС лежит в файлах, а не размазан по MBR и неразмеченному пространству, нет int 13h с ограничением на размер дисков (тот же nvme без option rom редкий bios через int 13h отдаёт), запускается сразу из x64.

вообще где-то 16-битный режим кроме бутлоадера сейчас используется? не удивлюсь, если его поддержку скоро выкинут из процессоров )

3. ЕМНИП у меня в такой конфигурации grub вообще не ставился.

4б. не понял, это как? сам бутлоадер (а не его утилиты) перезаписывал файлы конфигов?

6. обычно есть какая-нибудь горячая кнопка для boot menu.

[netch80]

> 0. а почему не efi?

Пока я оставил место для EFI раздела, но дальше будем смотреть. Все изменения за один раз - слишком.

> весь загрузчик ОС лежит в файлах, а не размазан по MBR и неразмеченному пространству

GRUB на GPT ставит в MBR промежуточный пускач, да, но дальше он хочет "BIOS boot partition", куда и записывает продолжение (полный толстый собранный под эту загрузку core.img).
Хочет 1MB, но разделом.

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

> нет int 13h с ограничением на размер дисков (тот же nvme без option rom редкий bios через int 13h отдаёт), запускается сразу из x64.

NVME у меня там нету, SSD по SATA. А ограничение на размер по int 13h начали снимать ещё до 2000-го, через вызовы с LBA, там 64 бита. Глюки, конечно, были по дороге, но сейчас все зачищены.

> вообще где-то 16-битный режим кроме бутлоадера сейчас используется? не удивлюсь, если его поддержку скоро выкинут из процессоров )

В SMM режиме. Возможно, ради него и тянут.
Ну и вообще 32 бита без protected - x86 не умеет (хотя бы формально). Придётся вводить real 32-bit, а им облом.

> 3. ЕМНИП у меня в такой конфигурации grub вообще не ставился.

Обычно таки ставится. На лаптопе вот:

root@lessie:/boot/efi/EFI/ubuntu# ls -la
total 4272
drwx------ 2 root root    4096 Mar 31  2020 .
drwx------ 5 root root    4096 Mar 31  2020 ..
-rwx------ 1 root root     108 Aug  8  2020 BOOTX64.CSV
-rwx------ 1 root root     112 Jun  5  2021 grub.cfg
-rwx------ 1 root root 1734528 Jun  5  2021 grubx64.efi
-rwx------ 1 root root 1277024 Aug  8  2020 mmx64.efi
-rwx------ 1 root root 1341544 Aug  8  2020 shimx64.efi

Я не разбирался, что там, в деталях, но этот конфиг grub всего лишь говорит загрузить второй GRUB по цепочке уже с раздела /boot.
А второй GRUB уже даёт выбирать ядра и всё такое.

> 4б. не понял, это как? сам бутлоадер (а не его утилиты) перезаписывал файлы конфигов?

Я сам до конца не понял, но он переделывал их в памяти (не на диске), меняя UUID стартовых разделов. Или же он брал откуда-то ещё старый конфиг, но откуда - я не смог понять. Это ещё надо изучить.

> 6. обычно есть какая-нибудь горячая кнопка для boot menu.

Её и нажимал (F11 на этой матери), и вот тогда появлялся список... выбираю пункт со флэшкой, и оно молча его пропускает и грузит с диска.

[edo-rus.livejournal.com]

Обычно таки ставится. На лаптопе вот:

эээ… я что-то потерял нить, при чём тут листинг efi-раздела?
я говорил, что grub-legacy на диске с gpt у меня безальтернативно требовал специальный раздел, о котором вы сами же пишете

дальше он хочет "BIOS boot partition", куда и записывает продолжение (полный толстый собранный под эту загрузку core.img)

[netch80]

> я говорил, что grub-legacy на диске с gpt у меня безальтернативно требовал специальный раздел, о котором вы сами же пишете

А, понял.

На это мне GRUB ругался "не хочу ставиться в режиме списков блоков, это некузяво", но с --force поставился.

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

[edo-rus.livejournal.com]

вообще где-то 16-битный режим кроме бутлоадера сейчас используется? не удивлюсь, если его поддержку скоро выкинут из процессоров )

наткнулся на свой старый коммент, я угадал
https://www.opennet.ru/opennews/art.shtml?num=59164

[muwlgr]

Однажды напишу в жж/дв о своём способе создания гибридных загрузочных флэшек (съёмных дисков), одинаково хорошо работающих и под старым bios, и под uefi. Общий принцип в том, что если установить grub-pc, прогнать grub-install на новое устройство и затем снести grub-pc и поставить grub-efi , то код grub-pc на bios-устройстве сохранится.
Сейчас только отмечу, что когда я устанавливал новый диск в десктопную мамку, я сразу создавал на нём второй mbr-раздел с нижней границей 1024*63*16==1032192 512-байтных секторов, и затем первый mbr-раздел с типом ef от дозволенной нижней границы (обычно 2048) до следующей дозволенной верхней (обычно 1032192-1).
Также добавлю, что таблица разделов gpt нужна только для дисков объёмом 2.5 ТБ или больше, т.е. где число 512-байтных секторов превышает 2**32-1 . Ну или если этот фиксированный или съёмный диск не предполагается использовать на bios/mbr-системах вообще никогда в будущем.
И в заключении отмечу, что использование Linux LVM2 значительно упрощает перенос всех существующих файловых систем на новый диск или диски через pvmove.

[dadv]

Если устройство не загрузочное, ему вообще не нужны таблицы MBR/GPT. Как минимум под FreeBSD его в зависимости от задач можно целиком отдать под ZFS, или под GRAID, или под disklabel - в общем, под любой менеджер томов с 64-битной адресацией.

[netch80]

> И в заключении отмечу, что использование Linux LVM2 значительно упрощает перенос всех существующих файловых систем на новый диск или диски через pvmove.

Вот это единственное, до чего руки не дошли из-за лени ;(
Надо таки разобраться и освоить LVM даже с загрузкой. Причём я когда-то его использовал, но уже забыл детали.
А польза достаточно очевидна - не только то, что ты говоришь, с переносом, но и с расширением, если старых недостаточно.

> Сейчас только отмечу, что когда я устанавливал новый диск в десктопную мамку, я сразу создавал на нём второй mbr-раздел с нижней границей 1024*63*16==1032192 512-байтных секторов, и затем первый mbr-раздел с типом ef от дозволенной нижней границы (обычно 2048) до следующей дозволенной верхней (обычно 1032192-1).

Костыль понятный, но сейчас уже вряд ли нужен.