@twi1ight_spark1e помнишь, ты говорил про граб в /boot/efi/EFI/BOOTX64.efi? У меня сейчас так:

altracer@glacier:~$ fdupes -S -r /boot/efi/EFI/
1557816 bytes each:
/boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
/boot/efi/EFI/Boot/bootx64.efi

Помню, было дело
В чем нюанс?

Документации нет потому что

На самом деле почти всё (что можно было перенести) я нашел в man openrc-run
Но про rc_ulimit пришлось вычитывать хуй знает где

Там виндовый лежал (см.выхлоп поиска дубликатов), сейчас сделал так:

altracer@glacier ~> sudo grub-install --efi-directory=/boot/efi --removable
Выполняется установка для платформы x86_64-efi.
Установка завершена. Ошибок нет.
altracer@glacier ~> fdupes -S -r /boot/efi
131072 bytes each:                      
/boot/efi/EFI/gentoo/grubx64.efi
/boot/efi/EFI/Boot/bootx64.efi

Не знаю, как по мне писать скрипты под openrc слишком трудоемко

Вроде не то чтобы
Современный опенрц весьма себе декларативный

Но на некоторые вещи всё ещё приходится прибегать к миниатюрным портянкам, конечно

Я как то сравнивал время написание одного и того же на systemd и openrc. Openrc час, systemd 8 минут

Это проблема с точки зрения мейнтейнера, но не меня как крайне ленивого пользователя =Ъ
Я этих опенрцшных сервисов пишу по штуке в пару месяцев, в среднем

Даже для разработчика это не такая прям большая проблема
Написать один инит для одной софтины — не такая большая проблема, всё равно на разработку главного функционала уйдет значительно больше времени

Ну вот поэтому я и перестал обслуживать openrc как майнтейнер (патчез аре велком хотя обычно)

ну не скажи, в том же Alpine те же Natanael Copa да Ariadne Conill просто ссылаются на релизы исходников в апстриме, а вот openrc $pkgname.initd приходится писать именно им

И радуйся, если разработчик конкретной проги вообще знает, что существует что-либо кроме SystemD

Разработчикам может быть не на чем тестить инит, поэтому они его не пишут
Примерно то же самое случилось с maddy — автор сказал заслать ему опенрцшный инит как напишу, потому что самому ему проверить то и не на чем (да и изучать ещё одну систему инициализация он вряд ли горит желанием)

Как понять не на чём? docker pull alpinelinux/build-base:latest и ставишь свою прогу туда

Сейчас что угодно на чём угодно можно тестить, тем более в эпоху WSL2

Напишет, запустит, увидит что как-то оно работает, закоммитит
Потом начнут всплывать нюансы типа "а куда лог пишется", "а чё там по супервайзингу"

А почему флаг libglvnd нельзя выключить? Типа, у меня только Intel и иксы, на кой мне переключение реализаций OpenGL?

Посмотри в профиль, он там должен осесть

Нашёл. Но если отключить, то тянет eselect-opengl. То есть, от обоих никак не избавиться без правки ебилдов