Как загрузить linux с uefi?

Ну, у lilo были свои проблемы. Лишние слои абстракции просто так, на пустом месте, не появляются.

У lilo только одна проблема, привязан к имени диска и если внезапно измениться порядок дисков то проблема возникнет. Ну и с efi не робит.

/proc/mdstat покажи

по умолчанию он в 1 сектор и в core пишет

В понедельник. Собственно, массивы для /boot и /boot/efi я уже разобрал.

В смысле? Что такое «первый сектор»? MBR считается нулевый сектором. И откуда grub-install в первый сектор какого устройства писать? Разве в случае uefi скрипты post-install вызывают grub-install с указанием устройства?

при UEFI режиме вряд ли там будет MBR, а для GPT нужен раздел с FAT, где это всё попроще решается.

ну а если всё-таки MBR, то груб в самый первый сектор запишет свой загрузчик (440 байт ЕМНИП), а что не входит - в следующие сектора или в особый раздел BISOBOOT

сопсна это промстандарт, Солярка также делала для VTOC/UFS

Ну понятно, в контекст вам вникать лень, играте в поискового бота, по паре слов среагировали, ответ написали. Можно было и не апать тему.

ничо не понял. в чём именно претензия? что сектор 1 указал, а не 0? так это смотря как их считать.

контекст автор сказал уточнит

да и не такая уж старая эта тема

Personalities : [raid1]
md1 : active raid1 sdb4[2] sdc4[0]
      454755328 blocks super 1.2 [2/2] [UU]
      bitmap: 0/4 pages [0KB], 65536KB chunk

md3 : active raid1 sdc5[0]
      26196992 blocks super 1.2 [2/1] [U_]

md2 : active raid1 sdb3[0] sdc3[1]
      6025216 blocks super 1.2 [2/2] [UU]

md127 : active raid1 sda1[2] sdd1[1]
      976628736 blocks super 1.2 [2/2] [UU]
      bitmap: 3/8 pages [12KB], 65536KB chunk

unused devices: <none>

Здесь md3 это новый корневой раздел, остальное – дополнительные файловые системы и swap.

Собственно, сейчас вопрос в efibootmgr, как правильно добавить что нужно и неправильно не окирпичить как ненужно. А потом вопрос grub думаю поедет нормально.

Вы написали в ветку, которая слегка отделилась от основной темы:

Дак я не про конкретный случай ТС, а в целом. А том везде «рецептов» много, что делать в случае raid, а про то, что надо воткнуть палки в колёса, чтобы обновление системы не поломало сделаное руками, почти не пишут.

И с MBR там вобще всё понятно, там может быть только один загрузчик и обновление системного загрузчика (update grub) перепишет установленный руками. И шло обсуждение uefi:

А если загрузчик «вне системы», не нужно монтирование /boot/efi. Система при всей своей вредности не сможет навредить загрузчику «вне системы».

Когда я писал «что делает по умолчанию grub-install» я подразумевал, не то, что бы вобще не в курсе, что это за команда, а то, что не возмусь спрогнозировать её поведение из post-install скрипта при обновлении системы касательно конфиликта с установленным вручную загрузчиком.

Насколько я знаю в линуксах, нет единого подхода к обновлению grub или другого загрузчика, типа файла, где хранятся опции команды grub-install, вызываемой автоматически при обновлении пакета grub.

И эта ветка закончилась:

устанавливать систему без загрузчика

И ставить его отдельно, руками, «вне системы», единственный рабочий вариант для общего случая.

Брателло, если у тя нет /usr/lib/grub/x86_64-efi/modinfo.sh, но при этом есть /usr/lib/grub/i386-pc/modinfo.sh - может ты зря думаешь про UEFI?

откуда вообще взялась ссылка на grub/x86_64-efi ?

OVZ вообще под каким дистром реально?

чо там в /etc/os-release etc.?

Текущая загрузка, насколько я могу судить, происходит через uefi. … Из этого я делаю вывод что grub не установлен.

Если ты загружаешься с загрузчика «Ю-И-Эф-Айя», то зачем тебе ещё один загрузчик «Граб»? Первый загрузчик «Ю-И-Эф-Ай» загружает ядро «Линукса» в оперативную память и запускает его. Путь к корневой файловой системе может быть указан в ядре «Линукса» при его сборке. Второй загрузчик «Граб» можно не устанавливать.

OVZ вообще под каким дистром реально?

Скорее всего под Шапкой (ну я про всю кучу) это сейчас выбор есть раньше для нормальных серверов альтернатив не было.

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

чо там в /etc/os-release etc.?

