farwayer Сообщения

farwayer	# 8 лет, 10 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	elsonador Путь до ядра считывает UEFI. Да, но efibootmngr у меня сам вставляет нужный слэш, как бы он не был написан. Возможно, в старых версиях этого не происходило.

farwayer	# 8 лет, 10 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	Начиная с версии ядра 3.8.0 можно использовать как прямые, так и обратные слэши.

farwayer	# 8 лет, 10 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	Кстати, для тех, кому религия не позволяет хранить ядро и initram в корне UEFI раздела, а делать костыли с systemd, cron'ом или хуком mkinitcpio для синхронизации ядра при его обновлении не хочется, есть еще один способ. Можно хранить ядро в ESP\EFI\arch, как описано в вики и спецификации UEFI, и монтировать этот путь на /boot через mount --bind.

farwayer

# 8 лет, 10 месяцев назад

Темы: 12

Сообщения: 181

Участник с: 30 апреля 2010

Кстати, для тех, кому религия не позволяет хранить ядро и initram в корне UEFI раздела, а делать костыли с systemd, cron'ом или хуком mkinitcpio для синхронизации ядра при его обновлении не хочется, есть еще один способ.
Можно хранить ядро в ESP\EFI\arch, как описано в вики и спецификации UEFI, и монтировать этот путь на /boot через mount --bind.

farwayer	# 8 лет, 10 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	elsonador Ну дык ядро и встроенной поддержки FAT не имеет. Как оно будет грузить initramfs? Да, верно. Но подгрузкой initramfs занимается EFI STUB, который почти наверняка делает это через функции EFI_FILE_PROTOCOL в UEFI, такие как Open() и Read(). По крайней мере, я бы делал именно так. Таким образом, если в UEFI добавить драйвер чтения ext4, то загружать initram можно было бы даже с другого раздела с этой ФС. Но такой способ EFI STUB не поддерживает - initram должен находиться на разделе UEFI. Да и смысла оставлять initram на другом разделе, если ядро на разделе UEFI, нет. elsonador farwayer Так и должно быть. Там UTF-16. А вдруг не должно? Прошу прощения, там на самом деле не UTF-16, а его предшественник - UCS-2. Но смысла это не меняет.

farwayer

# 8 лет, 10 месяцев назад

Темы: 12

Сообщения: 181

Участник с: 30 апреля 2010

elsonador
Ну дык ядро и встроенной поддержки FAT не имеет. Как оно будет грузить initramfs?

Да, верно. Но подгрузкой initramfs занимается EFI STUB, который почти наверняка делает это через функции EFI_FILE_PROTOCOL в UEFI, такие как Open() и Read(). По крайней мере, я бы делал именно так. Таким образом, если в UEFI добавить драйвер чтения ext4, то загружать initram можно было бы даже с другого раздела с этой ФС. Но такой способ EFI STUB не поддерживает - initram должен находиться на разделе UEFI. Да и смысла оставлять initram на другом разделе, если ядро на разделе UEFI, нет.

elsonador
farwayer
Так и должно быть. Там UTF-16.
А вдруг не должно?

Прошу прощения, там на самом деле не UTF-16, а его предшественник - UCS-2. Но смысла это не меняет.

farwayer	# 8 лет, 10 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	elsonador Автор, а автор? Ты сам-то свою инструкцию пробовал? Нет, это полет моей больной фантазии %) elsonador Я краем уха слышал, что UEFI does not support loading a separate initramfs. Перевод нужен? Что, простите? UEFI вообще знать не знает ни про какие initramfs, ядра и т.п. творения создателей ОС. Он знает, как найти и передать управление на UEFI-загрузчик с прописанными в NVRAM параметрами. Все остальное не его дело. Если имелось в виду, что ядро не может загрузить образ initramfs с другого раздела где ФС, которую не поддерживает ядро, то, отчасти, это верно. Можно собрать ядро с поддержкой этой ФС, но тогда смысла в initramfs вообще нету. Либо добавить драйвер ext4 в UEFI (но такой вариант я не пробовал и не уверен, что ядро его поддерживает). Если бы внимательно читали мою заметку, то поняли бы, что и ядро, и initramfs находятся на разделе UEFI. Последовательность загрузки: 1. UEFI считывает BootXXXX запись и достает из нее путь к загрузчику-ядру (/vmlinuz-linux) и параметры для него (initrd=/initramfs-linux.img root=PARTUUID=087e1626-ccc5-468a-ab8d-ca02f8f04d14 ro add_efi_memmap) 2. UEFI передает управление ядру 3. Ядро подгружает initramfs с раздела UEFI (initrd=/initramfs-linux.img) 4. Теперь ядро спокойно может читать rootfs с ext4 (или что там у вас) и грузиться дальше Хотя бы рассказали, что именно у вас не работает. elsonador Откуда там точки образовались? Так и должно быть. Там UTF-16. Natrio Просто пересказываю, что выяснил – разработчики ядра приняли все меры к тому, чтобы ядро Linux при желании МОЖНО было даже "подсунуть вместо загрузчика" UEFI. Как раз про это и заметка.

