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]

Я, конечно, имел в виду 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ТБ всё-таки важна.

[dadv]

Поддержка незагрузочных дисков 2TB+ нуждается в GPT в единственном случае - если диск используется с более чем одной операционной системой, и какая-то из них не понимает разделы второй и каждой надо дать собственный раздел или разделы.

Поддержка загрузочного диска 2TB+ реализуется и без GPT, потому что загрузчики с операционками, слава богу, пока укладываются в два терабайта :-)

Что касается минусов GPT - для системы с одной операционкой это переусложненная фигня и при всей её преусложнённости в ней нет поддержки дуалбута! В тупой MBR есть флаг "активного" раздела и подразумевается, что он может переставляться между разделами в любой момент и любой раздел может быть загрузочным, и где это в GPT? А как вам "резервная копия" данных GPT, для нахождения которой, строго говоря, нужна первая копия, в которой прописано, где именно лежит резерв...

[edo-rus.livejournal.com]

Поддержка загрузочного диска 2TB+ реализуется и без GPT, потому что загрузчики с операционками, слава богу, пока укладываются в два терабайта :-)

не очень понял что вы предлагаете.
да, я могу linux/windows загрузить с диска с таблицей разделов MBR и разделами в пределах 2ТБ. но при этом остальная часть диска останется неиспользуемой.

Что касается минусов GPT - для системы с одной операционкой это переусложненная фигня

да в чём переусложнённая-то?

при всей её преусложнённости в ней нет поддержки дуалбута! В тупой MBR есть флаг "активного" раздела

то есть вы так себе представляете дуалбут? «загрузился, отредактировал таблицу разделов, перезагрузился»

А как вам "резервная копия" данных GPT, для нахождения которой, строго говоря, нужна первая копия, в которой прописано, где именно лежит резерв...

строго в конце диска

[netch80]

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

В GPT есть флаг активности раздела, читай доки внимательно. А вот то, что он никому не нужен, показывает то, насколько он реально нужен ;))

> А как вам "резервная копия" данных GPT, для нахождения которой, строго говоря, нужна первая копия, в которой прописано, где именно лежит резерв...

И снова читай доки, а не перепев от Мойши.

> Two GUID Partition Table Header structures are stored on the device: the primary and the backup. The primary GUID Partition Table Header must be located in LBA 1 (i.e., the second logical block), and the backup GUID Partition Table Header must be located in the last LBA of the logical device.
(UEFI 2.0 Spec, January 31, 2006)

Все прочие варианты это на период изменения размера.

> Поддержка загрузочного диска 2TB+ реализуется и без GPT, потому что загрузчики с операционками, слава богу, пока укладываются в два терабайта :-)

Ну то есть ты хочешь костылить даже там, где удобнее было бы получить диск цельным объектом.

[netch80]

> На практике extended-разделы MBR не нужны вообще

Да-да, потребности в колбасе нет.
Ладно, ты в схеме FreeBSD вряд ли больше 20-24 разделов на диск сделаешь (если потратить все буквы adefgh), а если кто не хочет такие схемы применять? А если кому dualboot нужен?

> Проблемы выравнивания просто не существует, это вопрос качества кода и дефолтов софта для создания разделов. Проблемы "CHS-адресации" уже много лет как не существует на практике, никого не колышит "противоречие CHS" и вообще эмуляция CHS давно не нужна.

Всё это периодически где-то взрывается. GPT лишена проблем совместимости с рождения.

> такие идентификаторы не должны юзера колебать от слова никак, на то есть номера от 1 до 4 в MBR и метки в GPT.

Ну да, метки в GPT. Ты ж сам был против GPT. А без меток? Воткнул я новый диск и сижу теперь такой красивый переписываю ada1->ada2 и так далее?

