Комментарии 99
Это руководство в стиле «как нарисовать сову»
Напишите с какого места непонятно. Можно в личку. Я допишу если нужно.
Мне тоже непонятно.
1. Прошивка UEFI (чип) ищет GPT-диск и запускает файл (загрузчик) по фиксированному пути
2. Загрузчик читает /loader/loader.conf со списком пунктов меню — в примере по умолчанию выбирается archlinux
3. Загрузчик для выбранного пункта меню читает конфиг пункта меню — в файле /entries/arch.conf, раздел 'Arch Linux'.
Каким образом archlinux сочетается с /entries/arch.conf и текстом Arch Linux? Как загрузчик нашел файл из которого читать конфиг пункта меню?
4. Загрузчик запускает Linux с нужными опциями
В опциях указана обычная опция initrd /efi/archlinux/initramfs-linux.img, а также дополнительный параметр ядра initrd=\EFI\archlinux\intel-ucode.img.
Что такое \EFI\archlinux\intel-ucode.img, откуда он взялся и нужен ли он для загрузки?
1. Прошивка UEFI (чип) ищет GPT-диск и запускает файл (загрузчик) по фиксированному пути
2. Загрузчик читает /loader/loader.conf со списком пунктов меню — в примере по умолчанию выбирается archlinux
3. Загрузчик для выбранного пункта меню читает конфиг пункта меню — в файле /entries/arch.conf, раздел 'Arch Linux'.
Каким образом archlinux сочетается с /entries/arch.conf и текстом Arch Linux? Как загрузчик нашел файл из которого читать конфиг пункта меню?
4. Загрузчик запускает Linux с нужными опциями
В опциях указана обычная опция initrd /efi/archlinux/initramfs-linux.img, а также дополнительный параметр ядра initrd=\EFI\archlinux\intel-ucode.img.
Что такое \EFI\archlinux\intel-ucode.img, откуда он взялся и нужен ли он для загрузки?
Я изменил default arch на default archlinux в тексте, чтобы убрать возможность прочитать слово в значении «архитектура». Имя файла подправить забыл.
Специально указываю, что все настройки — мои собственные, все равно настраивать надо по аналогии, копировать тут смысла нет. intel-ucode это микрокод процессора, для работы не обязателен.
Специально указываю, что все настройки — мои собственные, все равно настраивать надо по аналогии, копировать тут смысла нет. intel-ucode это микрокод процессора, для работы не обязателен.
Чтоб настраивать по аналогии, надо чтоб хоть что-то работало :)
Итого, ещё раз повторим инструкцию по рисованию совы:
1. Удалить все имеющиеся загрузочные записи в чипе UEFI
2. После этого чип UEFI запускает загрузчик по фиксированному пути /EFI/Boot/BOOTX64.EFI
3. Загрузчик из systemd-boot читает свой конфиг из /loader/loader.conf
4. Загрузчик из systemd-boot читает свой конфиг из /entries/XXX.conf
5. Загружаемся
Все правильно?
Итого, ещё раз повторим инструкцию по рисованию совы:
1. Удалить все имеющиеся загрузочные записи в чипе UEFI
2. После этого чип UEFI запускает загрузчик по фиксированному пути /EFI/Boot/BOOTX64.EFI
3. Загрузчик из systemd-boot читает свой конфиг из /loader/loader.conf
4. Загрузчик из systemd-boot читает свой конфиг из /entries/XXX.conf
5. Загружаемся
Все правильно?
1. Незачем что-то удалять. Незачем вообще лишний раз трогать. Просто выставить загрузку с диска.
2. Да. И он уже должен работать, даже если не настроен — запускаться, получать управление, отображать меню. Вопрос дальнейшей настройки — чисто механический: открыть в инете документацию, и согласно ей настроить. И необязательно это должен быть systemd-boot, можно и grub зафигачить, и rEFInd, настройки у всех разные — но сам загрузчик должен заработать сразу, как только его положили по нужному пути.
3,4. /loader/entries/xxx.conf (папка entries должна лежать рядом с loader.conf)
2. Да. И он уже должен работать, даже если не настроен — запускаться, получать управление, отображать меню. Вопрос дальнейшей настройки — чисто механический: открыть в инете документацию, и согласно ей настроить. И необязательно это должен быть systemd-boot, можно и grub зафигачить, и rEFInd, настройки у всех разные — но сам загрузчик должен заработать сразу, как только его положили по нужному пути.
3,4. /loader/entries/xxx.conf (папка entries должна лежать рядом с loader.conf)
Кирпичится не винт, а материнка, точнее микросхема UEFI. После этого решается только одним способом — выпаиванием чипа, перепрошивкой на программаторе и припаиванием обратно. Опасность возникает при добавлении пунктов в меню загрузки, потому что они хранятся в NVRAM чипа. Если очень не повезло, то окирпичить комп может операционка, причем в худших случаях — просто при старте с live-cd (без какой-либо записи на диск). Так было с Ubuntu и ноутами Samsung. Если ничего не путаю, производитель менял пострадавшим мать по гарантии, но не факт что всем.
Манипуляции над загрузчиком, если иметь в виду манипуляции с файлами на EFI-разделе, абсолютно безопасны. Опасность возникает, когда ты вдруг понимаешь, что только что написал команду efibootmgr и собираешься её запустить. К слову, если ты набрал её на маке — то с высокой степенью вероятности получишь кирпич )) потому что формат прошивки UEFI у них свой, линуксовая прога там всё порушит. Моя статья как раз о том, что НЕ НАДО использовать команды, изменяющие NVRAM.
> Я правильно понимаю, что можно клонировать загрузчик на флешку, удалить оригинал с винчестера, и в итоге у меня получается что-то вроде HASP-а для запуска системы?
Да. Перед тем, как писать статью, я вдоволь поигрался с флешкой. Удалять вот файлы на системном диске не пробовал, но должно сработать.
> Очень интересно будет почитать исполнение на тему: как поставить любой linux параллельно с windows 8+ при наличии лицензии на оную и UEFI-загрузчика, без виртуалок, ничего не сломав.
Я могу тебе тут в паре предложений рассказать. Ставишь обе системы в произвольном порядке, в линуксе если инсталлер предложит поставить загрузчик — отказываешься. Винда создаст EFI-раздел (при разбитии диска она его сама создаёт), на него пихает свой загрузчик в папку /EFI/Microsoft/ и прописывает в NVRAM микросхемы UEFI загрузочную запись «Windows Boot Manager» с путём к загрузчику. Заходишь в биос, в списке порядка загрузки помимо дисковых устройств появится эта запись. Ты меняешь загрузку обратно на диск. В этом случае при старте UEFI будет искать загрузчик в «пути по умолчанию», то есть попытается запустить файл /EFI/Boot/bootx64.efi
Скорее всего это сработает, потому что винда туда копию своего загрузчика наверняка делает. Ну если юзер выставит загрузку с диска вместо Windows Boot Manager, чтоб у него винда грузилась. Так вот, дальше по моей статье — находишь бинарник с загрузчиком, заменяешь им виндовый в «пути по умолчанию» (в папке Microsoft не трогаешь), кидаешь куда надо текстовый конфиг, прописываешь пути для запуска линукса и винды, и после ребута новый загрузчик покажет уже свое загрузочное меню, которые ты сам настроил.
При этом «ничего не сломав» гарантируется тем фактом, что в любой момент ты можешь в биосе выставить загрузку в Windows Boot Manager, который находится /EFI/Microsoft и который ты не трогаешь совсем. То есть, винда гарантированно не пострадает.
Манипуляции над загрузчиком, если иметь в виду манипуляции с файлами на EFI-разделе, абсолютно безопасны. Опасность возникает, когда ты вдруг понимаешь, что только что написал команду efibootmgr и собираешься её запустить. К слову, если ты набрал её на маке — то с высокой степенью вероятности получишь кирпич )) потому что формат прошивки UEFI у них свой, линуксовая прога там всё порушит. Моя статья как раз о том, что НЕ НАДО использовать команды, изменяющие NVRAM.
> Я правильно понимаю, что можно клонировать загрузчик на флешку, удалить оригинал с винчестера, и в итоге у меня получается что-то вроде HASP-а для запуска системы?
Да. Перед тем, как писать статью, я вдоволь поигрался с флешкой. Удалять вот файлы на системном диске не пробовал, но должно сработать.
> Очень интересно будет почитать исполнение на тему: как поставить любой linux параллельно с windows 8+ при наличии лицензии на оную и UEFI-загрузчика, без виртуалок, ничего не сломав.
Я могу тебе тут в паре предложений рассказать. Ставишь обе системы в произвольном порядке, в линуксе если инсталлер предложит поставить загрузчик — отказываешься. Винда создаст EFI-раздел (при разбитии диска она его сама создаёт), на него пихает свой загрузчик в папку /EFI/Microsoft/ и прописывает в NVRAM микросхемы UEFI загрузочную запись «Windows Boot Manager» с путём к загрузчику. Заходишь в биос, в списке порядка загрузки помимо дисковых устройств появится эта запись. Ты меняешь загрузку обратно на диск. В этом случае при старте UEFI будет искать загрузчик в «пути по умолчанию», то есть попытается запустить файл /EFI/Boot/bootx64.efi
Скорее всего это сработает, потому что винда туда копию своего загрузчика наверняка делает. Ну если юзер выставит загрузку с диска вместо Windows Boot Manager, чтоб у него винда грузилась. Так вот, дальше по моей статье — находишь бинарник с загрузчиком, заменяешь им виндовый в «пути по умолчанию» (в папке Microsoft не трогаешь), кидаешь куда надо текстовый конфиг, прописываешь пути для запуска линукса и винды, и после ребута новый загрузчик покажет уже свое загрузочное меню, которые ты сам настроил.
При этом «ничего не сломав» гарантируется тем фактом, что в любой момент ты можешь в биосе выставить загрузку в Windows Boot Manager, который находится /EFI/Microsoft и который ты не трогаешь совсем. То есть, винда гарантированно не пострадает.
Я правильно понял, когда винда ставится, она патчит микросхему UEFI своей записью на Windows Boot Manager и этого никак не избежать без бубна?
И ещё — выше были комментарии по поводу livecd и других операций, которые лезут в NVRAM и могут кирпичнуть мать. Можно поподробнее как/когда и при каких условиях? То есть, я при каких то действиях, могу даже не подозревать, что софт в процессе своей обычной работы лезет в NVRAM UEFI и что то там меняет? Как так жить то?
И ещё — выше были комментарии по поводу livecd и других операций, которые лезут в NVRAM и могут кирпичнуть мать. Можно поподробнее как/когда и при каких условиях? То есть, я при каких то действиях, могу даже не подозревать, что софт в процессе своей обычной работы лезет в NVRAM UEFI и что то там меняет? Как так жить то?
Установщик «винды», как и установщики других ОС (естественно, поддерживающие UEFI) «патчат микросхему UEFI» так же, как и Вы, когда, например, корректируете очередность поиска загрузчика в «setup-е» BIOS-а (читай, UEFI). Спешу Вас успокоить — ни установщик, ни сама ОС (без «вредоносов», естественно) ничего плохого Вашей материнке не сделает. К тому же, если у Вас не китайский компьютер, то производитель материнки наверняка (но не гарантированно) предусмотрел «защиту» от «невалидных» переменных и наверняка реализует возможность «сброса к заводским настройкам». У меня есть китайский компьютер с «китайской» прошивкой UEFI))) Так там буквально все разрешено бесконтрольно менять — после некоторых экспериментов у меня перестала работать встроенная видеокарта (на экране ничего небыло, а вот диск «жужжал» и клавиатура включалась). Так вот мне и в этом случае удалось «вслепую» сбросить настройки до заводских и восстановить работоспособность компьютера).
Так что, если Вы не ставите целью «окирпичивание» материнки, то это наверняка Вам не грозит. Ведь не даром говорят: «Тонут в основном те, кто умеет плавать».
Так что, если Вы не ставите целью «окирпичивание» материнки, то это наверняка Вам не грозит. Ведь не даром говорят: «Тонут в основном те, кто умеет плавать».
То есть, я при каких то действиях, могу даже не подозревать, что софт в процессе своей обычной работы лезет в NVRAM UEFI и что то там меняет? Как так жить то?
Окирпичивание без действий со стороны может произойти в исключительных случаях, когда в конретной модели конкретного производителя есть ошибка.
«Берёте USB-флешку, форматируете в таблицу разделов GPT» — Как это сделать?
> Не надо использовать GRUB
Может, конечно, и так, но вдруг вам захотелось сделать нормальное полнодисковое шифрование?
Может, конечно, и так, но вдруг вам захотелось сделать нормальное полнодисковое шифрование?
Нет, когда нужны возможности конкретного загрузчика — то его конечно и надо использовать. Просто у меня уже крик души, я постоянно наблюдаю что люди ставят себе Grub, нередко с большим трудом, когда можно обойтись куда меньшей кровью.
А в чем проблема с grub под UEFI? ровно так же создается папка на ESP (EFI System Partition), там лежат бинарики *.efi и конфиги. С этим загрузчиком живу с тех пор, как пересел с lilo? проблем не было ни каких…
И да, любые манипуляции с загрузкой, не важно откуда, из Setup материнки, из любой программы работающей с efivars меняют эти самые vars
И да, любые манипуляции с загрузкой, не важно откуда, из Setup материнки, из любой программы работающей с efivars меняют эти самые vars
Обычно /boot — не шифруют. А LUKS — работает точно также (ручками передаем параметры ядру).
Я потому и говорю «нормальное полнодисковое», включая /boot.
Возможно это описание прольёт свет: https://wiki.archlinux.org/index.php/systemd-boot#Encrypted_Root_Installations
Спасибо за статью. Сняло многие вопросы.
>>Не надо использовать GRUB
Да, только при мультибуте юниксов с виндой возникает знатный пердолинг с этими вашими GPT и UEFI. А вот старый добрый MBR и GRUB честно тянет тележку без танцев с бубнами. Может для каких-то мега объемных дата-систем и актуально это дело, но для большинства домашних систем нужно как козе баян.
Да, только при мультибуте юниксов с виндой возникает знатный пердолинг с этими вашими GPT и UEFI. А вот старый добрый MBR и GRUB честно тянет тележку без танцев с бубнами. Может для каких-то мега объемных дата-систем и актуально это дело, но для большинства домашних систем нужно как козе баян.
Вот я и статью задумал, чтобы рассказать что есть прямая и короткая дорога без пердолинга.
Реализация подкачала )
Реализация подкачала )
>>какого хрена эта флешка не определяется как загрузочная, я же сделал все по инструкции
Используете самурайский метод — dd в консоли как диды завещали?:) Не знаю таких проблем. Делаю загрузочные флешки с Unetbootin в линуксе или в UltraISO под окнами. Ни разу факапов не было. Все грузится спокойно, что установочная винды, что лайв флешка с Убунтой.
>> если не дай бог выбрал не то место для установки линуксового загрузчика — не увидишь либо линукс, либо винду
Откуда вы такие проблемы себе роете? Подозреваю, что стараетесь реализовывать нетривиальные решения, ну тогда могу посоветовать перестать выбирать шашечки, а заняться реальной работой. Проверенно — когда не хватает времени на работу, про выбор шашечек забываешь. Как в общем и про системы где постоянно требуется знание тантрического секса на бубне типа Генту или Арч.
Используете самурайский метод — dd в консоли как диды завещали?:) Не знаю таких проблем. Делаю загрузочные флешки с Unetbootin в линуксе или в UltraISO под окнами. Ни разу факапов не было. Все грузится спокойно, что установочная винды, что лайв флешка с Убунтой.
>> если не дай бог выбрал не то место для установки линуксового загрузчика — не увидишь либо линукс, либо винду
Откуда вы такие проблемы себе роете? Подозреваю, что стараетесь реализовывать нетривиальные решения, ну тогда могу посоветовать перестать выбирать шашечки, а заняться реальной работой. Проверенно — когда не хватает времени на работу, про выбор шашечек забываешь. Как в общем и про системы где постоянно требуется знание тантрического секса на бубне типа Генту или Арч.
Да не, не очень
Ну с Arch линукс может все и безоблачно, но у меня с Убунтой, Win7 и GPT вышли какие то проблемы, сейчас уж и не вспомню, что там было. Вроде Убунта говорила, что жесткий диск не видит, на который предварительно была установлена винда с GPT. Переустановил винду с MBR и сразу все завелось без всякого выпендрежа. С разделами тоже проблем у меня нет. У меня три жестких диска: 1TB, 500ГБ, 320ГБ. Линукс установлен на диск 1TB, диск разбит на несколько разделов в разных форматах естественно. Не пойму зачем мне этот ваш GPT и UEFI, если у меня и так все работает?
Это проблемы исключительных дистров. Убунту — совсем уже исключительный.
Так-то можно и на ms-dos до сих пор сидеть — а чё, там тоже всё работает.
Не пойму зачем мне этот ваш GPT и UEFI, если у меня и так все работает?
Так-то можно и на ms-dos до сих пор сидеть — а чё, там тоже всё работает.
Деаа?? И чем отличается работа в системе загруженной через GRUB + MBR от системы загруженной Gpt + НЕХ. Чем? Расскажите — посмешите.
Ну, например, фреймбуфер на всех этапах загрузки, а не жалкий VGA.
Ну, например, упирание в два терабайта для MBR.
Ну, например, нормальные драйверы на этапе инициализации, а не 16-битные огрызки.
Ну, например, secure boot.
Ну, например, отсутствие проблем «да где этот чертов загрузочный сектор».
Ну, например, создание несколько больше, чем 4 (7) разделов.
Ну как, ржёте там небось, да?
Ну, например, упирание в два терабайта для MBR.
Ну, например, нормальные драйверы на этапе инициализации, а не 16-битные огрызки.
Ну, например, secure boot.
Ну, например, отсутствие проблем «да где этот чертов загрузочный сектор».
Ну, например, создание несколько больше, чем 4 (7) разделов.
Ну как, ржёте там небось, да?
Я просил указать чем отличается работа в загруженной системе, а не ваши прохладные истории пердолинга с шашечками на стадии загрузки. Или пердолинг с шашечками на стадии загрузки это ваша основная деятельность? Тада пардоньте. Единственный явный плюс который для реальных дел это поддержка жестких дисков 2тб + ну и хочу сказать, что я имею ввиду домашние машины, а не серверные монстры.
Я тоже много чего просил. Только вот какое отношение загрузка имеет к процессу работы? Перефразирую более понятно для пердолящих всё и вся: как процесс доставка товара может изменить свойства самого товара? Совершенно неважно, привезёте ли вы мебель на самолёте из другой страны или его джамшуты за бутылку принесут из соседнего магазина — мебель то одна.
Ну да. Перефразирую старый анекдот про бананы и пальмы на новый лад.
Загружается юзер на своем писюке, а за спиной кулхацкер ходит и под нос бубнит: «ну как так можно… Загружаешься… Загружаешься через граб и на жестком диске мбр, а не гпт… Посмотри на меня! Я закончил MIT, прочел статью на хабре, просидел ночь, укокошил один жесткий диск ковыряясь в его прошивке, но зато я теперь гружусь в гпт! Вот тебе ссылочка на статью на хабре приступай к экспериментам! „
Юзер: “И что же я получу в итоге?»
Кулхацкер удивленно: «Как что? Ты будешь грузить систему! „
Загружается юзер на своем писюке, а за спиной кулхацкер ходит и под нос бубнит: «ну как так можно… Загружаешься… Загружаешься через граб и на жестком диске мбр, а не гпт… Посмотри на меня! Я закончил MIT, прочел статью на хабре, просидел ночь, укокошил один жесткий диск ковыряясь в его прошивке, но зато я теперь гружусь в гпт! Вот тебе ссылочка на статью на хабре приступай к экспериментам! „
Юзер: “И что же я получу в итоге?»
Кулхацкер удивленно: «Как что? Ты будешь грузить систему! „
Интересно, с чего вы решили, что речь идет об установленных и работающих системах?
Мне казалось очевидным, что настройка загрузчика это неотъемлемый шаг именно установки.
А про выбор MS-DOS+MBR против GPT+EFI — большинство возражений, которые я встречал, сводятся к «Я не понимаю как это работает, и не хочу разбираться». Конечно, за исключением редких случаев, когда есть какая-то необходимость именно в первом варианте. Просто те, кто разобрался, перестают видеть хоть какой-то смысл в ставить систему «по старому».
Мне казалось очевидным, что настройка загрузчика это неотъемлемый шаг именно установки.
А про выбор MS-DOS+MBR против GPT+EFI — большинство возражений, которые я встречал, сводятся к «Я не понимаю как это работает, и не хочу разбираться». Конечно, за исключением редких случаев, когда есть какая-то необходимость именно в первом варианте. Просто те, кто разобрался, перестают видеть хоть какой-то смысл в ставить систему «по старому».
подскажите, а как без GRUBа всякие quiet splash, nomodeset и прочие параметры ядру передать?
Например так?
efibootmgr -c -L «Archlinux (debug)» -l '\EFI\archlinux\vmlinuz-linux' -u «root=/dev/mapper/vg1-lvroot rw initrd=\EFI\archlinux\initramfs-linux.img systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M enforcing=0 quiet splash nomodeset»
Это относится к пункту «как не надо делать»)
Почему? Пожалуй именно этого описания не хватает.
Последствиям от необходимости юзеру писать в NVRAM посвящено полстатьи. И про кирпичи, и про то что неудобно, что параметры на лету не поменяешь, и что строка длинная и сложная получается, с высоким шансом ошибиться/опечататься
Тогда тогда изменить параметры «на лету»? Поставить GRUB? Дописать параметры в /etc/modprobe.d/? Использовать efishell для загрузки nsh-скрипта? Вопрос ведь не в записи в nvram — в случае изменения одного параметра (AHCI/IDE) мы и ранее окирпичивали Windows, здесь же мы удалим пути к EFI программам установленными производителем.
> здесь же мы удалим пути к EFI программам установленными производителем.
Вот этого не понял. А параметры на лету умеет менять не только Grub.
Вот этого не понял. А параметры на лету умеет менять не только Grub.
efibootmgr --help
efibootmgr # получили список всех возможных загрузчиков для efi
efibootmgr -B -b XXXX # удалили ненужную запись
efibootmgr -c -L "..." -l "..." # добавили новую
efibootmgr --bootorder XXXX,YYYY,ZZZZ # изменили порядок загрузки
rm -rf /sys/firmware/efi/efivars/* # выстрелить себе в ногу и биться головой об стол
efibootmgr -B -b XXXX # удалили ненужную запись
efibootmgr -c -L "..." -l "..." # добавили новую
efibootmgr --bootorder XXXX,YYYY,ZZZZ # изменили порядок загрузки
rm -rf /sys/firmware/efi/efivars/* # выстрелить себе в ногу и биться головой об стол
Файлы .efi — это переносимый исполняемый файл, т.е. программа. Т. е. Setup это тоже EFI, но хранится он в чипе на материнской плате.
P.S.: Пример
Ясно, я считал что efivars это просто переменные.
efivars — это и есть переменные. Думаю что стоит почитать статьи CodeRush, или дождаться когда он расскажет о efivars и зачем они нужны сам :)
efivars — это такая псевдо-ФС в Linux, абстракция над UEFI runtime-сервисами для работы с переменными — GetVariable, SetVariable, GetNextVariableName и QueryVariableInfo.
Зачем эту псевдо-ФС по умолчанию монтируют на запись — мне не ведомо, скорее всего для efibootmgr вышеупомянутого. Вследствие того, что конкретные реализации прошивок не всегда следуют последним стандартам, а efibootmgr — не самая всезнающая утилита, то на некоторых машинах её использование действительно приводит к «кирпичу», поэтому в этом смысле я согласен с автором — положи загрузчик на ESP в \EFI\BOOT\boot{архитектура}.efi и пусть диспетчер BDS прошивки сам его найдет и добавит в BootOrder/BootXXXX заведомо правильным образом.
Что же до использования GRUB/shim/bootmgr/черта-лысого — это вкусовщина и у делу не относится.
Если вам интересно, как устроены переменные BootXXXX и BootOrder, первая устроена вот так, а вторая — просто список из UINT16, этих самых XXXX.
Проблема же efibootmgr в том, что она пытается угадать формат DevicePath, который в различных версиях стандарта периодически обновляется, а у некоторых вендоров имеет и свои собственные расширения, поэтому если вы можете ей не пользоваться — лучше и не пользуйтесь, во избежание.
Зачем эту псевдо-ФС по умолчанию монтируют на запись — мне не ведомо, скорее всего для efibootmgr вышеупомянутого. Вследствие того, что конкретные реализации прошивок не всегда следуют последним стандартам, а efibootmgr — не самая всезнающая утилита, то на некоторых машинах её использование действительно приводит к «кирпичу», поэтому в этом смысле я согласен с автором — положи загрузчик на ESP в \EFI\BOOT\boot{архитектура}.efi и пусть диспетчер BDS прошивки сам его найдет и добавит в BootOrder/BootXXXX заведомо правильным образом.
Что же до использования GRUB/shim/bootmgr/черта-лысого — это вкусовщина и у делу не относится.
Если вам интересно, как устроены переменные BootXXXX и BootOrder, первая устроена вот так, а вторая — просто список из UINT16, этих самых XXXX.
Проблема же efibootmgr в том, что она пытается угадать формат DevicePath, который в различных версиях стандарта периодически обновляется, а у некоторых вендоров имеет и свои собственные расширения, поэтому если вы можете ей не пользоваться — лучше и не пользуйтесь, во избежание.
Grub — это один из многих загрузчиков, очень навороченный.
Во всех остальных загрузчиках параметры ядру передаются абсолютно так же — прописываются в текстовом конфиге либо меняются «на лету» прям перед загрузкой (зависит уже от конкретной реализации).
Идея в том, что 7 строчек конфига и 3 файла у systemd-boot гораздо легче настраиваются, чем Grub, при одинаковом в принципе результате — на выходе меню со списком загрузки.
Во всех остальных загрузчиках параметры ядру передаются абсолютно так же — прописываются в текстовом конфиге либо меняются «на лету» прям перед загрузкой (зависит уже от конкретной реализации).
Идея в том, что 7 строчек конфига и 3 файла у systemd-boot гораздо легче настраиваются, чем Grub, при одинаковом в принципе результате — на выходе меню со списком загрузки.
А зачем для загрузки винды отдельный диск и почему именно Fat32? :) Папка EFI вполне замечательно видится загрузчиком даже если она лежит на большом NTFS разделе рядом с папкой Windows. Главное чтобы в файле EFI\Microsoft\Boot\BCD все правильно было прописано.
Упущено главное: в чем профит? Когда это может понадобиться?
Каждый раз при установке linux либо linux+windows в любых сочетаниях?
Все продвинутые дистры имеют гуй для этого.
Который не работает тогда, когда надо, или так, как надо.
Достаточно ли продвинутым дистром является Ubuntu 16.04?
Так вот, её установщик не умеет ставить систему рядом с виндой в UEFI-режиме. Я сделал пять попыток, которые все закончились одинаково. Это был как раз тот случай, когда я выбрал Убунту ради скорости установки, а в итоге потратил уйму времени и нервов. А потом примерно за 15 минут поставил Арч — с такой разбивкой диска, какая мне нужна.
Не надо про гуй, пожалуйста.
Достаточно ли продвинутым дистром является Ubuntu 16.04?
Так вот, её установщик не умеет ставить систему рядом с виндой в UEFI-режиме. Я сделал пять попыток, которые все закончились одинаково. Это был как раз тот случай, когда я выбрал Убунту ради скорости установки, а в итоге потратил уйму времени и нервов. А потом примерно за 15 минут поставил Арч — с такой разбивкой диска, какая мне нужна.
Не надо про гуй, пожалуйста.
Говоря о копировании в /boot, или приводя такие команды, как
Кстати, EFI-раздел на диске в формате GPT имеет тип EF00. А как будет себя вести система, если тип EF00 не будет найден на дисках?
bootctl install --path=/boot
Кстати, EFI-раздел на диске в формате GPT имеет тип EF00. А как будет себя вести система, если тип EF00 не будет найден на дисках?
Я проверил на флешке и трех разных загрузчиках. Комп подхватывает fat-раздел в качестве ефишного, хотя тип у него 0700 Microsoft basic data.
Думаю, Вами верно замечено, что производители реализуют UEFI, как им заблагорассудится. И тот рецепт, что подошел для одного комплекта оборудования, вполне может не подойти для другого. У меня после смены матери (на ASUS-B150) стал игнорироваться загрузчик EFI\Boot\Bootx64.efi (который systemd-boot), а загружался EFI\ubuntu\grubx64.efi Пока не нашел в BIOS-firmware переключатель Boot-mode: Windows/OtherOS и не переключил его в OtherOS.
Интересует, как правильно настроить загрузчик, расположенный на разделе одного из дисков, для загрузки нескольких ОС (Windows, OS X и Linux) с разных дисков. Сейчас использую Clover с USB флэшки, что бы загружать OS X, установленный на отдельный жёсткий диск. Без флешки просто запускается Windows.
Я понял проблему так: вы пользуетесь хакинтошем, и вы намеренно установили его на внешний жёсткий диск. Вам неудобно, что если хотите загрузиться в хакинтош, вам кроме внешнего жёсткого диска приходится вставлять ещё и флешку с кловером.
Я бы сделал так.
1) Установил бы первым загрузчиком rEFInd. По-моему самый удобный и красивый загрузчик.
2) Установил бы clover вторым загрузчиком. Вроде как он заточен именно под загрузку яблок.
3) REFInd имеет возможность обнаруживать установленные ОС даже без конфигурации конфига. Вы можете настроить, чтобы наряду с Linux и Windows в его меню отображался clover. В rEFInd есть возможность сразу добавить в меню мак, но я думаю это будет работать только на настоящих маках.
4) Когда нужен win или lin, выбираете их из меню rEFInd при включении. Если нужен хакинтош — выбираете кловер, затем, попав в него, уже выбираете мак с подключенного жёсткого диска.
Проблема решена — загрузочная флешка с кловером больше не нужна.
Я бы сделал так.
1) Установил бы первым загрузчиком rEFInd. По-моему самый удобный и красивый загрузчик.
2) Установил бы clover вторым загрузчиком. Вроде как он заточен именно под загрузку яблок.
3) REFInd имеет возможность обнаруживать установленные ОС даже без конфигурации конфига. Вы можете настроить, чтобы наряду с Linux и Windows в его меню отображался clover. В rEFInd есть возможность сразу добавить в меню мак, но я думаю это будет работать только на настоящих маках.
4) Когда нужен win или lin, выбираете их из меню rEFInd при включении. Если нужен хакинтош — выбираете кловер, затем, попав в него, уже выбираете мак с подключенного жёсткого диска.
Проблема решена — загрузочная флешка с кловером больше не нужна.
Спасибо, обязательно попробую так сделать.
И попробую добавить OS X в rEFInd, так как железо у меня всё совместимо с маками — мои процессор, материнка и видеокарта ставятся в маки и OS X с ними работает как с родным железом. Если получится, постараюсь описать процесс с ньюансами :)
Установил не на внешний, а на внутренний, но разницы нет, я так думаю.
И попробую добавить OS X в rEFInd, так как железо у меня всё совместимо с маками — мои процессор, материнка и видеокарта ставятся в маки и OS X с ними работает как с родным железом. Если получится, постараюсь описать процесс с ньюансами :)
Установил не на внешний, а на внутренний, но разницы нет, я так думаю.
о вкусах не спорят но зачем такой огород? Если загрузка только UEFI, то просто с флешьки клевера копируется папка Clover на ESP/EFI? рядом с Microsoft. Далее уже зависит от пожеланий как грузить ту или иную ОС, через базовый загрузчик, либо все через Clover, который прекрасно умеет грузить любые EFI-совместимые ОС, к слову и не EFI тоже, нужно только драйвера ФС подкинуть, чтобы считать ядро или загрузчик.
про красоту интерфейса — тем у клевера чуть меньше, чем дофига и есть дока по созданию своих.
про красоту интерфейса — тем у клевера чуть меньше, чем дофига и есть дока по созданию своих.
https://ubuntuforums.org/showthread.php?t=2294337&p=13383524#post13383524
то что нашёл навскидку
то что нашёл навскидку
Там много чего гуглится по этому вопросу, проблема решаема
Попробуйте армейский способ — подменить Windows Boot Manager, bootmgr.efi, переименованным refind_x64.efi, а оригинал положить рядом, под именем, скажем, bootmgr_orig.efi. С клевером у меня это работает прекрасно.
Только проверьте, что rEFInd работает с прямыми путями, а не относительными.
Только проверьте, что rEFInd работает с прямыми путями, а не относительными.
мой коммент будет откровением, но для uefi достаточно 48МB
И хотел бы я посмеяться над этими словами, да не получается. Когда-то я считал так-же, и себе сделал раздел 100 Мб, чтоб «с запасом». А теперь живу и мучаюсь — появилась необходимость держать две системы, и внезапно выяснилось — чуть больше 50 Мб ядро занимает. Если перед обновлением забуду fallback-ядро удалить, то обновление обламывается, а вот модули новые поставиться успевают. После ребута система мертва. А чтобы места добавить — это надо весь стек ресайзить: фс, потом логический том LVM, потом группу томов, и потом физический смещать. Называется пожалел 200 метров. Да, про вторую систему и предполагать не мог, а вот поди ж ты.
поэтому ядра и прочий мусор нужно держать в /boot, а в ESP/EFI/ только загрузчики! у меня папка Opensuse занимает всего ~4Мб и конфиг граба как вы любите, 4 строки! это правда не полноценный загрузчик а скорее прелоадер, хотя /boot/grub2 весит тоже несколько Мб всего.
Кстати МакОС при разбиении диска в GPT сразу под ESP выделяет 200Мб (она там прошивки хранит зачем-то), Винда 100. в Linux — как указать. при современных объемах видел рекомендации в полгига…
Кстати МакОС при разбиении диска в GPT сразу под ESP выделяет 200Мб (она там прошивки хранит зачем-то), Винда 100. в Linux — как указать. при современных объемах видел рекомендации в полгига…
Ещё один важный момент, если я не ошибаюсь. Если у вас x86 железо и UEFI, то вместо этого:
Переименовываем и кладем этот файл на созданный раздел по адресу /EFI/Boot/bootx64.efi
Надо файл назвать /EFI/Boot/bootia32.efi
Такого уже осталось очень мало, но мне пока попадается, особенно дешёвые китайские планшеты (Intel, x86, x64)
А кто-нибудь пробовал мигрировать установленную Windows 7 с MBR/BIOS на GPT/UEFI? Если просто сменить разметку диска с помощью gdisk, венда перестает загружаться. Раздел на месте (другая венда отлично его видит), линукс тоже без проблем работает. Обидно, поменял разметку диска по сути от скуки, и потерял установленную и обжитую систему.
Clover.… конфиг в виде xml нечитаем, настроить не смог.
Должен отметить, что это следствие его узкого назначения. Да, его можно использовать как универсальный загрузчик — примерно с тем же успехом, что и виндовый. Если сумеете настроить, ага.
Кстати, может кто-нибудь подсказать, как можно победить винду, при каждой загрузке выставляющую в NVRAM свой загрузчик первым и по умолчанию? Я это решил только армейским способом, переименовав cloverx64.efi в bootmgr.efi, но может, это просто как-то отключается?
Должен отметить, что это следствие его узкого назначения. Да, его можно использовать как универсальный загрузчик — примерно с тем же успехом, что и виндовый. Если сумеете настроить, ага.
Кстати, может кто-нибудь подсказать, как можно победить винду, при каждой загрузке выставляющую в NVRAM свой загрузчик первым и по умолчанию? Я это решил только армейским способом, переименовав cloverx64.efi в bootmgr.efi, но может, это просто как-то отключается?
К сожалению, подсказать не смогу, но могу обратить ещё внимание на то, что при некоторых обновлениях винды (редких, но такое было на моей памяти несколько раз) она обновляет и свой загрузчик тоже, тем самым перезаписывая ваш переименованный файл.
PS: В некоторых UEFI можно в настройках активировать "boot order lock", что не позволит винде менять порядок загрузчиков. Но я видел это только на lenovo.
Объясните зачем это нужно и что раньше было не так?
В первых двух предложениях я написал, зачем статья:
1. Рассказать, что происходит «под капотом» при загрузке ОС в UEFI-режиме
2. Рассказать, как при установке системы установить и настроить загрузчик
Основной причиной написания статьи является тот факт, что мой способ настройки проще и безопасней, чем в подавляющем большинстве руководств по установке системы в режиме UEFI
Вернёмся к вашему вопросу, который я не понимаю и от которого у меня болит голова)
Что именно «зачем нужно»? Когда «раньше»?
Если вопрос означает «У меня всё и так работает, зачем мне это перенастраивать» — ответ будет «Вам это не нужно, но знания могут пригодиться при переустановке системы или при возникновении проблем»
Если вопрос означает «Я предпочитаю старый способ загрузки с использованием таблицы разделов MS-DOS и MBR, зачем мне UEFI» — ответ будет «Загрузка в UEFI-режиме гораздо проще для понимания, настройки и исправления проблем. И установка нескольких ОС на один диск гораздо проще.»
1. Рассказать, что происходит «под капотом» при загрузке ОС в UEFI-режиме
2. Рассказать, как при установке системы установить и настроить загрузчик
Основной причиной написания статьи является тот факт, что мой способ настройки проще и безопасней, чем в подавляющем большинстве руководств по установке системы в режиме UEFI
Вернёмся к вашему вопросу, который я не понимаю и от которого у меня болит голова)
Что именно «зачем нужно»? Когда «раньше»?
Если вопрос означает «У меня всё и так работает, зачем мне это перенастраивать» — ответ будет «Вам это не нужно, но знания могут пригодиться при переустановке системы или при возникновении проблем»
Если вопрос означает «Я предпочитаю старый способ загрузки с использованием таблицы разделов MS-DOS и MBR, зачем мне UEFI» — ответ будет «Загрузка в UEFI-режиме гораздо проще для понимания, настройки и исправления проблем. И установка нескольких ОС на один диск гораздо проще.»
Спасибо за статью! Очень полезно!
А вы не могли бы рассказать, как Clover на Хакинтоше заставить нормально грузить с диска Ubuntu? Мне не удалось настроить.
А что конкретно у вас не заработало?
У меня Clover видит и Windows и Ubuntu и MacOS.
Причём знаний у меня на уровне — скачал iso, записал в rufus на флешку, выбрал GPT при записи, поставил с флешки.
Там единственная хитрость — я запускал efi shell из clover и путь до инсталлятора ubuntu набивал руками.
что-то типа
cd FS0:
\EFI\BOOT\BOOTX64.efi
этот путь на флешке с ubuntu должен быть — запускаешь его и загружается инсталлятор ubuntu, исталлятор прописывает запись об ubuntu в EFI раздел.
Clover потом подхватывает эту запись из EFI раздела — всё работает.
Скачиваем из интернета любой UEFI-загрузчик
(нам нужен сам загрузчик, это один бинарный файл!)
Переименовываем и кладем этот файл на созданный раздел по адресу /EFI/Boot/bootx64.efi
NTLDR.EXE от Win2000 SP4 пойдёт? А копия boot-сектора с винта с RHEL 3? (шутка)
Лучше напишите, как отличить гуашевые загрузчики от
Поиском отличать. Первая же ссылка по поиску «UEFI bootloader» даёт довольно исчерпывающую информацию.
Другое дело, что я действительно неправ, предлагая искать «любой загрузчик», по-хорошему нужна конкретика. Про «любой» я написал, чтобы дать понять что тут нет особой загрузочной магии, т.е. для более понятного объяснения самого процесса. Не хотелось бы превращать статью в руководство по настройке одного конкретного загрузчика, когда она призвана быть как можно более общей.
Другое дело, что я действительно неправ, предлагая искать «любой загрузчик», по-хорошему нужна конкретика. Про «любой» я написал, чтобы дать понять что тут нет особой загрузочной магии, т.е. для более понятного объяснения самого процесса. Не хотелось бы превращать статью в руководство по настройке одного конкретного загрузчика, когда она призвана быть как можно более общей.
Загрузочная запись нам не нужна — дело в том, что при выставлении в настройках BIOS загрузки с диска прошивка UEFI сначала ищет на нём EFI-раздел, а затем пытается исполнить файл по строго фиксированному адресу на этом разделе: /EFI/Boot/BOOTX64.EFI
вроде бы в стандарте это только для сменных накопителей. хотя по факту обычно работает.
древний hp elitobook не хотел грузиться, пока не прописал через efibootmgr
скажите плиз, что гуглить в моем случае. хочу переставить ssd с дебианом к новой мамке, подозреваю, что оно сразу не заведётся.
Тяжело, а есть ли загрузочный образ для записи или восстановления UEFI?
Вот к примеру утилита Ventoy автоматизирует создание загрузочной области на флешке. Быть может есть образ который автоматически копирует или устанавливает или формулировки или создаёт раздел или копирует UEFI на винт?
В статье даются взаимоисключающие советы. Сначала пол-статьи рассказывается, как плохо лезть в прошивку - а потом автор рекомендует bootctl install --path=/boot которая, как пишет сам же автор, добавляет свою загрузочную запись в прошивку. Это как вообще понимать? Стилистическая ошибка текста? Или оно действительно лезет в прошивку?
ну вроде бы автор не призывает ставить так, а просто указывает, что штатный способ установки systemd-boot проще, чем штатный способ установки grub.
если же ваш вопрос «можно ли с помощью bootctl поставить загрузчик не добавляя загрузочную запись», то у него есть опция --no-variables
кстати да, лайк за инфу. Но мне в итоге не понравилась сама концепция, в которой ядро и инитрд должны лежать на той же фс. А если мне дебажное ядро захочется, а оно не влазит на раздел...Так что я перешел на refind, который умеет грузить ядра с разделов.
Вообще, ядумаю, что затирать во флешке запуск /efi/boot/bootx64.efi - это как-то неправильно. А bootctl делает это без спроса. еще и записывает на флешку /efi/boot/bootx64.efi как обманку, и пользователь пребывает в уверенности, что запускается именно bootx64
Но мне в итоге не понравилась сама концепция, в которой ядро и инитрд должны лежать на той же фс. А если мне дебажное ядро захочется, а оно не влазит на раздел...Так что я перешел на refind, который умеет грузить ядра с разделов
А мне наоборот нравится идея отказа «навороченных» загрузчиков. По сути, grub или refind — это ещё одна операционная система, со своими драйверами файловых систем, рейдов и т.п.
Зачем это лишнее звено, когда uefi bios уже даёт всё необходимое для загрузки linux? Нам нужно только отобразить меню и запустить выбранный бинарник (ядро linux обычно собирается как uefi executable).
Ну а сделать раздел достаточного размера совсем не сложно
Вообще, ядумаю, что затирать во флешке запуск /efi/boot/bootx64.efi - это как-то неправильно. А bootctl делает это без спроса. еще и записывает на флешку /efi/boot/bootx64.efi как обманку, и пользователь пребывает в уверенности, что запускается именно bootx64
Не понял
Ну, пользователь запустил bootctl, установил загрузчик от systemd. Посмотрел содержимое флешки: "ага, вот он, родимый, лежит в /efi/boot/bootx64.efi" - подумал пользователь, заблуждаясь. Дальше диск накрылся, пользователь вставляет другой диск - и ничего не грузится.
А все потому, что bootctl удалил из биоса запись с загрузкой /efi/boot/bootx64.efi и прописал что то свое. Но файл есть - и подвох не так просто заметить.
что-то какая-то надуманная проблема на мой взгляд.
во-первых, uefi bios хранит список вариантов загрузки с привязкой к дискам, так что настройки от старого диска не применятся к новому.
во-вторых, автор статьи как раз предлагает не редактировать список вариантов загрузки (хотя у этого предложения есть и недостатки, например, некоторые старые bios использовали дефолт только для сменных носителей, если просто положить загрузчик в /efi/boot/bootx64.efi стационарного hdd/ssd и не создавать записи, то ничего не загрузится)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Настройка UEFI-загрузчика. Самое краткое руководство в мире