farwayer

# 8 лет, 10 месяцев назад

Темы: 12

Сообщения: 181

Участник с: 30 апреля 2010

elsonador
Автор, а автор? Ты сам-то свою инструкцию пробовал?

Нет, это полет моей больной фантазии %)

elsonador
Я краем уха слышал, что UEFI does not support loading a separate initramfs. Перевод нужен?

Что, простите? UEFI вообще знать не знает ни про какие initramfs, ядра и т.п. творения создателей ОС. Он знает, как найти и передать управление на UEFI-загрузчик с прописанными в NVRAM параметрами. Все остальное не его дело. Если имелось в виду, что ядро не может загрузить образ initramfs с другого раздела где ФС, которую не поддерживает ядро, то, отчасти, это верно. Можно собрать ядро с поддержкой этой ФС, но тогда смысла в initramfs вообще нету. Либо добавить драйвер ext4 в UEFI (но такой вариант я не пробовал и не уверен, что ядро его поддерживает).

Если бы внимательно читали мою заметку, то поняли бы, что и ядро, и initramfs находятся на разделе UEFI.
Последовательность загрузки:
1. UEFI считывает BootXXXX запись и достает из нее путь к загрузчику-ядру (/vmlinuz-linux) и параметры для него (initrd=/initramfs-linux.img root=PARTUUID=087e1626-ccc5-468a-ab8d-ca02f8f04d14 ro add_efi_memmap)
2. UEFI передает управление ядру
3. Ядро подгружает initramfs с раздела UEFI (initrd=/initramfs-linux.img)
4. Теперь ядро спокойно может читать rootfs с ext4 (или что там у вас) и грузиться дальше

Хотя бы рассказали, что именно у вас не работает.

elsonador
Откуда там точки образовались?

Так и должно быть. Там UTF-16.

Natrio
Просто пересказываю, что выяснил – разработчики ядра приняли все меры к тому, чтобы ядро Linux при желании МОЖНО было даже "подсунуть вместо загрузчика" UEFI.

Как раз про это и заметка.

farwayer	# 8 лет, 10 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	На хабре вышла довольно подробная статья про загрузку через EFI Boot Stub.

farwayer	# 8 лет, 11 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	Первым пунктом же https://wiki.archlinux.org/index.php/Openbox_Themes_and_Apps#Application_launchers ...

farwayer	# 8 лет, 12 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	Прошу прощения, что некропощу в своей же теме, но есть дельный совет: никогда не подрубайте холодильник к тому же удлинителю, что и комп! :)

farwayer	# 8 лет, 12 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	Natrio Это правда работает быстрее? Если выключена обратная совместимость с BIOS - то да. У меня -3 секунды к загрузке. Но вообще это зависит от материнки и конкретной реализации UEFI. Ускорение достигается как раз за счет быстрой инициализации устройств. Natrio И да, у вас явно деструктивная рекомендация в конце – если вы удалите каталог /boot , смонтировать в него раздел явно не получится. Это от недосыпа было... Когда перечитывал, понял, какую фигню написал :) cucullus Зачем всё это, зачееееем? (песня какая-то такая была) А незачем. Просто новый комп настраивал и решил поковырять. Чуть быстрее загружаться стал. Минус один пакет в системе (syslinux). cucullus Я уже :) Кто со мной? Вижу, ни у одного меня свободный график ;) Присоединился бы, но предпочитаю это дело real2real xD

farwayer

# 8 лет, 12 месяцев назад

