В OpenSUSE появилась экспериментальная поддержка systemd-boot вместо GRUB

Ключевое слово «если». Из коробки это никто кроме граба не умеет делать емнип. Можно наверное заморочиться и замутить цепочку загрузчиков, вот тут например есть описание как это провернуть с systemd-boot.

Но зачем это нужно не особо понятно. Какую ценную информацию нужно прятать в буте? Ядро и файлы в initrd у подавляющего большинства дефолтные из репозиториев дистрибутива с дефолтными же настройками из гайдов. Воссоздать цепочку загрузки с расшифровкой всех разделов по пути несложно.

Здесь эффективны только аппаратные ключи (читай TPM), и опять же это делает шифрование бута нафиг не нужным. Можно хоть напрямую хакерам письмо выслать с приложением своего initrd, без ключей от него нет никакого толку.

Это все так, но в текущей схеме хранить ключи в TPM можно только при включенном Secure Boot. А с этим есть свои заморочки с подписью всего и вся. Я пока не знаю можно ли как-то включить TPM без Secure Boot. Если да, то все ОК.

Нормальные EFI прошивки умеют в MBR, соотв. и systemd-boot на таком будет работать.

Нет, тут шла речь про MBR-запись в первом секторе. Ее-то как-раз Systemd-Boot и не сможет сделать, ибо не умеет. А то, что и на MBR можно сделать EFI-раздел и раздел с ОС - это я и так знаю.

Экспериментальная поддержка - это же ведь не должно означать, что будет только один новый загрузчик? При установке же можно будет выбрать, как раньше между Lilo и Grub?

В случае с Systemd сами понимайте, что это и может означать. Много альтернатив там предлагают пользователям Systemd? 0? А как так-то? Выбор между Lilo и Grub был только потому, что оба имели сходную структуру. А здесь - принципиально другая структура. В общем, графический менеджер EFI-софта, коим Grub не является.

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

К счастью, systemd уже не зависит от интереса Леннарта к жизни. Мы получаем более-менее консистентную систему загрузки, поддержки демонов, логгирования и еще много чего. Да, она будет такая. Да, демон «заточенный» для systemd выглядит сильно не так как раньше. Да, у него может появиться dbus-интерфейс и systemd будет им управлять. Да, линукс начинает выглядеть несколько не так как раньше, но это становится долголетним мейнстримом, что неплохо для промышленного использования. Хотите вечного красноглазия и вечного «состояния беты» — ну, как бы, велком в альтернативные дистрибутивы.

Конечно можно, у TPM нет никакого требования к наличию Secure Boot. Их просто рекомендуют использовать в комбинации для усиления защиты.

Хотя в мире проприетарного железа конечно все возможно, производители в своих UEFI прошивках могут любую дичь творить. Взять например ноуты, где SB вообще нельзя выключить.

Ну и TPM в принципе не имеет прямой связи с бутом, это модуль общего назначения. Он может использоваться для произвольных целей другими приложениями, например хранить пароли пользователя итд.

Мне тоже так кажется, что TPM не зависит от SecureBoot, но реальность несколько другая:

Built-in FDE support requires both UEFI Secure Boot and TPM 2.0 (Trusted Platform Module) support, but its implementation in Ubuntu Core is generic and widely compatible to help support a range of hardware. External I2C/SPI-based TPM modules are not currently supported.

TPM-based FDE seals the FDE secret key to the full EFI state, including the kernel command line, which is subsequently unsealed by the initrd code in the secure-boot protected kernel.efi at boot time.

Отсюда — https://ubuntu.com/core/docs/full-disk-encryption

Мы получаем более-менее консистентную систему загрузки, поддержки демонов, логгирования и еще много чего.

Если бы. Мы получаем некий комбайн, куда «завезли» уже и текстовый редактор, и шелл, и гипервизор, если я правильно понял, и загрузчик, а вот удобной системы инициализации мы не получили. В моём Дебиане по прежнему есть /etc/init.d с «баш-портянками».

И от них избавиться в принципе невозможно, поскольку перед запуском «демона» почти всегда требуется выполнить ряд проверок и в зависимости от них передать «демону» параметры и/или выполнить настройку «окружения»: проверить наличие конфигурационного файла, скопировать дефолтный (который может лежать по разным путям в разных дистрах) в рабочую директорию, если не было, предварительно проверив наличие рабочей директории, возможности записи в неё или её создания и т.д.

Понятно, что всё это можно и дОлжно быть в юните, но в чём тогда разница с баш-скриптами?!