Кстати, во фре уже полечили, что если диск/раздел становится виден по id/метке, то он не виден по классической схеме (в стиле /dev/ada1s2)? В линуксе все /dev/disk/by-uuid/* и т.п. это симлинки, не отменяющие некоторое базовое название.

> а если кому-то она создаёт проблемы, то наверное ему нужно подумать о смене профессии :-)

Боюсь, менять профессию надо тем, кто держит фряху на подходах 40-летней давности, отвергая всё новое...

[dadv]

> не хочет такие схемы применять?

Против "нихачю" ничего нельзя сделать, увы.

> А если кому dualboot нужен?

Четыре primary-раздела в MBR достаточны для dualboot нынче. И были достаточны во времена WinXP. У меня по старой памяти десктоп с фряхой/Win8.1, всё работает с двумя разделами в MBR и ещё два свободных, можно было бы Linux добавить при необходимости, был бы triple boot.

> Всё это периодически где-то взрывается.

Уже много-много лет ничего взорваться тут не может, LBA есть везде.

> Воткнул я новый диск и сижу теперь такой красивый переписываю ada1->ada2 и так далее?

Разумеется нет, уже много лет как (как минимум с 8.0) всё монтируется по меткам типа /dev/ufs/root в случае UFS, а ZFS вообще сама.

> Кстати, во фре уже полечили, что если диск/раздел становится виден по id/метке, то он не виден по классической схеме (в стиле /dev/ada1s2)?

Это не бага, это фича :-) :-) Если используешь метки, то старая схема низачем не нужна.

> отвергая всё новое

Не новое, а бестолковое. Новья-то полно.

[netch80]

> Это не бага, это фича :-) :-) Если используешь метки, то старая схема низачем не нужна.

Ну вот пока вы будете так относиться к багам, число желающих использовать фряху будет сокращаться.
Я с неё дома ушёл не просто так, а после того, как накопилось впечатлений и особенно когда кто-то там перестаравшись испортил всю работу с Haswell. Возвращаться не хочется.

> У меня по старой памяти десктоп с фряхой/Win8.1

Эээ... ты виртуализацией не пользуешься принципиально? Зачем тебе бутаться?

> Против "нихачю" ничего нельзя сделать, увы.

Этот аргумент может точно так же быть обращён против тебя. Все сложности с GPT это пара десятков килобайт кода на обновить backup таблицу и пересчитать контрольную сумму. Код вылизан в куче вариантов больше 10 лет. Универсализация же подхода позволяет не думать о том, что была какая-то старая схема с её тараканами и подводными багами типа в очередном BIOS проснулся старый код, который выставляет 255 секторов туда, где влазит только 63.

[dadv]

> Ладно, ты в схеме FreeBSD вряд ли больше 20-24 разделов на диск сделаешь (если потратить все буквы adefgh)

Просто на всякий случай: уже несколько мажорных релизов в bsdlabel поддерживается до 20 разделов на слайс, то есть даже не используя возможности GEOM по стекированию меток до произвольного уровня, можно получить 4*20=80 разделов, начиная с ada0s1a до ada0s4t :-)

Реально, конечно, никто так делать не будет, а возьмёт ZFS.

[netch80]

> Просто на всякий случай: уже несколько мажорных релизов в bsdlabel поддерживается до 20 разделов на слайс, то есть даже не используя возможности GEOM по стекированию меток до произвольного уровня, можно получить 4*20=80 разделов, начиная с ada0s1a до ada0s4t :-)

Это влазит в 512 байт?

А вообще, да, выглядит полезным расширением. Хоть что-то двигается, хоть и слишком своеобразно :)

> Реально, конечно, никто так делать не будет, а возьмёт ZFS.

Про это уже говорил - фиксация только на двух FS может быть слишком ограничительной.

[permeakra]

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

[dadv]

> Типовой же пользователь же с этим просто не сталкивается.

"пользователь" в данном случае хозяин блога и иже с ними.

[edo-rus.livejournal.com]

у типового пользователя стоит windows 10 на диске с gpt и всё работает )))

[dadv]

Такому пользователю dualboot не нужен, мы не про этот тип. Ему и GPT не нужна на самом-то деле. Windows вполне могла бы использовать MBR с относительно небольшим загрузочным разделом, а остальное оформлять как особого вида Dynamic Partitions (покрывающие терабайтные остатки диска) и ваш "типовой юзер" никакой разницы бы не ощутил.

[netch80]

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

Нет. Если что-то пусть даже очень давно вылизанное перестаёт активно использоваться, с ним начинают накапливаться проблемы от того, что меняются, например, используемые этим кодом интерфейсы нижнего уровня, и нету массового тестирования.
По этой причине последние 5 лет уже практически закончился отказ от 32-битных десктопных операционок (дистрибутивов). 64 бита выгоднее для ядра от ~1.5GB оперативки, а память меньше этой в современных системах уже и не встретишь.

MSDOS схему (aka MBR) ожидает похожая участь в ближайшее время. Производители железа форсируют EFI для единства платформы. Новые поколения разработчиков уже с трудом будут понимать, зачем были нужны извращения с матрёшками extended-разделов и с проходом загрузчика через игольное ушко одного 512-байтного блока кода (из которого доступно с учётом вырезаний под BPB и MBR, кажется, 406 байт), и всё, что они захотят сделать - это загрузку следующего этапа в стиле LILO (подгружается набор LBA следующей стадии, где уже нормальный объём кода и соответственно возможности для работы), а затем ещё вытащить заново все параметры платформы.

Мне это тоже не нравится, но это объективная реальность и уже заметная последние лет 10 тенденция.

[permeakra]

>MSDOS схему (aka MBR) ожидает похожая участь в ближайшее время.

Вот когда, вот тогда и. С тем, что со временем она умрет, я согласен. Но пока с MBR спокойней.

Кстати, насчет 32-битных операционок. Глобально-то все действительно как вы описали, но 32-битная система-гость смысл вполне имеет. Как и 32-битная подсистема в 64 битной операционке.

А EFI, имхо - переусложненная хрень.

[netch80]

> Вот когда, вот тогда и. С тем, что со временем она умрет, я согласен. Но пока с MBR спокойней.

Примерно поровну. Прямо на сейчас нет жёсткого преимущества в общем случае ни у MBR ни у GPT. Влиять могут внешние факторы вроде EFI или таки слишком толстого диска.

> Кстати, насчет 32-битных операционок. Глобально-то все действительно как вы описали, но 32-битная система-гость смысл вполне имеет. Как и 32-битная подсистема в 64 битной операционке.

От платформы зависит. В случае x86 не вижу реальных преимуществ ни у одного варианта. 32-битный код чуть тоньше, да. Но уже за счёт в ~2.3 раза (14 против 6) доступных РОН (исключая sp и bp), гарантированного SSE (и тоже вдвое большего количества регистров) значительно меньше дёрганий стека и код оказывается быстрее. На то же действуют соглашения о вызове с передачей параметров через регистры. Это было отмечено ещё при первых появлениях x86-64 и с тех пор не поменялось. 32-битный код нужен только там, где нет возможности перекомпилировать (и подточить старые завязки на 32-битные long и указатели).
Если бы ещё AMD не придумал префиксы на почти каждую команду, которые жрут место - ещё и было бы экономнее по объёму.
Ну, похоже, скоро ARM его вытеснит из половины серверов и десктопов (к сожалению - если платформа на ARM будет более закрытой, чем даже теперешний маразм на x86).

> А EFI, имхо - переусложненная хрень.

Само EFI - да, согласен. У Intel очень специфический подход (был?), например, вместо того кошмара, что они сделали в ACPI, нужен был какой-то лиспоподобный интерпретатор. С EFI похоже.

[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 на таком сервере просто низачем не нужен.

[edo-rus.livejournal.com]

Volumes work like partitions, allowing space on the physical drives to be split and used in different ways

вы по сути заменили общеупотребительную таблицу разделов неким подобием из bsd.
честно говоря, сходу не вижу у вашего решения никаких преимуществ перед привычным для меня созданием таблицы разделов GPT на nvme0n1 и nvme1n1, объединением nvme0n1p1 и nvme1n1p1 в зеркало, ну и использованием оставшегося по своему усмотрению (да, да, можно и zfs).

[dadv]

А разница есть. Я уже не могу поправить свой камент, Dreamwidth не даёт после того как к нему появился ответ - там есть небольшая неточность в формулировках. Вместо вот этого:

> Для системы этот раздел виден в качестве устройства /dev/raid/r0. GRAID обеспечивает тупое поблочное программное зеркалирование этого тома, автоматически зеркалируются загрузчики всех уровней, бесплатно.

Следует читать вот это:

> Для системы этот том виден в качестве устройства /dev/raid/r0 с разделом /dev/raid/r0s1. GRAID обеспечивает тупое поблочное программное зеркалирование этого тома, начиная с нулевого сектора с MBR и далее везде, автоматически зеркалируются загрузчики всех уровней, бесплатно.

Вот в этом-то и разница: при замене диска (например, из-за физического выхода из строя) либо GRAID автоматически синхронизирует всё: MBR с таблицей разделов, все уровни загрузчиков, файловую систему UFS или загрузочный пул ZFS (всё это в фоне параллельно с работой системы, так как GRAID есть часть ядра). Либо не стартует синхронизацию автоматом, а после пинка администратора, мол пора начинать, диск вставили правильный.

Не нужно на новом диске создавать GPT, создавать разделы, прописывать загрузчики - вообще ничего делать не нужно, синхронизируется не раздел, а том.

[netch80]

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

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

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

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