Темы: 12

Сообщения: 181

Участник с: 30 апреля 2010

Natrio
Это правда работает быстрее?

Если выключена обратная совместимость с BIOS - то да. У меня -3 секунды к загрузке. Но вообще это зависит от материнки и конкретной реализации UEFI. Ускорение достигается как раз за счет быстрой инициализации устройств.

Natrio
И да, у вас явно деструктивная рекомендация в конце – если вы удалите каталог /boot , смонтировать в него раздел явно не получится.

Это от недосыпа было... Когда перечитывал, понял, какую фигню написал :)

cucullus
Зачем всё это, зачееееем? (песня какая-то такая была)

А незачем. Просто новый комп настраивал и решил поковырять. Чуть быстрее загружаться стал. Минус один пакет в системе (syslinux).

cucullus
Я уже :) Кто со мной?

Вижу, ни у одного меня свободный график ;) Присоединился бы, но предпочитаю это дело real2real xD

farwayer	# 8 лет, 12 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	Предполагается, что ты знаком с основами UEFI и принципом загрузки ОС через него. Это не мануал, а кратко скомпонованные факты. Если не знаешь, как сделать GPT таблицу разделов или отформатировать EFI раздел - кури вики. В заметке не будет пространных размышлений о плюсах и минусах UEFI - думайте сами, решайте сами, иметь или не иметь (с). Итак, приступим. Что нам нужно, для того, чтобы загрузиться через UEFI (кроме совместимой материнки)? GPT таблица разделов. Отформатированный FAT32 (FAT12, FAT16, но это - старье) раздел со специальной сигнатурой C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System Partition - ESP). UEFI-совместимый бинарник, расположенный на этом разделе. Почему-то считается, что он должен лежать по пути \EFI\${VENDOR}\${LOADER}.efi. Как мы убедимся позже - необязательное условие. Бинарник должен быть правильной платформы: загрузить x86 на x86_64 процессоре не получится. Опционально: запись BootXXXX в параметрах UEFI, которая указывает на нужный бинарник. По умолчанию загружается \EFI\BOOT\boot[architecture name].efi. В вики описаны 3 способа загрузки linux через UEFI: Внешний загрузчик (rEFInd, gummiboot, grub2, syslinux>=6.x, ...), расположенный на ESP разделе - не наш случай. Мы ведь не хотим загрузчик, правда? ;) Через UEFI Shell - специальный шелл, который может быть уже встроен в UEFI или устанавливаться отдельно на ESP раздел (http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome). Для этого нам нужно выполнить команды: > fs0: > cd \EFI\arch > vmlinuz-arch.efi root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 ro rootfstype=ext4 add_efi_memmap initrd=EFI/arch/initramfs-arch.img Или создать специальный MS-DOS подобный скрипт archlinux.nsh в корне ESP: echo -on \EFI\arch\vmlinuz-arch.efi root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 rootfstype=ext4 add_efi_memmap initrd=EFI/arch/initramfs-arch.img Тогда можно будет делать так: fs0: archlinux Если назвать этот скрипт startup.nsh (о чем вики скромно умалчивает), то скрипт будет автоматически исполнен через 5 сек (ваш Кэп). Последовательность загрузки в этом случае: UEFI -> UEFI Shell -> скрипт -> ядро. Слишком много сущностей, тебе не кажется? Еще и ждать. А мы ведь любим целоваться... Вывод: в пень! Создать запись BootXXXX (XXXX - от 0x0000 до 0xFFFF) в EFI vars с помощью efibootmgr и напрямую передавать управление ядру. Для того, чтобы пункты 2 и 3 работали, ядро должно быть собрано с особыми параметрами, т.е. прикидываться UEFI бинарником. Эти параметры были добавлены в Linux>=3.3. Они включены по умолчанию в ядро archlinux и некоторые другие ядра из AUR и сторонних реп (linux-ck, например). Тут вырисовывается очевидное ограничение: таким образом не загрузишь x86 систему на x86_64 процессоре (помнишь про это ограничение бинарника UEFI?). Описывать я буду как раз 3 способ. Что нам советует вики для 2 и 3 случая? Только не спеши повторять! Создать ESP раздел. Смонтировать его на /boot/efi Создать директорию /boot/efi/EFI/arch/ Скопировать ядро и initramfs на ESP раздел /boot/vmlinuz-linux -> /boot/efi/EFI/arch/vmlinuz-arch.efi /boot/initramfs-linux.img -> /boot/efi/EFI/arch/initramfs-arch.img /boot/initramfs-linux-fallback.img -> /boot/efi/EFI/arch/initramfs-arch-fallback.img Теперь ESP раздел у нас подготовлен. Или нет? А что будет, если ядро обновиться? Опять руками копировать? У вики есть 3 способа для тебя, парень (и да простят меня милые девушки)! Systemd юнит и path-файл для его активации (следит за изменением файла), которые зачем-то предлагают сохранить в /usr/lib/systemd/system/, вместо предназначенного для пользовательских файлов /etc/systemd/system/ (святотатство-то какое!). lncron mkinitcpio hook Вроде, теперь все хорошо. А в fstab кто за тебя ESP раздел прописывать будет?! Опять вики молчит, как партизанка. Объединяет эти 3 способа только то, что они - костыли! Это не наш метод, бро! Ты ведь не следовали этим советам, правда? ;) А что, если сгрузить ядро в корень ESP раздела и монтировать его как /boot, прописав его в BootXXXX запись не как \EFI\arch\vmlinuz-arch.efi, а \vmlinuz-linux? Тогда при обновлении ядра, оно автоматически сгрузиться на ESP раздел, без каких-либо танцев с бубном. А будет ли это работать? Спека по UEFI (12.3.1.3 Directory Structure) говорит, что бинарники должны располагаться в \EFI\${VENDOR}, иначе возможны коллизии имен. Но мы-то сами знаем, что и где у нас лежит на ESP разделе! Как-нибудь уж сами разберемся с коллизиями, чай не маленькие дети. Тест на 2 материнках от разных производителей (Asus P8Z77-I DELUXE и Gigabyte B75-N) показал, что способ вполне себе рабочий. В самом деле: нафик UEFI проверять путь на валидность? Если кто-то его прописал - значит попробуем загрузить! Итак, план действий: Копируем vmlinuz-linux, initramfs-linux.img и initramfs-linux-fallback.img (по желанию) в /tmp: cp /boot/{vmlinuz-linux,initramfs-linux.img,initramfs-linux-fallback.img} /tmp/ Монтируем ESP раздел на /boot: mount <UEFI Partition> /boot Перемещаем из /tmp на ESP: mv /tmp/{vmlinuz-linux,initramfs-linux.img,initramfs-linux-fallback.img} /boot/ Добавляем запись в /etc/fstab: UUID=be445405-0426-4e59-8614-c9873d685419 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 2 где be445405-0426-4e59-8614-c9873d685419 - UUID раздела (узнать можно ls -l /dev/disk/by-uuid/). Добавляем BootXXXX запись с помощью efibootmgr: # modprobe efivars # efibootmgr -c -d /dev/sdX -p Y -l /vmlinuz-linux -L "Arch Linux" -u "initrd=/initramfs-linux.img root=PARTUUID=087e1626-ccc5-468a-ab8d-ca02f8f04d14 ro add_efi_memmap" где sdX - диск с ESP, Y - номер ESP раздела, 087e1626-ccc5-468a-ab8d-ca02f8f04d14 - PARTUUID (≠UUID) root-раздела (ls -l /dev/disk/by-partuuid). Для fallback, если нужно, аналогично. Кстати, тут в вики очередной фейл: они указывают "$(cat /proc/cmdline)", в качестве командной строки ядра. При загрузки в не-UEFI режиме или с флешки установщика - там будет не то, что нам нужно! АХТУНГ: До версии ядра 3.8 нужно использовать обратные слэши (\) в пути к initramfs. Т.е. путь долже выглядеть так: initrd=\\initramfs-linux.img Опционально: при успешной загрузке сносим ставшие ненужными файлы с корня: umount /boot rm /boot/{vmlinuz-linux,initramfs-linux.img,initramfs-linux-fallback.img} mount /boot Выпиваем пару литров божественного компота из хмеля и солода (или морковного сока, по желанию) Все. UPD: На хабре вышла довольно подробная статья про загрузку через EFI Boot Stub. UPD2: Кстати, для тех, кому религия не позволяет хранить ядро и initram в корне UEFI раздела, а делать костыли с systemd, cron'ом или хуком mkinitcpio для синхронизации ядра при его обновлении не хочется, есть еще один способ. Можно хранить ядро в ESP\EFI\arch, как описано в вики и спецификации UEFI, и монтировать этот путь на /boot через mount --bind.