А теперь такой простой практический вопрос. «Демоны» должны запускаться в некоем порядке и не след запускать «демон» до запуска службы, от работы которой он зависит. systemd это позволяет сделать. Но как не лазя в лог загрузки узнать, что за чем стартует, чтобы понять, куда впихнуть тебе нужный? Изучение юнити типа цель (target) не подходит, это аналог уровня запуска.

Разве что реальность пользователей этого дистрибутива.

Built-in FDE support

Это речь конкретно о том как у них сделано. Если все делать самостоятельно, то можно как угодно вертеть.

Вот например статья как сделать шифрование через systemd-cryptsetup. Там описано использование различных источников хардварных ключей, включая TPM.

В моём Дебиане по прежнему есть /etc/init.d с «баш-портянками». И от них избавиться в принципе невозможно

Возможно, если захотеть.

Понятно, что всё это можно и дОлжно быть в юните, но в чём тогда разница с баш-скриптами?!

Разница есть. И дело даже не в содержимом скрипта, а в том каким образом он запускается. Systemd позволяет выстроить сложную иерархию сервисов с зависимостями итд, настроить реакцию на определенные условия (например выполнить какие-то действия если сервис покрашился).

Ну то есть да, на скриптах в теории все это тоже возможно реализовать, все же баш тьюринг-полный язык. Вот только зачем заниматься написанием велосипедов, когда можно переложить все это на плечи системы инициализации?

Но как не лазя в лог загрузки узнать, что за чем стартует, чтобы понять, куда впихнуть тебе нужный?

Непонятно в чем проблема слазить в лог, но в целом systemctl status показывает иерархию зависимостей.

Спасибо, почитаем, может что и получится..

Вот как знаток systemd, скажите пожалуйста, такие штуки

PrivateTmp=true
ProtectHome=true
ProtectSystem=full
NoNewPrivileges=true
ProtectControlGroups=true
ProtectKernelModules=true
ProtectKernelTunables=true

Можно как-то сделать, чтобы при каждом обновлении PostgreSQL они не оказывались в юните заново?

Я ж их удаляю. Они мне мешают. По идее - это ж мои настройки запуска сервиса, не надо их перетирать каждый раз (оставим за скобками вообще их необходимость по версии сопровождающих).

Нет какого-то способа положить в какое-нибудь условное ./conf.d мои настройки запуска этого сервиса?

апстримное ядро тоже будет подмято под systemd-boot

гугл, которому системда в ведре нафиг не уперлась, быстренько разомнет его обратно.

юнитам можно (и нужно) писать override-ы в /etc/systemd, а не лазить в устанавливаемые менеджером пакетов файлы.

Проверил. Работает. Красота. Спасибо.

$ cat /etc/systemd/system/postgresql.service.d/override.conf
[Service]
ProtectHome=false

гугл, которому системда в ведре нафиг не уперлась, быстренько разомнет его обратно.

Я про бинарную форму, которая ясное дело к Google не имеет никакого отношения. В данном случае апстримом для дивана служит ядро Debian. То, что из исходников можно будет собрать классику - я не отрицал, и даже наоборот утверждал это. Вопрос в том, хватит ли на это клешней у диванов, потому что силенок-то у них явно не как у альта, кальки, редоса, слакваря и Gentoo. Это уровень минта, не более. Еще вопрос кстати, что с ним будет, учитывая что скоро убунта оснапится. Тоже предстоит самостоятельно везти весь дистрибутив.

А у нас тут на минуточку, сайт и разговор на этом сайте про свободное ПО. Где вообще-то, возможность форкать тот или иной продукт, в том числе дистрибутив — это не «отмораживание ушей», а фундаментальное достоинство, один из принципов, по которым это самое свободное ПО функционирует. Но нет. Надо найти «маму» и ревностно высмеивать всех, кто с «мамой» не согласен

Это к чему было сказано? Как это отменяет тот факт, что разработчики девуана – недоумки, неспособные мирится с тем, что они оказались в меньшинстве?

Именно для этого они героичиски очищают свой дистрибутив от всего, что связанно с systemd? Вместо того, чтобы остаться в проекте Debian и собирать собственные установочные образы с тем инитом, который им больше нравится?

Это к чему было сказано? Как это отменяет тот факт, что разработчики девуана – недоумки, неспособные мирится с тем, что они оказались в меньшинстве?

Более того, неспособны даже будучи сами в этом самом меньшинстве отвечать за свой же базар.

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

systemd – монструозная херовина, взявшая на себя уже много больше, чем удобную загрузку, что не есть хорошо. Так что её отторжение понятно

Это ложь. systemd зависит только от journald и udev. Компоненты вроде systemd-networkd не являются частью инита и могут использоватся отдельно.

Альтернатива

Груда кривых скриптов на баше – это не альтернатива. Это дерьмо.