NAME="Virtuozzo"
VERSION="7.0.8"
ID="virtuozzo"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="OpenVZ release 7.0.8"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:virtuozzoproject:vz:7"
HOME_URL="http://www.virtuozzo.com"
BUG_REPORT_URL="https://bugs.openvz.org/"

откуда вообще взялась ссылка на grub/x86_64-efi ?

Надо полагать, Virtuozzo при установке сделало. Система установлена когда-то давно с оригинального образа без каких либо дополнительных действий. И при установке оно неизбежно сделало для себя загрузчик. Кроме того, при загрузке можно видеть меню grub.

может ты зря думаешь про UEFI?

Почему оно – написано в исходном посте. Команда efibootmgr выдавала

Boot0000* OpenVZ        HD(2,GPT,2b4cc65d-3efd-4f00-8053-6c07f3830802,0x200800,0x64000)/File(\EFI\virtuozzo\shimx64.efi)
Boot0002* Hard Drive    BBS(HD,,0x0)AMGOAMNO....<много букв>....AMBO

В chroot я выполнил grub2-mkconfig и efibootmgr -c -L "OpenVZ_RAID" -l '\EFI\virtuozzo\shimx64.efi', после этого в efibootmgr появилась вторая строка:

Boot0000* OpenVZ        HD(2,GPT,2b4cc65d-3efd-4f00-8053-6c07f3830802,0x200800,0x64000)/File(\EFI\virtuozzo\shimx64.efi)
Boot0001* OpenVZ_RAID   HD(1,GPT,99232e27-7e50-4b3e-8f4c-3d45b29746cc,0x800,0x74706000)/File(\EFI\virtuozzo\shimx64.efi)

Вот разница между grub.cfg:

# diff /boot/efi/EFI/virtuozzo/grub.cfg /mnt/raid/boot/efi/EFI/virtuozzo/grub.cfg
88c88
< menuentry 'Virtuozzo 7.0.8 (3.10.0-862.11.6.vz7.64.7)' --class openvz --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-862.11.6.vz7.64.7-advanced-2f982a73-3ab2-44b3-81a7-89443e6702df' {
---
> menuentry 'Virtuozzo 7.0.8 (3.10.0-862.11.6.vz7.64.7)' --class openvz --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-862.11.6.vz7.64.7-advanced-85fa1a5f-d8de-4941-93f9-103cae0369ee' {
94c94
<       set root='hd1,gpt1'
---
>       set root='hd2,gpt1'
96c96
<         search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt1 --hint-efi=hd1,gpt1 --hint-baremetal=ahci1,gpt1  6a23dfc7-3791-4c27-9c61-a720c2c1c9df
---
>         search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt1 --hint-efi=hd2,gpt1 --hint-baremetal=ahci2,gpt1  ba027ae5-18fc-4b9e-b6cc-d9a0b770aef5
98c98
<         search --no-floppy --fs-uuid --set=root 6a23dfc7-3791-4c27-9c61-a720c2c1c9df
---
>         search --no-floppy --fs-uuid --set=root ba027ae5-18fc-4b9e-b6cc-d9a0b770aef5
100c100
<       linuxefi /vmlinuz-3.10.0-862.11.6.vz7.64.7 root=UUID=2f982a73-3ab2-44b3-81a7-89443e6702df ro crashkernel=auto quiet
---
>       linuxefi /vmlinuz-3.10.0-862.11.6.vz7.64.7 root=UUID=85fa1a5f-d8de-4941-93f9-103cae0369ee ro crashkernel=auto noquiet
103c103
< menuentry 'Virtuozzo 7.0.8 (0-rescue-94db05b042d047609677703b94a3950e)' --class openvz --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-0-rescue-94db05b042d047609677703b94a3950e-advanced-2f982a73-3ab2-44b3-81a7-89443e6702df' {
---
> menuentry 'Virtuozzo 7.0.8 (0-rescue-94db05b042d047609677703b94a3950e)' --class openvz --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-0-rescue-94db05b042d047609677703b94a3950e-advanced-85fa1a5f-d8de-4941-93f9-103cae0369ee' {
108c108
<       set root='hd1,gpt1'
---
>       set root='hd2,gpt1'
110c110
<         search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt1 --hint-efi=hd1,gpt1 --hint-baremetal=ahci1,gpt1  6a23dfc7-3791-4c27-9c61-a720c2c1c9df
---
>         search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt1 --hint-efi=hd2,gpt1 --hint-baremetal=ahci2,gpt1  ba027ae5-18fc-4b9e-b6cc-d9a0b770aef5
112c112
<         search --no-floppy --fs-uuid --set=root 6a23dfc7-3791-4c27-9c61-a720c2c1c9df
---
>         search --no-floppy --fs-uuid --set=root ba027ae5-18fc-4b9e-b6cc-d9a0b770aef5
114c114
<       linuxefi /vmlinuz-0-rescue-94db05b042d047609677703b94a3950e root=UUID=2f982a73-3ab2-44b3-81a7-89443e6702df ro crashkernel=auto quiet
---
>       linuxefi /vmlinuz-0-rescue-94db05b042d047609677703b94a3950e root=UUID=85fa1a5f-d8de-4941-93f9-103cae0369ee ro crashkernel=auto noquiet