farwayer

# 8 лет, 12 месяцев назад

Темы: 12

Сообщения: 181

Участник с: 30 апреля 2010

*Предполагается, что ты знаком с основами UEFI и принципом загрузки ОС через него. Это не мануал, а кратко скомпонованные факты. Если не знаешь, как сделать GPT таблицу разделов или отформатировать EFI раздел - кури вики.
*В заметке не будет пространных размышлений о плюсах и минусах UEFI - думайте сами, решайте сами, иметь или не иметь (с).

Итак, приступим.
Что нам нужно, для того, чтобы загрузиться через UEFI (кроме совместимой материнки)?

GPT таблица разделов.
Отформатированный FAT32 (FAT12, FAT16, но это - старье) раздел со специальной сигнатурой C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System Partition - ESP).
UEFI-совместимый бинарник, расположенный на этом разделе. Почему-то считается, что он должен лежать по пути \EFI\${VENDOR}\${LOADER}.efi. Как мы убедимся позже - необязательное условие. Бинарник должен быть правильной платформы: загрузить x86 на x86_64 процессоре не получится.
Опционально: запись BootXXXX в параметрах UEFI, которая указывает на нужный бинарник. По умолчанию загружается \EFI\BOOT\boot[architecture name].efi.

В вики описаны 3 способа загрузки linux через UEFI:

Внешний загрузчик (rEFInd, gummiboot, grub2, syslinux>=6.x, ...), расположенный на ESP разделе - не наш случай. Мы ведь не хотим загрузчик, правда? ;)
Через UEFI Shell - специальный шелл, который может быть уже встроен в UEFI или устанавливаться отдельно на ESP раздел (http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome). Для этого нам нужно выполнить команды:
```
> fs0:
> cd \EFI\arch
> vmlinuz-arch.efi root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 ro rootfstype=ext4 add_efi_memmap initrd=EFI/arch/initramfs-arch.img
```
Или создать специальный MS-DOS подобный скрипт archlinux.nsh в корне ESP:
```
echo -on
\EFI\arch\vmlinuz-arch.efi root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 rootfstype=ext4 add_efi_memmap initrd=EFI/arch/initramfs-arch.img
```
Тогда можно будет делать так:
```
fs0:
archlinux
```
Если назвать этот скрипт startup.nsh (о чем вики скромно умалчивает), то скрипт будет автоматически исполнен через 5 сек (ваш Кэп).
Последовательность загрузки в этом случае: UEFI -> UEFI Shell -> скрипт -> ядро.
Слишком много сущностей, тебе не кажется? Еще и ждать. А мы ведь любим целоваться... Вывод: в пень!
Создать запись BootXXXX (XXXX - от 0x0000 до 0xFFFF) в EFI vars с помощью efibootmgr и напрямую передавать управление ядру.

Для того, чтобы пункты 2 и 3 работали, ядро должно быть собрано с особыми параметрами, т.е. прикидываться UEFI бинарником. Эти параметры были добавлены в Linux>=3.3. Они включены по умолчанию в ядро archlinux и некоторые другие ядра из AUR и сторонних реп (linux-ck, например). Тут вырисовывается очевидное ограничение: таким образом не загрузишь x86 систему на x86_64 процессоре (помнишь про это ограничение бинарника UEFI?).

Описывать я буду как раз 3 способ. Что нам советует вики для 2 и 3 случая? Только не спеши повторять!

Создать ESP раздел.
Смонтировать его на /boot/efi
Создать директорию /boot/efi/EFI/arch/

Скопировать ядро и initramfs на ESP раздел

/boot/vmlinuz-linux -> /boot/efi/EFI/arch/vmlinuz-arch.efi
/boot/initramfs-linux.img -> /boot/efi/EFI/arch/initramfs-arch.img
/boot/initramfs-linux-fallback.img -> /boot/efi/EFI/arch/initramfs-arch-fallback.img