Потеряет завтра Леннарт Поттеринг интерес к своему монстру, Red Hat не найдёт или не захочет находить ему замену, и склеит ласты systemd

Лол. Поттерниг давно не является единственным разработчиком systemd.

Gangstalker, просто Санёк когда-то потерял букву. Вообще «targeted individuals»/«жертвы психотроники» довольно распространённое явление вследствие сраных «гражданских прав» и запрета на принудительное лечение; иногда ещё и недоступности медицины, как в Бангладеш или США.

Причины эти, естественно, косвенные - первопричина такова, что чем больше свободно гуляющих шизиков, тем больше оппозиционеров они могут записать в психи и «конспирологи».

Если бы. Мы получаем некий комбайн, куда «завезли» уже и текстовый редактор, и шелл, и гипервизор, если я правильно понял, и загрузчик, а вот удобной системы инициализации мы не получили

Хватит повторять тупые мантры.

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

systemd-analyze

На разработчиках девуана-то отыгрываться зачем?

Затем, что обличение рептилоидов будущими разработчиками - краеугольный камень всего проекта.

Systemd позволяет выстроить сложную иерархию сервисов

Вы понимаете, что пишете совершенно о другом, нежели я? Иерархия сервисов перпендикулярна необходимости предстартовой настройки конкретного «демона».

systemctl status

Вообще-то он показывает запущенные и работающие сервисы и ПРОГРАММЫ и вовсе не в порядке их запуска при загрузки системы.

А в лог лезть и читать целую портянку сообщений, вместо того, чтобы пробежаться глазами по каталогу /etc/rc*.d …

systemd зависит только от journald и udev.

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

Вопрос: почему systemd отслеживает, какие приложения запустил пользователь? Т.е. это уже не система инициализации, которая запустила все указанные демоны и завершила работу, отдав «полномочия» init-у.

Не спорю, что это удобно для наблюдения за системой и поиском, что пошло не так, но если что-то не так будет в самой systemd? Ведь чем больше прога, тем больше там может быть багов, невнятного поведения, нештатной работы в нештатных ситуациях и т.д.

Если ломалась какая-нибудь sysV, это (а) не влияло на запуск пользовательских приложения, (б) любой демон можно было запустить/остановить вручную sh-скриптом. Чё делать, если поломается systemd? Ну, чисто из-за сбойного кластера на диске? Ведь sh-портянок как бы нет, а юнит без systemd бесполезен?

Т.е. это уже не система инициализации

Доброе утро, долго спал. systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1 and starts the rest of the system

Дарагой, так я это в ответ на «systemd – система инициализации, а не монструозный комбайн, берущий на себя всё больше обязанностей».

Ждём, когда GNU/Lunux превратится в M$/systemd.

Выходит что создание аналога Debian - не такая уж и тяжелая задача.

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

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

Нет, это Вы не про то подумали. Я говорил о другом. Речь шла о ситуации, когда нет Debian. Вот совсем его нет. Есть только git-ы различных проектов и все. Больше ничего. Совсем ничего. И собрать нужно совсем с нуля, да прям как LFS. Даже Portage и того нет. Даже ядро в этом случае будет кастомным, а не стоком. Я не думаю, что Вы собирайте кастомное ядро. Или все-таки собирайте?

В каким-то смысле это (следование в канве идеологии дистра) может быть сложнее, чем LFS собирать. Параллельно разрабатываемое терминальное решение (прошивки для сетевых бездисковых устройств), не основанное ни на каком дистре, сильно проще развивать - а там как раз чистый git.

В каким-то смысле это (следование в канве идеологии дистра) может быть сложнее, чем LFS собирать.

Не-а. Это очень сильно упрощает работу, крайне сильно, перекладывая ряд решений на материнский дистрибутив. А в случае с LFS или и вовсе из чистого гита - все решения принимаются непосредственно автором этого изделия и никем больше. Но зато у самоуправления есть и значительное преимущество - решения не зависят от материнского дистрибутива совсем. Соответственно, есть возможность заниматься своим кейсом при разработке столько, сколько в этом есть необходимости и значимости, а не подчиняться каким-то сверху умным дядям. Devuan тот же даже установщик Debian-Installer использует, хотя им пора от него уходить, учитывая вышеописанную новость на свой собственный и сделать даже революцию в мире поддержки MBR-систем: устанавливать их в режиме UEFI на компьютеры с BIOS.

Параллельно разрабатываемое терминальное решение (прошивки для сетевых бездисковых устройств), не основанное ни на каком дистре, сильно проще развивать - а там как раз чистый git.

Если в кейсах чем меньше умеет, тем лучше - да, это значительно проще, поскольку ряд вещей можно выкинуть совсем на мороз.