Старый корень:

/dev/sdb5: UUID="2f982a73-3ab2-44b3-81a7-89443e6702df" TYPE="ext4" PARTUUID="4d0390ce-4639-4b8e-8032-34aa864eedb5"

Новый:

/dev/md3: UUID="85fa1a5f-d8de-4941-93f9-103cae0369ee" TYPE="ext4"

Старый boot:

/dev/sdb1: UUID="6a23dfc7-3791-4c27-9c61-a720c2c1c9df" TYPE="ext4" PARTUUID="7ca31de2-9341-4223-a64e-0bb743c334a6"

Новый boot:

/dev/sdc1: UUID="ba027ae5-18fc-4b9e-b6cc-d9a0b770aef5" TYPE="ext4" PARTUUID="114a1182-9c06-4c5c-88e6-3f17e3b441ca"

При этом, в меню по F12 появился новый пункт, но при загрузке через него загружается старый корень:

/dev/sdb5        25G  2.8G   21G  12% /

зачем тебе ещё один загрузчик «Граб»?

Так Virtuozzo сделали. Что мне нужно сказать efibootmgr чтобы грузиться без него?

сказал что у него не так

О каком посте речь?

Как загрузить linux с uefi? (комментарий)

И да я там ниже поправился, в грубе 1 это первый хдд.

Так Virtuozzo сделали. Что мне нужно сказать efibootmgr чтобы грузиться без него?

Я делал загрузку «Линукса» загрузчиком «Ю-И-Эф-Айем» по руководству по установке «Генты». Всё работало без загрузчика «Граба» напрямую из «Ю-И-Эф-Айя».

Что именно прописать я не смогу сказать, потому что сам давно уже этим занимался. Но я делал по указанному выше руководству. Странно, почему гуру-админы помалкивают тут. Наверное, они просто клацают «мышкой» при установке «Убунты», не думая, вот и помалкивают из-за отсутствия навыков ручной загрузки из «Ю-И-Эф-Айя».

по руководству по установке «Генты».

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

админы помалкивают

Мне трудно представить для чего администратору может быть нужно разбираться с загрузчиками. Например, в моём случае, когда я последний раз разбирался с загрузчиком это был lilo. С grub я имел дело пару раз и крайне поверхностно. С UEFI имею дел в первый раз. И данный пример это довольно экзотическая ситуация. Другими случаями, наверно, могут быть восстановления резервных копий, если они делались не образом диска а архивом файлов. Вот для энтузиастов это действительно может быть и интересно и актуально.

Ссылка неверная, должна вести сюда.

Ссылка неверная, должна вести сюда.

Да, спасибо. Раздел «Alternative 2: EFI Stub».

Я посмотрел старницу, но не нашёл там слова efibootmgr.

Это я не досмотрел, привел неправильную ссылку и ввел людей в заблуждение. Извините, ребята. Форумчанин Ярс-068 привел правильную ссылку на руководство по установке «Генты», где пошагово расписано как подготовить ядро «Линукса» и что прописывать в загрузчике «Ю-И-Эф-Айе». Если ты сделаешь все по руководству, то «Линукс» будет загружаться без второго загрузчика «Граба».

есть ещё systemd-boot проще груба.

но при загрузке через него загружается старый корень

ну да, а /etc/fstab верно старый остался ? и там поди по UUID загрузка?
вот именно поэтому я в таких скользких случаях LABEL использую. раньше прямо /dev/xxx прописывал, но сейчас могут уехать буквы, LABEL надёжнее и поменять проще чем UUID.
и если всё нормально, прописываешь новый UUID и вася кот.

Не, на массиве fstab свой, пока предполагаю initrd, завтра опять буду смотреть.

Там не установлен а доустановка представляется мало возможной.

точно! как я это просмотрел!

у него же EFI раздел не с тем типом! должно быть EFI SYSTEM …93B - а у него linux raid … 11E

дело раскрыто!

но на самом деле грабля может быть не одна )))))

с 11E (linux raid) EFI может не стартовать нормально и падает обратно на предыдущую известную хорошую запись

ну и сравнил бы fstab