Теперь ESP раздел у нас подготовлен. Или нет? А что будет, если ядро обновиться? Опять руками копировать? У вики есть 3 способа для тебя, парень (и да простят меня милые девушки)!

Systemd юнит и path-файл для его активации (следит за изменением файла), которые зачем-то предлагают сохранить в /usr/lib/systemd/system/, вместо предназначенного для пользовательских файлов /etc/systemd/system/ (святотатство-то какое!).
lncron
mkinitcpio hook

Вроде, теперь все хорошо. А в fstab кто за тебя ESP раздел прописывать будет?! Опять вики молчит, как партизанка.

Объединяет эти 3 способа только то, что они - костыли! Это не наш метод, бро! Ты ведь не следовали этим советам, правда? ;)
А что, если сгрузить ядро в корень ESP раздела и монтировать его как /boot, прописав его в BootXXXX запись не как \EFI\arch\vmlinuz-arch.efi, а \vmlinuz-linux? Тогда при обновлении ядра, оно автоматически сгрузиться на ESP раздел, без каких-либо танцев с бубном. А будет ли это работать? Спека по UEFI (12.3.1.3 Directory Structure) говорит, что бинарники должны располагаться в \EFI\${VENDOR}, иначе возможны коллизии имен. Но мы-то сами знаем, что и где у нас лежит на ESP разделе! Как-нибудь уж сами разберемся с коллизиями, чай не маленькие дети. Тест на 2 материнках от разных производителей (Asus P8Z77-I DELUXE и Gigabyte B75-N) показал, что способ вполне себе рабочий. В самом деле: нафик UEFI проверять путь на валидность? Если кто-то его прописал - значит попробуем загрузить!

Итак, план действий:

Копируем vmlinuz-linux, initramfs-linux.img и initramfs-linux-fallback.img (по желанию) в /tmp:
```
cp /boot/{vmlinuz-linux,initramfs-linux.img,initramfs-linux-fallback.img} /tmp/
```
Монтируем ESP раздел на /boot:
```
mount <UEFI Partition> /boot
```

Перемещаем из /tmp на ESP:

mv /tmp/{vmlinuz-linux,initramfs-linux.img,initramfs-linux-fallback.img} /boot/

Добавляем запись в /etc/fstab:

UUID=be445405-0426-4e59-8614-c9873d685419 /boot     	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro	0 2

где be445405-0426-4e59-8614-c9873d685419 - UUID раздела (узнать можно ls -l /dev/disk/by-uuid/).

Добавляем BootXXXX запись с помощью efibootmgr:
```
# modprobe efivars
# efibootmgr -c -d /dev/sdX -p Y -l /vmlinuz-linux -L "Arch Linux" -u "initrd=/initramfs-linux.img root=PARTUUID=087e1626-ccc5-468a-ab8d-ca02f8f04d14 ro add_efi_memmap"
```
где sdX - диск с ESP, Y - номер ESP раздела, 087e1626-ccc5-468a-ab8d-ca02f8f04d14 - PARTUUID (≠UUID) root-раздела (ls -l /dev/disk/by-partuuid). Для fallback, если нужно, аналогично.
Кстати, тут в вики очередной фейл: они указывают "$(cat /proc/cmdline)", в качестве командной строки ядра. При загрузки в не-UEFI режиме или с флешки установщика - там будет не то, что нам нужно!
АХТУНГ: До версии ядра 3.8 нужно использовать обратные слэши (\) в пути к initramfs. Т.е. путь долже выглядеть так: initrd=\\initramfs-linux.img
Опционально: при успешной загрузке сносим ставшие ненужными файлы с корня:
```
umount /boot
rm /boot/{vmlinuz-linux,initramfs-linux.img,initramfs-linux-fallback.img}
mount /boot
```
Выпиваем пару литров божественного компота из хмеля и солода (или морковного сока, по желанию)

Все.

UPD: На хабре вышла довольно подробная статья про загрузку через EFI Boot Stub.

UPD2: Кстати, для тех, кому религия не позволяет хранить ядро и initram в корне UEFI раздела, а делать костыли с systemd, cron'ом или хуком mkinitcpio для синхронизации ядра при его обновлении не хочется, есть еще один способ.
Можно хранить ядро в ESP\EFI\arch, как описано в вики и спецификации UEFI, и монтировать этот путь на /boot через mount --bind.