Одна определенная компания (в которой разрабатывают системд) решила сделать так, чтобы Линукс на подобии новой винды не загружался на компах с MBR. Ну то есть, речь идет о старых компах. Вот и все. Бизнес, и ничего личного. Скорость загрузки, с самого начала - аргумент для наивных, которые всерьез полагают, что несколько секунд разницы во времени загрузки - это то, ради чего делался системд. Ну или там мнимая безопасность загрузки, потому что простому пользовтелю она нужна точно так же как GPT таблица разделов (то есть, не нужна совсем).

На фоне всего этого дистры без Системд имеют особую ценность, потому что теперь речь будет идти не только о принципальном неиспользовании системд, но еще и о возможности запустить Линукс на компах с MBR.

Зачем вообще нужен загрузчик? UEFI без загрузчика все грузить умеет.

Хорошее дело, одобряю.

В OpenSUSE Tumbleweed (пока в качестве опции) вводится поддержка загрузчика systemd-boot как альтернативы GNU GRUB.

Зачем вы постите новости трехлетней выдержки?

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

Вы всё-таки нашли бабушкину заначку мухоморов?

Загрузчик - часть systemd

Значит его уберут из Devuan?

И в mbr, в отличие от grub он не умеет от слова совсем.

Но ведь есть и другие загрузчики? Ты сам упоминал даже такой, который умеет грузить UEFI ядра из legacy BIOS?

Про один из них я уже сказал: забыть дорогу к Debian. Совсем забыть.

Зачем? Одна из главных фич Devuan - это почти полная совместимость с Debian. Без неё он бы мамо кому был нужен из его пользователей.

Есть и другие релизные дистры без systemd: Alpine и Slackware.

Только вот силенок-то у них на это хватит?

Ты всё время пытаешься мериться силами. Штангист наверно?

Devuan - это как по умному с минимальными затратами, а не с нуля, как некоторые.

А тренды таковы: Systemd-Boot станет по умолчанию, и его надо будет в Devuan либо отодрать, либо признать.

И тебя признать с Альтом заодним?

Фсё! Хватит это терпеть! Devuan переходит на Альт!

Ты не грузишь сервер из него - ты собираешь вещички под надзором СБ и топаешь на улицу, провожаемый бодрым пинком под задницу ! :)

Странно, почему пинка не дают в таком случае как раз службе псевдобезопасности. Разве не она отвечает за защищённость от вирусов и троянов?

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

Так почти любой дистрибутив заправляет своей внутренней политикой, кроме совсем уж денискиных.

Downstream дистрибутив при желании может поменять СВОЮ политику, переключившись на Slackware или Alpine.

Или добавить пачку DevOps пайплайнов, которые будут выпиливать лишнее из апстрима.

Еще раз: задача не только в том, чтобы вырезать загрузчик. А еще и собрать кастомное ядро, которое будет работать не как EFI-приложение. Вот где будет самое интересное.

Поменять один флаг настроек? Это так сложно!

И дистрибутив, который всегда это делал, явно это сделает лучше из-за опыта работы.

Пересборка готового ядра в 2024 году - это не задача уровня первоклассника начальной школы?

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

Ещё раз, downstream дистрибутив может достаточно сильно менять то, что приходит ему на вход, не меньше, чем и самостоятельный дистрибутив. При желании может даже автоматизировать перепаковку DEB в RPM внезапно.

И ничего, помещается этот винигрет в его черепную коробку прекрасно!

В твою не помещается, что софтовый рубильник легче вырезать из уже готовой open-source системы, чем создать её с нуля? Почему Libreboot меняют на готовых матплатах, а не собирают свои матплаты с нуля (как оригинальные спектрумы)? Хотя BIOS даже не open-source в отличии от большинства дистрибутивов Linux.

Как там помыкают калькой, гентой и слакварем? Успешно?

Много пакетов переделали гента со слакварью?

Калька - это разве не калька с Gentoo?

Что видно на примере Mint,

А он хотел бы?

который не стал ввязываться в Systemd-бойню.

Это уже прямо так брутально?

Вопрос в том, хватит ли на это клешней у диванов, потому что силенок-то у них явно не как у альта, кальки, редоса, слакваря и

Сколько разработчиков у Slackware и сколько у Devuan?

И насколько отличаются решаемые задачи?

просто Санёк когда-то потерял букву.

Произношение ng в школе проходили? Посмотри транскрипцию в словаре хотя бы.

Подтверждаю. Наша контора свой вариант Дебиана собирает.

Астру или конкурирующий дистрибутив?

Любой, кто имеет десяток-другой девопсов-программистов может это сделать.

Для свободного проекта это был бы довольно серьёзный уровень.