Partitionless Btrfs внезапно загружается для восстановления GRUB

Partitionless Btrfs внезапно загружается для восстановления GRUB

Проблема

У меня есть машина, которая загружается в Arch Linux с восьмидискового тома Btrfs RAID10. Недавно я перезагрузился и попал на это приглашение GRUB для восстановления:

Добро пожаловать в GRUB! ошибка: такого устройства нет: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX. ошибка: неизвестная файловая система. Вход в режим восстановления... grub rescue> ls (hd0) (hd1) (hd2) (hd3) (hd4) (hd5) grub rescue> ls (hd5) (hd5): Файловая система неизвестна. grub rescue> ls (hd4) (hd4): Файловая система неизвестна. grub rescue> insmod btrfs grub rescue> ls (hd0) (hd0): Файловая система неизвестна. grub rescue>

Я не уверен, что именно вызвало это. После последней загрузки я установил обновления ( pacman -Syu) по крайней мере дважды и, возможно, внес другие изменения в систему, включая переустановку GRUB.Я смогу запустить систему, если добавлю специальный загрузочный диск.

Теория

Во время устранения неполадок с отзывчивым участником IRC-канала #archlinux я столкнулся сэта заметка на Arch wiki:

Смещение раздела

Проблема смещения может возникнуть при попытке встроить core.img в разделенный диск. Это означает, что можно встроить core.img grub в пул Btrfs на диске без разделов (например, /dev/sdX) напрямую. GRUB может загружать разделы Btrfs, однако модуль может быть больше, чем другие файловые системы. А файл core.img, созданный grub-install, может не поместиться в первые 63 сектора (31,5 КБ) диска между MBR и первым разделом. Современные инструменты разбиения на разделы, такие как fdisk и gdisk, избегают этой проблемы, смещая первый раздел примерно на 1 МБ или 2 МБ.

Похоже, это говорит о том, что могут возникнуть проблемы с установкой GRUB на разделенные диски.идиски без разделов, которые новые инструменты разбиения на разделы смягчают (на данный момент), оставляя дополнительное место в начале диска.

Страница GRUB wiki более прямая:

Установить на диск с разделами или без разделов

Предупреждение:GRUBнастоятельно не рекомендуетУстановка в загрузочный сектор раздела или диск без разделов, как это делают GRUB Legacy или Syslinux. Такая установка подвержена поломкам, особенно во время обновлений, ине поддерживаетсяразработчиками Arch.

Ну, ерунда.

Для пущей важности grub-install -vвключите эту строку в свой вывод:

grub-install: info: the total module size is 0xa07c.

Это примерно 41 КБ, что значительно превышает указанный выше предел в 31,5 КБ, но я недостаточно хорошо знаю GRUB, чтобы быть уверенным, что это является причиной моих бед.

Вопросы

  1. Если этоявляетсяпроблема, как я могу это доказать — и почему не происходит grub-installгромкого провала, если это так?

  2. Как правильно форматировать загрузочные диски Btrfs в будущем? MBR? GPT? — отдельный загрузочный диск — это заманчиво, но мне нравится иметь резервный загрузчик на каждом устройстве в томе.

  3. Есть ли более удобный способ перенести каждый диск в таблицу разделов, чем стирание и запуск btrfs replaceдля каждого диска?

решение1

Раньше создание таблицы разделов MBR с помощью, скажем, fdisk, по умолчанию оставляло первые 63 сектора нетронутыми. Именно там можно было установить GRUB и другие загрузчики.

Перенесемся в наши дни, и тот же инструмент (fdisk) оставляет больше неиспользованного пространства; достаточно для GRUB2, чтобы установить его stage1 с поддержкой BTRFS. Я думаю, что смещение составляет около 1 МБ по умолчанию; сколько бы это ни стоило в секторах.

Я не знаю, почему grub-installне происходит сбой, но предполагаю, что он не проверяет размер загрузочного сектора; а без разделов как бы это могло произойти?

Я не вижу проблемы в наличии избыточных загрузчиков. Вам придется управлять этим вручную, но stage1 GRUB2 не меняется часто. Но это означает, что вам понадобятся разделы.

Я не знаю инструмента, который может перенести диск, чтобы добавить таблицу разделов. Проблема в том, что файловая система привязана к секторам на диске, и добавление таблицы разделов изменяет эти сектора. Если бы ваши файловые системы BTRFS были на LVM, то да, вы могли бы перемещать вещи, потому что файловая система была бы привязана к "виртуальным секторам". Я не говорю, что вы должны это делать, просто иллюстрирую, в чем проблема.

Связанный контент