Хорошо, напишу ещё раз :) Два массива (/boot, /boot/efi) разобрал, оставил только корень.

причём тут массивы если EFI boot идёт только с раздела соответствующего типа?

Кхм.., Ну наверно разобрав массивы я всё вернул на место, и типы разделов также?

Как загрузить linux с uefi?

Прочитал «Как загрустить...»

в теме про это ни слова

Он не умеет загружать ядра, до которых тянуться надо за 1024-й цилиндр… Но при этом он умеет сказать ядру root=UUID=... и не зависит от файловой системы.

Мда … если почитать его ответы видно что у него grub.efi загружается …

1024-й цилиндр

Разве году в 2001-2003 это ограничение не убрали?

и не зависит от файловой системы

Когда-то у народа подгорало, что слака предлагает сделать корень в btrfs, а потом не может туда установить lilo, типа если хотите lilo, надо делать отдельный /boot. Вроде, потом как-то заработало, но, получается, какая-то зависимость от ФС была.

И, в целом, непонятно, если у ФС дудупликация блоков, точно ли это не помешает lilo, он же к номерам секторов/блоков привязывается?

Разве году в 2001-2003 это ограничение не убрали?

Вроде бы нет, но могу ошибаться.

Те подгорания с btrfs как-то мимо меня прошли, тут ничего не могу сказать.

если у ФС дудупликация блоков, точно ли это не помешает lilo, он же к номерам секторов/блоков привязывается?

По идее, не должно. Ведь /sbin/lilo получает фактическое месторасположение файла на диске и пишет его в код, который ставится в MBR.

Не знаю как ФС, но с lilo было так, что ставишь загрузчик, потом удаляешь разделы (вот не буду врать про форматирование, хотя там уже могло быть по разному) и потом загружаешься а линукс стартует… Ну, правда корневую ФС смонтировать не может с понятным результатом…

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

lilo не мог работать с gpt и UEFI и всегда пихался в mbr.

Да, конечно, он на GPT ставится в PMBR. А вот с UEFI – да, не мог, так как это BIOS-загрузчик. Но для UEFI позднее сделали ELILO.

Да, конечно, он на GPT ставится в PMBR.

Хм. Хз про такой, в gpt разметке есть партиция с номером (блин опять забыл) типа bios_dos это оно?

Нет, у GPT есть PMBR, Protective MBR – структура в нулевом секторе, аналогичная обычному MBR, в которой в таблице разделов числится один большой раздел на весь диск. Причём, это не мешает использовать этот PMBR для целей загрузки, именно благодаря этому возможна загрузка с GPT-диска в системе с BIOS.

именно благодаря этому возможна загрузка с GPT-диска в системе с BIOS.

Странно, вроде как раз для этого нужна партиция bios_dos. Ну хз, спорить не буду …

Это ты про BIOS boot раздел говоришь, на BIOS/GPT конфигурациях в этот раздел встраивается GRUB. Для LILO этот раздел не нужен, его загрузочный код в 446 байт влезает легко, в отличие от core.img GRUB’a.

На да, про bios_grub.

Для LILO этот раздел не нужен, его загрузочный код в 446 байт влезает легко, в отличие от core.img GRUB’a.

ааа, ну ок, я просто подумал что мы уже слезли с темы lilo.

(только сейчас в треде узнал про какой то ELILO ;) )

По идее, не должно.

Да, не должно, если lilo был запущен на уже дедуплицированной ФС. Но, если дедупликация запущена после, то загрузка может сломаться. Или вобще сделают постоянную фоновую дедупликацию. Lilo ведь (если ещё живой) единственная программа работающая в обход драйвера ФС.

Именно так, удаление раздела, или даже форматирование, обычное (быстрое), которое просто очищают структуры ФС, но блоки с данными не обнуляют, не страшно для lilo. А вот какая-нибудь дефрагментация или дедупликация ФС может его сломать. Если файл с данными lilo или с тем, что ему нужно загрузить, переместится на уровне секторов на НЖМД, то загрузка сломана, нужно запустить команду lilo, чтобы заново были определены номера блоков (секторов) с загружаемыми файлами.

На всякий случай допишу про дефрагментацию, что lilo могли ставить на FAT, и дефрагментировать под виндой...

Кстати да, интересно, это очень узкое место. Надо полагать это не особо проявлялось потому, что дефрагментация под линукс… как бы это так выразиться, не особо распространена. Ну и практика вынесения /boot на отдельный раздел делала вопрос дефрагментации данной ФС лишённым смысла. Но, да, вопрос 1024 цилиндра не единственный. А возможно и ещё есть, да, grub конечно не на пустом месте появился.

Опять я потерялся, где твой обещанный ls с gruba?