Создание юнита rc.local для systemd

Оригинал: https://www.redhat.com/en/blog/replacing-rclocal-systemd 

От переводчика: Автор статьи, безусловно, шарит в теме, но она написана в 2019 году и с тех пор кое-что поменялось, так что описанный здесь метод отчасти некорректен. Читайте примечание в самом тексте, я там всё объясню.

****************************************************************

У меня недавно возникли две разные проблемы на двух хостах под управлением Линукс. Они требуют разных решений, но одним способом: надо запустить команду во время или сразу после загрузки системы.

Файл rc.local был — и в ряде случаев остается — местом, куда сисадмины прописывают команды, которые должны выполняться во время загрузки. Использование этого файла не просто устарело — я за два часа попыток не смог заставить его работать. Это несмотря на то, что в документации к systemd упоминается "генератор", который создает сервисы systemd из файла rc.local, если он существует (похоже, это не худший способ заставить прекратить чем-то пользоваться — сделать так, чтобы не работало).

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

    Разница между boot (аппаратная загрузка) и startup (запуск операционной системы)

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

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

    1. BIOS Power-On Self-Test (POST) 
    2. Загрузчик (GRUB)
    3. Ядро
    4. Система инициализации (systemd)

Детальное описание обеих последовательностей загрузки вы можете найти в моей статье «Знакомство с процессами загрузки компьютера и запуска Линукс»: https://opensource.com/article/17/2/linux-boot-and-startup

    Локальные загрузочные скрипты

Иногда сисадмины добавляют в процесс загрузки системы команды для конкретной машины - например, для локального запуска процессов, не входящих в стандартную процедуру загрузки systemd. Можно создать сервисы systemd для каждой программы, которую вы хотите запускать при загрузке, но традиционный файл rc.local давал возможность прописать их все в одном исполняемом файле. В systemd тоже можно применить этот подход и поместить все команды в один файл. Это изящное решение упрощает последующее добавление новых команд, не требуя при этом создавать юниты для каждой.

Оно заключается в том, чтобы создать один сервис для systemd, а все необходимые команды поместить в исполняемый файл. Задача состоит из двух частей: очевидно, что первым делом надо создать сам исполняемый файл. Вторая часть - написание сервисного модуля (юнита) для systemd, который будет запускать этот файл.

      Создание исполняемого файла

Для сисадмина, знакомого с написанием bash-скриптов, это тривиальная задача. По сути мы напишем скрипт на баше и поместим его в каталог, который в соответствии с  Linux Filesystem Hierarchical Standard (FHS) предназначен для локальных бинарников - это /usr/local/bin. Можно возразить, что лучше поместить его в другой каталог, но я считаю, что логичней всего именно /usr/local/bin, так как в этом случае админу будет проще запускать его из командной строки при необходимости: этот каталог присутствует в переменной $PATH любого пользователя, включая рута. 

Создайте файл mystartup.sh с содержанием, указанным ниже, поместите его в /usr/local/bin и не забудьте сделать исполняемым. Путь к bash должен соответствовать вашему дистрибутиву. Например, в форках Дебиана путь будет /bin/bash.


#!/usr/bin/bash

################################################################################
# mystartup.sh
#
# This shell program is for testing a startup like rc.local using systemd.
# By David Both
# Licensed under GPL V2
#
################################################################################

# This program should be placed in /usr/local/bin

################################################################################
# This is a test entry

echo `date +%F" "%T` "Startup worked" >> /root/mystartup.log


Запустите эту программу из командной строки. После первого исполнения в каталоге /root должен появиться файл mystartup.log с датой и временем, а также с сообщением: "Startup worked". После создания лог-файла туда будут добавляться строки при каждом выполнении скрипта, чтобы вы могли убедиться, что он работает.

Запустите скрипт еще несколько раз. В результате должно получиться что-то вроде этого:


[root@testvm1 ~]#  mystartup.sh

[root@testvm1 ~]#  cat mystartup.log

2019-09-12 19:58:00 Startup worked

2019-09-12 19:58:17 Startup worked

2019-09-12 19:58:54 Startup worked

2019-09-12 19:59:00 Startup worked

2019-09-12 20:01:08 Startup worked

2019-09-12 20:04:01 Startup worked

2019-09-12 20:04:13 Startup worked

2019-09-12 20:06:11 Startup worked

2019-09-12 20:06:28 Startup worked

2019-09-16 09:51:21 Startup worked

2019-09-16 09:51:51 Startup worked


Теперь в файл mystartup.sh можно добавлять нужные вам при загрузке команды.

      Создание сервиса systemd

Сейчас мы создадим стандартный модуль службы systemd. Файл будет простой - он нужен только для того, чтобы скрипт mystartup.sh запускался при загрузке ОС. 

Создайте файл /usr/local/lib/systemd/system/mystartup.service со следующим содержимым:

################################################################################
# mystartup.service
#
# This service unit is for testing my systemd startup service
# By David Both
# Licensed under GPL V2
#
################################################################################
# This program should be placed in /usr/local/lib/systemd/system/.
# Create a symlink to it from the /etc/systemd/system directory.
################################################################################

[Unit]

Description=Runs /usr/local/bin/mystartup.sh

  
[Service]

ExecStart=/usr/local/bin/mystartup.sh


[Install]

WantedBy=multi-user.target


Делать его исполняемым не надо. Можно было бы поместить его и в /etc/systemd/system, но, поскольку он локальный, лучше в /usr/local.

* Примечание переводчика: дальше автор предлагает создать символьную ссылку на этот файл в каталоге /etc/systemd/system, но если вы это сделаете, то systemd пошлет вас на три буквы при попытке выполнить скрипт. На данный момент (сентябрь 2026 г.) надо выполнить команду типа systemctl enable mystartup (или, возможно, указать полный путь к скрипту). Тогда systemd сам создаст необходимую ссылку и добавит сервис в автозагрузку.

Если вы хотите запускать команды сразу после инициализации ядра (например, чтобы остановить парковку голов hdd),   то в строке WantedBy=multi-user.target надо прописать другой уровень: WantedBy=basic.target

      Протестируем сервис

Прежде чем перезагрузиться и проверить результат, протестируем юнит. Для начала убедимся, что systemd видит сервис:


[root@testvm1 ~]#  systemctl status mystartup

● mystartup.service - Runs /usr/local/bin/mystartup.sh

Loaded: loaded (/usr/local/lib/systemd/system/mystartup.service; linked; vendor preset: disabled)

Active: inactive (dead)

[root@testvm1 ~]#


Судя по выводу команды, юнит был распознан. Теперь давайте запустим сервис. Команда systemctl start запускает скрипт, но не добавляет сервис в автозагрузку

[root@testvm1 ~]#  systemctl start mystartup


Теперь загляните в лог-файл и проверьте, появилась ли там новая строка.

       Добавление сервиса в автозагрузку

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


[root@testvm1 ~]#  systemctl enable mystartup

Created symlink /etc/systemd/system/multi-user.target.wants/mystartup.service →

/usr/local/lib/systemd/system/mystartup.service.

[root@testvm1 ~]#

        Заключительный тест

До перезагрузки давайте посмотрим, как можно использовать команду journalctl для просмотра только той части журнала, которая касается mystartup.service. Также эту команду можно использовать для проверки работы скрипта, поскольку systemd логирует все свои действия. 

Следующая команда с параметром -u показывает только строки журнала, относящиеся к юниту mystartup:


[root@testvm1 ~]#  journalctl -u mystartup

-- Logs begin at Mon 2019-04-15 22:50:27 EDT, end at Mon 2019-09-16 11:44:30 EDT. --

Sep 16 11:09:28 testvm1 systemd[1]: Started Runs /usr/local/bin/mystartup.sh.

[root@testvm1 ~]#



Теперь давайте перезагрузимся и проверим логи:



[root@testvm1 ~]#  systemctl status mystartup

● mystartup.service - Runs /usr/local/bin/mystartup.sh

Loaded: loaded (/usr/local/lib/systemd/system/mystartup.service; enabled; vendor preset: disabled)

Active: inactive (dead) since Mon 2019-09-16 11:45:59 EDT; 1min 30s ago

Process: 819 ExecStart=/usr/local/bin/mystartup.sh (code=exited, status=0/SUCCESS)

Main PID: 819 (code=exited, status=0/SUCCESS)


Sep 16 11:45:55 testvm1 systemd[1]: Started Runs /usr/local/bin/mystartup.sh.

[root@testvm1 ~]#  journalctl -u mystartup

-- Logs begin at Mon 2019-04-15 22:50:27 EDT, end at Mon 2019-09-16 11:47:45 EDT. --

Sep 16 11:09:28 testvm1 systemd[1]: Started Runs /usr/local/bin/mystartup.sh.

-- Reboot --

Sep 16 11:45:55 testvm1 systemd[1]: Started Runs /usr/local/bin/mystartup.sh.

[root@testvm1 ~]#

         Заключение

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

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

UPD: вскоре после публикации этой статьи я получил на электронную почту сообщение от Тома Мерфи. Он рассказал, что в самом systemd существует сервис rc-local. Я благодарен ему за письмо, так как не знал об этом.

Поддержку традиционного rc.local можно осуществить командой systemctl enable rc-local. Перечисленные в файле rc.local команды выполнятся при следующей загрузке. Разумеется, этой же командой можно запустить rc.local немедленно.

Тем не менее, rc.local по-прежнему остается устаревшим. Вот что написано в мануале для  systemd-rc-local-generator: «Поддержка /etc/rc.local сохранена только для совместимости с некоторыми системами на System V. На сегодняшний день мы настоятельно не рекомендуем пользоваться этим скриптом. Вместо этого следует создавать соответствующие юниты с нужными зависимостями для каждого скрипта, который должен запускаться при старте системы».

    ОТ ПЕРЕВОДЧИКА: Я выкладываю эти статьи прежде всего для тех, кто пытается приспособить линукс для домашнего использования, поэтому на всякий случай резюмирую по шагам:
    1. Создать скрипт и поместить его в /usr/local/bin. Приведенный в статье скрипт удобен тем, что дает возможность проверить его работу, но после заключительной проверки я бы на вашем месте закомментировала эту строку, особенно если у вас SSD.
    2. Написать юнит и положить его в /usr/local/lib/systemd/system/. На самом деле дома можно сразу кидать в /etc/systemd/system, но если хотите цивильно по правилам, то надо в /usr/local.  
    3, Если вы поместили юнит в /etc, можете сначала запустить юнит командой start, как написано в статье. Если поместили в /usr/local, то надо запускать командой systemctl enable servicename. Ссылку создавать вообще не надо.

        Использованные ресурсы:

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

        Linux Filesystem Hierarchical Standard (FHS):  http://www.linux-databook.info/?page_id=2609

        https://en.wikipedia.org/wiki/GNU_GRUB

        https://www.gnu.org/savannah-checkouts/gnu/grub/manual/grub/grub.html

        https://en.wikipedia.org/wiki/Master_boot_record

        https://en.wikipedia.org/wiki/Multiboot_specification

        https://en.wikipedia.org/wiki/Systemd    

        Systemd bootup process: https://www.freedesktop.org/software/systemd/man/latest/bootup.html?__goaway_challenge=meta-refresh&__goaway_id=d2d3dc1830f49b19c195b6a9b4bce98c&__goaway_referer=https%3A%2F%2Fwww.redhat.com%2F
        List all manpages from the systemd project: https://www.freedesktop.org/software/systemd/man/latest/index.html

        An introduction to the Linux boot and startup processes: https://opensource.com/article/17/2/linux-boot-and-startup?extIdCarryOver=true&sc_cid=RHCTG0180000382526

Решение проблемы со спящим режимом на HP Probook

 У меня большая радость в личной жизни: я разобралась со спящим режимом. Краткая предыстория: у меня на ноуте hp probook с прошивкой uefi под линуксом есть проблема, о которой я читала много раз в блогах (например, блог дебиана, арча и LQ). Точнее, даже две проблемы, которые, судя по сообщениям в блогах, часто приходят вместе: 

1. Ноут зависает в простое. Экран гаснет и аппарат перестает реагировать на любые тычки клавиатуры, мыши и тачпада, кроме долгого нажатия на power. Но в моем случае это фигня, я просто запускаю screensaver и он может простаивать как угодно долго. Кстати, фризится он у меня только на дебиан, а на слаке вместо этого перезагружается.

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

Я сразу подозревала, что причина в сетевом стеке (точнее, видимо, в его взаимодействии с прошивкой, потому что на ноутах с bios всё работает), но не сразу поняла, как отключить ВСЁ: я то забывала про хрони, то ждала слишком мало.

РЕШЕНИЕ для Slackware 15.0 и для Debian 13 у меня отличается, поскольку дебиан установлен через debootstrap и там нет нетворкменеджера и тому подобного, а в слаке есть.

1. Slackware

bluetooth отключен через rfkill в rc.local; NetworkManager перед саспендом надо остановить - /etc/rc.d/rc.networkmanager stop. Сетевые приложения типа браузера я перед этим закрываю. Ещё был подлый ModemManager, который невозможно было убить командой kill, так как он сразу запускался заново. Сносить его я не стала, потому что однажды попыталась удалить wayland, которым все равно не пользуюсь, после чего перестал запускаться... FIREFOX. Короче, я просто сняла с его бинарника бит исполнения: chmod -x /usr/sbin/ModemManager  Еще приходится останавливать chronyd через kill -s 15 или killall. 

А теперь неочевидная часть: после этого надо еще несколько минут подождать (я раньше пыталась, но, видимо, мало ждала. В слаке надо ждать дольше, чем в дебиане), и тогда suspend работает на ура как через /sys/power/state,  так и через loginctl suspend.

2. Debian

Блютус отключен. Закрываю браузер, останавливаю wpa_supplicant (например, через команду terminate в wpa_cli) или dhcpcd для проводной сети (dhcpcd -x ifname). Chrony здесь можно не останавливать - без сети он сам отключается. Тоже надо подождать пару минут, потом systemctl suspend.

МОЙ ОЧЕРЕДНОЙ ДИСТРОХОП, ОТЗЫВ О Debian 13.5, ТЕКУЩАЯ СИТУАЦИЯ В ЛАГЕРЕ Линукс.

 У меня уже есть несколько постов про ноут HP Probook 430 G3, на котором спящий режим работает в slackware-15.0 stable через задницу. Одно время проблема вроде как решилась отключением elogind, но продлилось это несколько дней, потом опять он перестал уходить в suspend-to-RAM нормально - ну то есть уходил рандомно, а чаще не уходил. Архитектура процессора skylake, прошивка uefi, и это, видимо, роляет, потому что на старом компаке с bios та же система работает как часы. Memtest ничего не показал, хотя бывает, что память битая, а он не видит. В мануале к ноуту написано, что он поддерживает линукс, ОСОБЕННО убунту какой-то древней версии. К убунту я была морально не готова, поэтому решила попробовать дебиан. Ну мало ли - вдруг systemd будет работать лучше. Хотя я сомневалась, потому что на серверах спящего режима нет и корпораты вряд ли особо стараются его поддерживать. Но зато у дебиана поддержка чуть ли не 10 лет и репозиторий понасыщенней, чем EPEL и ELREPO.  

    ● Что там с другими линуксами, в том числе без systemd?

В клонах EL мало пакетов - то, чего нет в EPEL, надо дергать из Федоры, а зачем, если есть другие дистры. Кстати, Федора дропнула поддержку X11 и полностью перешла на wayland.

Моим первым дистром был Open Suse, и я сначала глянула, как там дела. На ЛОРе как раз была тема про новый релиз Leap-16. Отзывы о нем выглядели примерно так: просрали все полимеры, руки поотрывать и т.п. Короче, там теперь новый установщик, а панель администрирования yast разделили на две части: одна для пакетного менеджера, вторая для остального. На Reddit тоже были англоязычные отзывы, и там народ был недоволен, что из панели убрали некоторые функции и теперь придется руками править конфиги. Зато и установщик, и панели имеют веб-морду (первый, вроде как, на базе firefox). В общем, я поняла, что туда сейчас лучше не соваться, потому что сама свалила с сусе как раз в момент, когда они уходили от Novell и пилили свой первый Leap. До этого всё было прекрасно (хотя я допиливала его руками, но меня это никогда не пугало), а потом версии стали одна стремнее другой и я не выдержала.

Без системГэ я знаю один неплохой дистр - год назад там не было никаких elogind и вроде даже pam. Пожалуй, это единственный дистр на sysV, кроме слаки, который не считается маргинальным, так как популярен в Штатах - это PCLinux, форк Мандрейка. Роллинг, но когда я имела с ним дело (в течение пары лет), он был очень стабильным. Он стоял у моей матери, но она там кое-что нахеровертила и убила систему. Так как я сама пользовалась слакой, то и ей поставила, чтобы глаза не разбегались лишний раз. В принципе, когда я в последний раз ставила слаку, то рассматривала его, но там, во-первых, очень мало пакетов в репозитории (раньше было больше). На самом деле в слаке их тоже мало, но там можно подключить реп бинарно совместимого с ней Salix Os, а для остального есть слакбилды. Есть, кстати, еще slackonly, но из него можно ставить только в ближайшее время после выхода релиза, пакеты там не обновляются. Но зато, как и реп Salix, он тоже не васянский, в отличие от AUR и подобных. Во-вторых, его тоже пришлось бы допиливать: кроме правок конфигов, которые у меня уже есть на флешке, мне пришлось бы сносить displaymanager, переводить sysv в другой ранлевел (там уровни отличаются от sysv в слаке), ставить fluxbox и все такое, чего в слаке делать не надо. Но я все же посмотрела в эту сторону и узнала, что у главного разработчика PCLOS Билла уже больше десяти лет рак. Я даже увидела его давний пост, где он пишет, что, мол, "cancer is kicking my ass". Там, конечно, есть сообщество, но я так поняла, что основной план такой: если Билл вдруг отъедет, то вместо нынешнего дистра будет PCLinux debian edition. А там вообще изначально пакетник был rpm, но в качестве морды к нему apt и synaptic. Потом они пробовали редхатовский dnf, но я не в курсе, как он у них прижился.   

А, есть же еще отечественные операционные системы. Вот, например, Alt Linux, который похож на PCLOS тем, что там тоже rpm, apt и synaptic. На его эмблеме один пингвин сосет у другого, и это неспроста. Помню, когда я еще пользовалась XFCE, то полезла гуглить какую-то проблему и наткнулась на форум альта. Там пользователь задал вопрос, а ему ответили вот так: "Потому что пользователи gtk должны страдать". При этом у них была официальная сборка с XFCE. Это всё, что мне надо было знать об Alt Linux.

Void и Crux я уже пробовала, но как-то не зашло (в войде musl тогда работал хреново, в Круксе надо собирать руками слишком много, нафига мне этот менингит), так что решила для начала поставить дебиан, стабильности которого фанаты поют дифирамбы. Тем более, что версии пакетов в stable там уже не старше, чем сейчас в слаке, а ядро даже новее. 

    ● Debian

Сначала я записала образ на флешку, но он при установке потребовал вставить диск. Я заподозрила, что флешкой что-то не то, записала еще раз, после чего ноут перестал ее видеть. Да и х** с ней, подумала я и поставила систему через debootdstrap.  

Всё встало, я перешла в chroot, установила ядро, нужные прошивки, dhcpcd, ещё там что-то типа util-linux и загрузилась в новую ось через GRUB, который уже стоял в слаке и распознал дебиан. Дебиан встретил меня поросячьим визгом спикера прямо в консоли - такого я никогда не видела. Я решила разобраться с этим позже и поковырялась в системе, обнаружив, что надо еще ставить pciutils, usbutils и всё такое. Короче, при установке через deboostrap ставить придется всё, кроме apt. Вместо sudo я пользуюсь su. Так вот, в слаке su сконфигурирован так, что если вы даете команду "su", то подразумевается "su -". В дебиане это не так и после su вы не сможете просто выполнять команды, лежащие в /sbin или /usr/sbin, по названию без полного пути. Я пару раз успешно перевела ноут в спящий режим через systemctl и стала ковыряться дальше.

Накатила иксы и fluxbox, firefox (там два браузера - firefox и chromium, как и в последней слаке. Всяких slimjet и opera в репозиториях больше нет), и полезла смотреть, что за херня со спикером (он продолжал визжать в терминале sakura). Оказывается, это не баг, а фича, и если вы хотите заткнуть фонтан, там предлагается отредактировать файл inputrc, а если не поможет, то просто удалить драйвер для спикера. Охеренно придумано,конечно, но я потом отключила его через xset -b, а для консоли просто убавила звук в пульсе. Не могу не упомянуть, что загружается он дольше, чем слака, хотя именно ускорение загрузки позиционировалось когда-то главной целью Гэ.

А, сначала же я подняла сеть. Я не стала ставить NM и мне было лень разбираться с их скриптами, поэтому, чтобы пользоваться беспроводной картой, я просто поставила wpa-supplicant и подняла сеть в первый раз через wpa_cli. Проводная работает через dhcpcd. Net-tools искаропки там нет (а в слаке есть), так что запомните: ip addr show; ip link set XXXX up.

Дальше был gkrellm. Я увидела в репозитории плагин gxkb для него и на радостях установила, но он не отображался. Так же, как и в слаке, при попытке сменить тему во fluxbox иксы иногда падают. А хотите узнать дистрибутив, где не падают и gkrellm-gxkb отображается? Пожалуйста: freebsd. Я в курсе, что там могут отваливаться беспроводные карты, но по какой-то иронии судьбы на моих ноутах именно во фряхе сеть работала лучше всего. Но там другие загоны с вращением вентилятора. Более того, в дебиане как-то раз у меня из gkrellm исчез индикатор батареи. Я заглянула в настройки, там галка стоит - батарея, что ли, внезапно сдохла? Ну просто если исчезает индикатор сети, значит, сеть отвалилась. А, нет, батарея целая, после перезапуска gkrellm индикатор появился. Н-да. 

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

Как я и подозревала, через какое-то время начались проблемы со сном. Кстати, в Дебиане есть пакет pm-utils, которого, я думаю, уже больше нет нигде. Похоже, некоторые его майнтейнеры достигли просветления. В отличие от SUSE, где sysV больше не поддерживается, в дебиане еще как поддерживается и, более того, в их вики написано, что если раньше удаление Гэ вызывало проблемы, то теперь без него будет работать и гном, и все остальное. Я нашла проблему с systemd в системном журнале. journalctl умилил меня тем, что урезал вывод. Ну типа если проматывать стрелочкой наверх, то вы увидите всё, но это займет некоторое время. Чтобы такой херни не было, надо делать так: journalctl --no-pager|less. Честно говоря, less /var/log/messages мне нравится больше. Конфиг systemd я исправила, как было написано в каком-то unixforum или типа того, но, как обычно, эффекта хватило не надолго.

Решила я обновиться. но apt начал ругаться на реп обновлений безопасности, указанный в конфиге по умолчанию. Короче, там есть ещё cdn-fastly. Соответствующую строчку я заменила на это:

deb http://cdn-fastly.deb.debian.org/debian-security stable-security main

и все заработало. Обновлений было немного. В слаке мне еще нравится один нюанс: там пакетов мало, но они большие, что весьма полезно для ssd. В дебиан, в принципе, тоже по сравнению с PCLOS или, тем более, Open SUSE с этим весьма неплохо. Например, qpdfview хоть и не один пакет, как в слаке, но два, это тоже немного.

    ● Впечатление от системы

Честно говоря, тем, что все работает и не ломается при обновлениях, после десяти лет на slackware stable меня не удивишь. Кроеме того, не надо забывать, как я поставила систему. Если бы установка была из нормального образа, то телодвижений было бы гораздо меньше, а может, и работало бы что-то лучше. Общее впечатление вкратце такое: для домашнего использования слака и даже фряха приспособлены лучше. Дебиан всё же серверный.  Systemd, на мой взгляд, дома не нужен, так как плодит сущности, которые не факт, что вам нужны, и проявляет самостоятельность. В продакшене он удобен тем, что сразу подхватывает сервисы и не надо лишний раз ковырять конфиги руками. Например, chrony интегрирован в systemd. В слаке он ставится либо из слакбилда, либо из репы саликса. Но там надо руками создать группу и пользователя chrony и самому его запустить. В Дебиане ставишь его через apt, группа и юзер создаются сами, демон запускается и автоматически оказывается в автозагрузке (даже если вы не планировали запускать его прямо сейчас и ставить в автозагрузку).

Но, сука, как доходит до GUI, все меняется - по крайней мере, для пользователей WM, а не DE. В слаке есть утилита xwmconfig. Я не понимаю людей, которые сидят дома за компом одни и пользуются дисплейменеджером - это же средство контроля доступа, которое будет постоянно висеть в фоне и жрать ресурсы без всякого смысла. Ну вот, в слаке запускаешь xwmconfig (он на ncurses), там в списке все gui, которые там были и которые ты сам устанавливал, тыкаешь пару раз на клавишу и заходишь в нужное окружение. А вот в дебиане есть choosewm, но работает через жопу. В общем, я поставила то, чем обычно пользуюсь: fluxbox и windowmaker. В слаке они запускаются просто через startx, а там надо startx /usr/bin/startfluxbox или startx /usr/libexec/WindowMaker/wmaker - до последнего еще надо додуматься. Fluxbox в слаке сконфигурирован удобней, чем в дебиане, gkrellm не глючит. Но suspend на дебиане работает чаще.

Кроме того, Слака жрет чуть меньше памяти, быстрее загружается. Но в этой версии после обновления были проблемы в виде тормозов при авторизации, которые пропали после другого обновления на Compaq и остались на Probook. Про дебиан ничего не могу сказать, так как пользуюсь им без году неделю. По доступности пакетов  в репозиториях примерно одинаково, но только для меня. В слаке нет, например, гнома, хотя есть репозитории, откуда можно накатить и его, и Гэ, но это все будут телодвижения. При этом практически все производители софта, если он имеет версию под линукс, выкладывают деб-пакет на своих сайтах. У слаки здесь все печальней. А, кстати, в слаке wps-office есть в слакбилдах. Но зато для дебиана есть пакет на офсайте. О том, как я не смогла загрузить нормальный пакет и попользовала китайский wps, расскажу отдельно.

В общем, не могу сказать, что дебиан говно, но слака мне нравится больше. Вот поэтому, сука, я до сих пор на ней и сижу: практика неоднократно показала, что если в ней есть проблема, то это проблема самого ядра или Xorg и т.п., и в другом линуксе она, скорее всего, никуда не денется. Единственное, что раньше в слаке не работал networkmanager, хотя и стоял из коробки, а в других дистрах работал. Но в слаке для этого был wicd. Кроме этого случая, я не могу вспомнить, чтобы где-то было лучше, чем на слаке, а вот хуже лично для меня - это да.
 

Как я чинила спящий режим на hp probook 430-G3: виды режимов сна и управление suspend через интерфейс ядра линукс

 Я уже писала про этот ноут ― там была проблема со спящим режимом на slackware 15.0. После перехода в S2RAM он сразу просыпался, а если выбрать s2ide, то, наоборот, невозможно было его разбудить. Я особо не дёргалась по этому поводу, потому в простое он нагревается где-то до 30-34 градусов, вся периферия уходит в сон, особенно после настройки через powertop, ну и я, честно говоря, была почти уверена, что проблема в прошивке - типа кривых таблиц acpi, - потому что не работает Fn и кнопки отключения wifi и звука. Но всё равно меня подбешивало, поэтому как-то на досуге я решила выяснить, в чем на самом деле проблема. В итоге я выяснила, но спойлерить не буду, а то получится не так захватывающе, как это было для меня.

    1. ВИДЫ РЕЖИМОВ СНА В БОЛЕЕ-МЕНЕЕ СОВРЕМЕННЫХ НОУТБУКАХ

 
● S0 (connected suspend/modern suspend/s2idle) ― это как в планшетах и смартфонах: поддерживается wi-fi соединение, фоновые обновления почты и приложений даже при закрытой крышке.

● S1 (standby/power on suspend) ― состояние сна в acpi, когда CPU прекращает выполнять команды, останавливает тактовые генераторы и сбрасывает кэши, но питание на компоненты, включая RAM, подаётся.

● S2 (standby/shallow) ― промежуточный, встречается редко. Напряжение может подаваться на некоторые компоненты материнской платы.

● S3 (suspend to RAM) - все компоненты обесточены, кроме RAM, где сохраняется состояние системы.

● S4 ― гибернация.

    2. ИНТЕРФЕЙС ЯДРА ДЛЯ УПРАВЛЕНИЯ СПЯЩИМ РЕЖИМОМ ИЗ ПРОСТРАНСТВА ПОЛЬЗОВАТЕЛЯ
    оригинал:    https://www.kernel.org/doc/html/v4.18/admin-guide/pm/sleep-states.html 

Это каталог /sys/power

    ■ Значение файлов и настройка:

● state ― содержит поддерживаемые ядром состояния сна. У меня это были disk (гибернация) и freeze (s2idle). Третье значение mem интерпретируется в зависимости от содержания файла mem_sleep.

● mem_sleep ― содержит доступные режимы сна и позволяет выбрать вариант, который будет ассоциирован с параметром mem из файла /sys/power/state. Ассоциированный параметр будет взят в квадратные скобки. Если ядро не поддерживает сон, этого файла не будет. У меня там было два варианта: deep (s2RAM) и s2idle. На некоторых ACPI-based системах, которые берут информацию из таблиц ACPI, по умолчанию стоит s2idle, даже если поддерживается s2RAM, но обычно последний стоит по умолчанию. Чтобы выставить параметр по умолчанию, можно либо либо использовать 'echo deep > /sys/power/mem_sleep', либо сделать это через параметр ядра "mem_sleep_default", передав его загрузчику.

    ■ Два способа перевести машину в  S2idle

I   echo freeze|sudo tee /sys/power/state

II  echo s2idle|sudo tee /sys/power/mem_sleep
    echo mem|sudo tee /sys/power/state

    ■ Единственный способ перевести в S2RAM 

     echo deep|sudo tee /sys/power/mem_sleep
     echo mem|sudo tee /sys/power/state

Собственно, теперь я так и перевожу ноут в сон.

    3. ПОЧЕМУ НОУБУК САМОПРОИЗВОЛЬНО ВЫХОДИТ ИЗ СНА

Первое, что выдаст вам гугл по этому поводу, файл /proc/acpi/wakeup. Типа надо убрать оттуда лишнее, тогда всё заработает. Надо смотреть на enabled. Это если не смотреть специфичные для слаки решения. На LQ я нашла совет поменять elilo на grub и поставить новое ядро. Короче, теперь у меня grub и ядро 6.12.82, но проблему это не решило. 

Ну вот мой вывод:

bash-5.1# cat /proc/acpi/wakeup |grep en
XHC      S0    *enabled   pci:0000:00:14.0
RP05      S4    *enabled   pci:0000:00:1c.0
PXSX      S4    *enabled   pci:0000:01:00.0
RP06      S4    *enabled   pci:0000:00:1c.5
RP09      S4    *enabled   pci:0000:00:1d.0

Как видите, S3 здесь вообще не фигурирует, а для S0 стоит XHC, это extensible host controller, который управляет usb 3.0/3.1. Между тем ноут просыпается из обоих режимов только по кнопке питания, дёрганье мыши, нажатия на тачпад или встроенную клаву на него не действуют.

Параметр wakeonlan у меня отключен в прошивке, /sys/class/net/wlan0/device/power/wakeup показывает "disable". Тем не менее, я пыталась отключать сеть и ноут действительно переходил в S3, но только один раз. В следующий раз он опять мигал индикатором батареи и просыпался примерно через минуту. Ну и, собственно, в S3 он, похоже, не переходил: экран гас, но кнопки продолжали светиться как обычно, тогда как в s3 кнопка вайфай становится оранжевой, а power начинает мигать.

В качестве GUI у меня fluxbox и windowmaker, то есть никаких своих менеджеров питания, которые сбрасывали бы настройки elogind, нет. В сон я переходила командой loginctl suspend. 

    4. ФОКУСЫ ПИДОРСКОГО elogind

Этот шлак был у меня сконфигурирован вроде правильно в файле /etc/elogind/logind.cong, но оказалось, что у него есть один нюанс - ингибиторы. Это программы, которые не дают машине перейти в сон, пока что-то там не завершат. Вот команда для просмотра ингибиторов, если у вас нет systemd: 

bash-5.1# dbus-send --system --print-reply --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.ListInhibitors

А вот её вывод в первый раз: 

      struct {
         string "sleep"
         string "NetworkManager"
         string "NetworkManager needs to turn off networks"
         string "delay"
         uint32 0
         uint32 1129
      }
      struct {
         string "sleep"
         string "ModemManager"
         string "ModemManager needs to reset devices"
         string "delay"
         uint32 0
         uint32 1216
      }

Я остановила NM, и ноут заснул. Но сделав это во второй раз, получила хрен на блюде. Посмотрев ингибиторы, я увидела, что там добавился ещё Upower. Если убить его командой kill, то ноут опять засыпал,  но в третий раз опять что-то вылезало. Короче, мне надоело это блядство и я просто отключила нахрен elogind, сняв бит x с его скрипта в /etc/rc.d. Кроме того, он влияет на pam ― у меня после одного из обновлений это стало проявляться тормозами при авторизации пользователей как в консоли, так и в терминале GUI. Я обнаружила его, когда смотрела лог авторизации (в слаке это /var/log/secure). Короче, надо ещё сделать так:

bash-5.1# grep elogin /etc/pam.d/*

и закомментировать строчки, содержащие elogind, в файлах, которые вы используете.
Также я установила nologind из репозитория Salix OS, ну типа чтобы нормально работал powerkit, хотя я не уверена, что он был нужен, но мне надоело видеть ошибки и возиться лишний раз. Seatd я ставить не стала, потому что нахрен он нужен, когда в системе два пользователя, и оба ― ты сам.

    ЭПИЛОГ: теперь я выключаю и перезагружаю ноут командой shutdown, а в сон перевожу через описанный выше интерфейс ядра. У меня ничего не тормозит и всё работает, но я опять покосилась в сторону freebsd ― скорее рефлекторно, ведь там со спящим режимом всё ещё хуже и, кроме того, обороты вентилятора хрен настроишь, если модуль wmi не поддерживает твоё железо. Но знаете, я обнаружила, что утилиту ataidle, которая останавливала парковку головок hdd, похоронили, добавив этот функционал в стандартный camcontrol. В общем, если они разберутся с вентиляторами и саспендом и я на тот момент ещё буду жива, то с удовольствием пошлю линукс на три буквы. 

UPD: проблема решена

 описание здесь: https://bjdarticles.blogspot.com/2026/08/hp-probook.html

Отзыв об HP Probook 430 G3, нюансы его прошивки, управление частотой процессора в данном ноуте и вообще в ядре линукс, начиная с 5-й версии.

 Предыстория

У меня перестали реагировать на нажатие некоторые клавиши встроенной клавиатуры на ноуте Asus K-50ip. Оказалось, это частично крякнул мультиконтроллер. Можно было заменить за 3 рубля, но я не стала, потому что там всратый чипсет от nvidia, куда интегрированы северный и южный мосты, а также видеокарта Geforce. Разумеется, всё это греется как утюг и, кроме того, прибито к материнской плате, то есть заменить его можно только с ней. В общем, я решила, что чинить его экономически нецелесообразно.

Пришлось рыскать в поиске вменяемой комиссионки, так как покупать новый ноут сейчас в РФ означает как минимум заплатить неадекватные качеству деньнги, а чаще при этом еще и получить говняное поделие. Подержанный HP, Dell или Acer всяко лучше, чем новый ирбис, прости господи, или китайский шлак. Про подержанный Asus я такого не скажу, потому что там чаще всего плохая система охлаждения, хотя полагаю, что и у них есть удачные модели.

Мои требования, нюансы режима турбо и обновления прошивки

Нашла я один магазин у черта на рогах с нормальными отзывами и каким-то выбором. Мне нужен был ноут на intel без дискретной видеокарты и режима турбо, чтобы не грелся и не выебывался. Просто у моего друга Санька был ноут с турбо - новый HP Elitebook (в 2014-15 году стоил около 100 000). Этот турборежим невозможно было отключить в прошивке: галка была, но если ее поставить, система не загружалась. А когда он был включен, питания от сети не хватало и использовалась батарея. Через пару месяцев после окончания гарантии батарея вздулась. Саня купил новую и, пошарившись в интернетах, решил обновить прошивку, так как в новой версии было умное управление аккумулятором: он не заряжался выше 80% и не разряжался ниже 20. После обновления он получил умное управление зарядом, а также проблему с прокруткой у тачпада (которая была только под линуксом, а не в винде - у него был дуалбут) и, самое хреновое, кулер перестал увеличивать обороты, в результате процессор начал греться в обеих ОС. На сайте HP он узнал, что раньше обновления можно было откатить, но не в этот раз. Техподдержке HP уже кто-то задал такой вопрос и был послан на три буквы. В общем, когда увидите совет обновить прошивку, подумайте десять раз.

Характеристики ноутбука

В итоге я выбрала hp probook, хотя диагональ у него 13,3", всё остальное идеально: проц Pentium 4405U без турбо - 2 ядра/4 потока; 8 ГБ DDR4; встроенная видяха, есть ethernet, три порта usb; SSD на 256 ГБ с нормальным смартом, родная батарея с износом 20%. Заряд держит больше 3-x часов (благодаря ssd, маленькому экрану и тому, что там вентилятор периодически отключается); заряжается быстро - т.е. состояние элементов питания хорошее. В отзывах про него часто поливают дерьмом матрицу, но меня она устроила: яркая и контрастная, цветопередача с уклоном в зелёный (а не в синий или фиолетовый). На матрице несколько тонких полос - отпечатков от клавы, обусловленных тем, что в более-менее новых ноутах нет зазора между экраном и клавой и при регулярном закрытии крышки стирается антибликовое покрытие. Замена матрицы такого размера у нас стоит около 6 косарей (это дёшево), но сервисник сказал, что смысла особо нет, потому что она опять протрётся. 2018 год выпуска, корпоративный сегмент.

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

Вопросы типа есть ли слот для памяти и винта не стоят - там даже процессор BGA.

Нюансы прошивки

Теперь, собственно, о нюансах - они касаются управления частотой процессора и спящего режима. Сразу скажу, что это фокусы прошивки, которую, судя по показаниям /sys/devices/virtual/dmi/id/bios_date, обновили в 2024 году.

Моя операционная система Slackware64 15.0. Клавиши, которые в сочетании с Fn регулируют яркость экрана, громкость и всё такое, на линуксе не работают, да и хрен с ними. Яркость я выставила в rc.local, прописав туда echo 800 > /sys/class/backlight/intel_backlight/brightness. 

Проблема со спящим режимом: если в прошивке поставить галку на пункте, который позволяет процессору снижать частоту, то ноут нормально засыпает только при закрытой крышке (напоминаю, что от постоянного хлопанья крышкой стирается покрытие на матрице, а также перетирается шлейф матрицы). Если крышку не закрыть, то через несколько секунд после засыпания один раз мигает индикатор батареи, ноут выходит из сна и при этом ещё перезагружается. Если галку снять, то процессор будет постоянно молотить на самой высокой частоте (кроме простоя), зато после команды loginctl suspend ноут спит с открытой крышкой. При этом ещё надо снять галку с Deep sleep и Extended idle power states.

Смысл некоторых пунктов прошивки (они описываются в руководстве:  https://kaas.hpcloud.hp.com/pdf-public/pdf_12904670_en-US-1.pdf  Наывается HP PC Commercial BIOS (UEFI) Setup Administration guide)

Меню Advanced, подменю Power Management

1.  Runtime power management - галка, которую надо поставить, чтобы можно было управлять частотой ЦПУ. Без неё он постоянно работает на максимальной. Но если у вас уже выставлен режим powersave через операционную систему, снятие галки ничего не изменит и suspend не получится. 
2.  Extended idle power states - позволяет процессору переходить в более глубокие состояния сна в простое.
3.  Power Control - при поставленной галке ноутбук поддерживает приложения для управления питанием типа APM+ - это прикол корпоративного сегмента, дома она вряд ли нужна.

Настройка частоты процессора в ядре линукс, начиная с 5-й версии. 

Мне надо, чтобы меньше грелось, но при этом не тормозило. Раньше она настраивалась через драйвер acpi-cpufreq или intel_pstate и всё, но теперь, чтобы снизить температуру, сначала надо выставить это, если там стоит "menu" вместо "ladder":

1. echo 'ladder' > /sys/devices/system/cpu/cpuidle/current_governor

2. echo 'fair_share' > /sys/devices/virtual/thermal/thermal_zone#/policy

Здесь # - номер зоны, надо выставить для всех. По умолчанию там step_wise.

Я вычитала это  на LWN... А, нет,  просто заметила, что как-то сильно греется, несмотря на настроенный cpufreq, и посмотрела dmesg. Там обнаружились governor menu и governor step_wise. После этого я нашла их по названию в системе. Капец.  

Дальше уже настройки intelpstate или acpicpufreq (у меня на этом ноуте первое). В cpufreq я пользуюсь регулятором conservative. В intelpstate надо поменять две настройки:

3. echo 'powersave' > /sys/devices/system/cpu/cpufreq/policy#/scaling_governor

После этого можно будет изменить вторую:

4. echo 'balance_power' > /sys/devices/system/cpu/cpufreq/policy#/energy_performance_preference

Честно говоря, я не читала, как работают разные настройки, но  здесь их пять: default,  performance,  balance_performance,  balance_power,  power. Это сильно напоминает cpufreq, и balance_power выглядит как аналог conservative.

Вот показания датчиков без нагрузки и снагрузкой. В комнате 27-28 ℃.

 Итог: 
ноут офигенный, аппаратная часть идеальная, но прошивка малость ёбнутая, хотя бывают случаи похуже. Впрочем, HP и Dell вообще славятся всратыми прошивками.

UPD: Если выставить в прошивке управление батареей "Let HP manage your battery health", то эта гнида будет считать за цикл зарядки, если разрядить ее до 80% и зарядить до 100. Если оставить  "maximize performance", то счетчик не будет увеличиваться, как и должно быть. В общем, надо выбирать или "battery health", или "performance", если не хочешь, чтобы батарея накрылась через месяц. Но health заряжает только до 80%, то есть если его активировать, то не надо подключать ноут к сети, если там больше 80% заряда, иначе контроллер уйдет в защиту. Кто-то держит на 80% постоянно подключенным к сети, я разряжаю до 89% и заряжаю каждый раз, а после использования отключаю. У меня телефонные аккумуляторы в таком режиме живут уже по 16 лет.

UPD2: Я решила проблему со сном, и виновата оказалась не прошивка, а пидорский elogind, который Алиен Боб притащил в систему, чтобы работало его дурацкое КДЕ. Если коротко, я сняла бит исполнения с этого куска дерьма в каталоге /etc/rc.d и закомментировала все строки с elogind в конфигах PAM. Теперь всё работает как часы, команды сна отдаю через интерфейс ядра. Кроме того, что починился suspend, исчезла пауза при авторизации пользователя в системе между вводом логина и пароля -  зря я грешила на pam.

Обновление прошивки на HP Elitebook 840 G5

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

У меня есть друг Санёк. Где-то в 2014-15 году он купил ноут фирмы HP: Elitebook 840 G5 с конфигурацией intel core i5-8250U, 4 ядра по 1.6 GHz с разгоном до 3.4 в режиме турбо. Он тогда стоил около 100 килорублей. Я помню, когда он его только купил, то рассказывал, что с выключенным turbo boost ноут не загружается. Вообще, когда я ещё сидела на винде, то много читала о том, что у HP проблемы с драйверами и прошивкой. Если у вас не винда, проблемы усугубляются, в чем Санёк убедился лично.

Собственно этот turbo boost и стал причиной всей свистопляски. Это интеловская технология: при выполнении задач, не расходующих процессор, он работает с базовой тактовой частотой, а при необходимости одно ядро разгоняется в случае Санька больше чем в 2 раза. Короче, через месяц после окончания гарантийного срока у Саниного ноута вздулась батарея. Оказалось, что он пользовался турбо, а в его старой прошивке не было "умного" управления АКБ - это когда она заряжается до 80% и разряжается до 20%. Режим турбо требует наличия батареи, так как блок питания ноутбука не рассчитан на такую мощность, и поэтому получается, что батарея постоянно слегка разряжается, потом автоматически начинает заряжаться и быстро дохнет из-за большого количества циклов зарядки. 

Купил Саня АКБ русско-китайского производства, вставил её, ноут заработал, но перед загрузкой системы прошивка каждый раз высирала сообщение о том, что "у вас левая батарея, это может повлечь ядерный взрыв и эпидемию чумы". Санька это сообщение разозлило, и он полез на форум HP. Оказалось, что там сидят дебилы типа как в ростелекоме на первой линии: им уже задали этот вопрос, и они ответили, что надо отключить уведомления в винде. Автор вопроса напомнил придуркам, что сообщение появляется до загрузки системы, после чего его просто проигнорили. Саня сказал, что они вообще если встречают вопрос, на который не могут ответить, то шлют на хуй без церемоний.

Тогда Санек решил проявить смелость и обновить прошивку. Нет, он не лох и не чайник, он системный архитектор. Просто никогда раньше не делал этого, решил попробовать (на свою ж...). Он решил делать это из Винды. У него дуалбут: искоробочная Виндос 10 и Генту. Виндой он пользуется только для игр, поэтому три года её не обновлял. Чтобы найти нужную прошивку, он обновил систему, и она затерла ему первичный загрузчик GRUB. Он признался, что у него долго горела жопа: сука, я же не устанавливал её, а только обновил! Так как он занимается этим не каждый день, ему пришлось читать документацию, как записать grub обратно, скачивать system rescue cd и все это делать. Протрахался около двух часов. Это было только начало. Но наконец все было сделано, и винда в опциональных обновлениях предложила ему обновить EFI.

После этой процедуры сообщение о батарее не исчезло, зато тачпад - Саня предпочитает его мыши - стал глючить, пролистывая две страницы вместо одной. Этот глюк проявлялся только в генту, но не в винде. Но это ещё не самое хреновое. Оказалось, что кулер на процессоре перестал разгоняться до полных оборотов. Естественно, чип стал греться как не в себя и в генту, и в винде. Саня решил откатить прошивку назад, но с версии, предшествующей его версии, откат стал невозможен. Он узнал об этом из документации на сайте HP, а не из сообщения, которое должно было его об этом предупредить перед обновлением. Кстати, он очень похвалил официальную документацию на их сайте: сказал, что там черт ногу сломает, хрен разберешься. Тогда он решил обновиться до следующей версии, которую нарыл на сайте. В общем, потрахавшись ещё, он обновился, и там, насколько я помню, как раз оказалось умное управление батареей. Ну хоть что-то.

Поимев секс, Санёк решил проблему с тачпадом, а с вентилятором ничего не вышло. Он попробовал thermald, но тот ему не помог, что в принципе логично - прошивка же не работает, что система может. В результате он просто выставил порог, выше которого частота не должна подниматься, и сидит теперь на обгрызанном процессоре.

Итак, в результате обновления прошивки Саня приобрел умное управление АКБ, которое увеличит срок службы последней, если пользоваться режимом турбо, без которого ноут не загружается. При этом у него перестал раскручиваться на полную мощность вентилятор. Сообщение о левой батарее не исчезло. Также он просрал десять дней своего времени и кучу нервов. Давать оценку результату я предоставлю читателям.

Процесс загрузки FreeBSD

 Оригинал:  https://klarasystems.com/articles/the-freebsd-boot-process/

 В этой статье изучается процесс загрузки FreeBSD. Он надёжен и хорошо продуман, но слегка различается в зависимости от архитектуры системы, файловой системы (UFS или ZFS), схемы разметки диска (GPT или MBR) и интерфейса прошивки, управляющего загрузкой (UEFI или BIOS/CSM).

    ● BIOS

BIOS также известен как режим CSM или legacy. Это старый механизм загрузки 16-битных систем, который до сих пор поддерживается на многих компьютерах. Он подходит для загрузки FreeBSD, хотя будет чуть медленней UEFI и не поддерживает загрузку с устройств NVMe. Режим BIOS поддерживает разметки MBR и более современную GPT, а также слайсы Freebsd.

    ● UEFI

Все современные системы архитектуры amd64 поддерживают режим загрузки UEFI; также многие из них поддерживают устаревший режим BIOS ─ некоторые даже предлагают установить один из них основным, а второй в качестве запасного, если первый метод не сработает.

Также режим UEFI доступен на многих системах с архитектурой arm64 ─ его поддержка требуется для сертификата  ServerReady ARM.

Некоторые системы arm64 и riscv/riscv64 поддерживают загрузку с помощью U-Boot вместо загрузки с помощью UEFI ─ FreeBSD поддерживает оба метода. Системы архитектуры RISC-V также можно загружать с помощью загрузчика OpenSBI, заменившего BBL(Berkley Boot Loader) из проекта FreeBSD. В данный момент команда FreeBSD работает над реализацией поддержки UEFI в системах RISC-V.

    ● Процесс загрузки Freebsd

Этот процесс бывает довольно сложным и включает в себя множество частей, которые сложно отличить друг от друга. Чтобы облегчить понимание, мы разбили статью на два раздела. В первом рассматривается часть загрузки, предшествующая запуску программы loader(8), которая отображает знаменитое "меню с Бисти"; второй посвящен тому, что происходит после того, как loader загрузит выбранное ядро системы.

        ▪ Стадии загрузки до активации загрузчика Freebsd ─ программы loader(8)

К этапу загрузки ядра Freebsd и передачи управления загрузкой процессу PID 1 ─ то есть системе init(8) ─ можно прийти разными путями в зависимости от архитектуры системы, метода загрузки, схемы разметки и файловой системы.

Прежде чем вникать в детали каждого режима загрузки, давайте схематично разобьем их на стадии:


BIOS/ MBR/UFS

  +-> MBR from 'Boot Device' BIOS disk          | MBR
    +-> boot0                                   | STAGE 0
      +-> boot1                                 | STAGE 1
        +-> boot2                               | STAGE 2
          +-> loader                            | STAGE 3
            +-> kernel                          | KERNEL
              +-> init                              | INIT

BIOS/ MBR/ZFS
  +-> MBR from 'Boot Device' BIOS disk          | MBR
    +-> boot0                                   | STAGE 0
      +-> boot1                                 | STAGE 1
        +-> zfsboot                            | STAGE 2
          +-> zfsloader                       | STAGE 3
            +-> kernel                           | KERNEL
              +-> init                               | INIT

BIOS/ GPT/UFS
  +-> GPT from 'Boot Device' BIOS disk          | GPT
    +-> pmbr                                     | STAGE 0
      +-> gptboot                              | STAGE 1 + STAGE 2
        +-> loader                               | STAGE 3
          +-> kernel                             | KERNEL
            +-> init                                 | INIT

BIOS/ GPT/ZFS
  +-> GPT from 'Boot Device' BIOS disk                 | GPT
    +-> pmbr                                                            | STAGE 0
      +-> gptzfsboot                            | STAGE 1 + STAGE 2
        +-> zfsloader (analogous to loader)     | STAGE 3
          +-> kernel                                 | KERNEL
            +-> init                                     | INIT
 
UEFI/GPT/MBR/UFS/ZFS
  +-> GPT/MBR from 'Boot Device' BIOS disk      | GPT/MBR
    +-> UEFI                                       | STAGE 0
      +-> boot1.efi (/efi/boot/boot${ARCH}.efi) | STAGE 1 + STAGE 2
        +-> loader.efi                          | STAGE 3
          +-> kernel                              | KERNEL
            +-> init                                  | INIT

UEFI/GPT/MBR/UFS/ZFS (13.0 and later)
  +-> GPT/MBR from 'Boot Device' BIOS disk      | GPT/MBR
    +-> UEFI                                                            | STAGE 0
      +-> loader.efi (/efi/FreeBSD/loader.efi)  | STAGE 1-3
        +-> kernel                                                    | KERNEL
          +-> init                                                        | INIT


Переменная ARCH, в зависимости от вашей системы, может принимать одно из значений:  x86 - x64 - arm - aa64.

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

    ▪ BIOS/Legacy, MBR и UFS

Использование таблицы разделов MBR и файловой системы UFS ─ самый старый метод загрузки FreeBSD. Допустим, ваше загрузочное устройство ─ диск с интерфейсом sata: /dev/ada0. На нём есть один основной раздел MBR (в терминах FreeBSD он называется слайс), который система видит как /dev/ada0s1. На этот слайс надо будет установить флаг активного (загрузочного) раздела. Внутри слайса вы увидите разделы (партиции) BSD, созданные утилитой bsdlabel(8). Корневой раздел, с которого будет производиться чтение в процессе загрузки, обозначен как /dev/ada0s1a.

    Stage 0: 

Из-за ограничений на размер файла загрузчика, накладываемых BIOS+MBR, загрузчик делится на стадии. BIOS загружает в память для исполнения первый сектор диска. Это называется нулевой стадией ─ stage 0. Нулевая стадия использует файл /boot/boot0, в котором записано 446 байт кода на ассемблере, а оставшиеся 66 байт (512-446) первого сектора содержат таблицу разделов (именно поэтому в ней может быть только 4 пункта) и сигнатуру. После загрузки в память программа, которая 446 байт, анализирует таблицу разделов и отображает меню загрузки на основании кода типа раздела, считанного из таблицы. Например:


    F1 FreeBSD
    F2 Win

    Default: F1

Вместо файла /boot/boot0 можно использовать /boot/boot0sio ─ в этом случае меню также будет выведено на последовательную консоль. Но если на вашей машине нет последовательной консоли, она может зависнуть в процессе загрузки, поэтому данный файл не используется по умолчанию. 

    Stage 1:

Следующий этап загрузки ─ считывание и выполнение файла  /boot/boot1 с первого сектора выбранного первичного раздела (слайса) ─ это называется Stage 1. Как правило, на этом этапе выполняются два файла: /boot/boot1 (512 байт) и  /boot/boot2  (7680 байт). Файл  /boot/boot2 занимает первые шестнадцать секторов по 512 байт, которые UFS не использует.

Главная задача boot1 ─ загрузка следующей стадии загрузчика, которая имеет более сложный код, чем первая стадия. Этот код загружает сервер BTX, после чего тот загружает свой клиент boot2, а затем ещё один клиент под названием loader. После этого мы переходим на вторую стадию.

    Stage 2:

boot 2 задаёт и инициализирует важную структуру данных bootinfo и передаёт её загрузчику, а затем ─ ядру FreeBSD, но об этом позже. boot 2 ─ это маленькая программа, которая имеет базовую информацию о файловой системе UFS, достаточную, чтобы найти файлы /boot/loader и /boot/kernel ─ учитывая объём кода (7680 байт), это весьма впечатляет.

    Stage 3:

Запускается loader, который ищет ядро и загружает его. Как уже было сказано, loader также является клиентом BTX. Считываются и загружаются конфигурационные файлы /boot/loader.rc и /boot/loader.conf. Основная задача программы loader - загрузка ядра FreeBSD; loader позволяет выбрать одно из нескольких ядер. После загрузки ядра в память начинается его инициализация.

    ▪ BIOS/Legacy, MBR и ZFS    

Схема загрузки ZFS с раздела MBR слегка отличается. На нулевой стадии (Stage 0) boot0 загружает другой файл boot1. Затем boot1 находит файл zfsboot ─ аналог boot2 ─ размером 64 КiB по смещению 1 Mib на разделе ZFS в предопределенном пустом месте файловой системы. 

Это означает, что на этапах Stage 1 и Stage 2 соответственно код zfsboot распознает файловую систему ZFS и загружает zfsloader. zfsloader выводит интерактивное меню, аналогичное тому, которое выдает loader для системы UFS. Точно так же, как и loader, zfsloader после этого загружает ядро и остальную часть системы FreeBSD.

Этап, на котором zfsloader уже загружен и работает ─ это Stage 3. На этой стадии можно выбрать, какой ZFS Boot Environment загружать.

    ▪ BIOS/Legacy, GPT и UFS

Теперь давайте рассмотрим чуть более современный процесс загрузки с использованием таблицы разделов GPT, но в режиме загрузки BIOS (Legacy, CSM). Хотя диск размечен с использованием таблицы GPT, он все равно содержит защитную загрузочную запись ─ Protective MBR или, сокращенно, pmbr. Она нужна для того, чтобы операционные системы, не поддерживающие схему GPT, не определяли диск как неразмеченный. 

pmbr загружает FreeBSD тем же способом, что и MBR ─ считывается один сектор размером 512 байт и выполняется код из него. Это можно назвать нулевой стадией ─ Stage 0.

Специальный загрузочный раздел GPT (его тип freebsd-boot) содержит код других стадий загрузчика: gptldr ─ аналог boot1 ─ и gptboot вместо boot2. Это будут соответственно Stage 1 и Stage 2.

pmbr находит этот загрузочный раздел и выполняет код, содержащийся в нём. Для файловой системы UFS используется файл gptboot. Как и раньше, первый этап (Stage 1) представляет собой программу на ассемблере размером 512 байт, которая только загружает и выполняет Stage 2. gptboot содержит код, который больше по размеру и позволяет обращаться к UFS, а также (опционально) понимает шифрование GELI, Этот код умеет находить загрузчик на разделе с файловой системой UFS и запускать его. 

На стадии Stage 3 loader загружен и работает, можно выбрать, какое ядро загружать.

    ▪ BIOS/Legacy, GPT и ZFS

Загрузка с GPT и файловой системой ZFS во многом похожа на схему с GPT и UFS2. Сначала pmbr загружает систему FreeBSD, выполняя код из первого сектора размером 512 байт  ─ как и в случае MBR. Этот этап можно назвать Stage 0.

Специальный загрузочный раздел GPT (тип freebsd-boot) содержит код других стадий загрузчика: gptldr ─ аналог boot1  ─ и zfsboot вместо boot2. Это Stage 1 и Stage 2.

pmbr считывает и выполняет код из этого раздела. Для ФС ZFS используется файл gptzfsboot, который содержит информацию о ZFS и ─ опционально ─ о GELI и может расшифровать, загрузить в память и запустить zfsloader из набора данных ZFS, созданного по умолчанию.

Когда zfsloader загружен и работает, начинается Stage 3 и можно выбрать, какую среду загрузки и какое ядро загружать.

    ▪ UEFI, GPT/MBR и UFS/ZFS

А теперь поговорим о "новейшем" способе загрузки FreeBSD ─ с помощью Unified Extensible Firmware Interface, (UEFI). UEFI быстрее, чем метод BIOS, поскольку переходит в 64-разрядный режим, как только это становится возможным. 

Немного предыстории: первой реализацией интерфейса был Intel EFI для архитектуры Itanium (IA64). Затем эту разработку "унифицировали" и перенесли на другие архитектуры ─ отсюда и "Unified" в начале названия. Разумеется, это очень сокращённая версия истории прошивки: кроличья нора значительно глубже, ─  но в данном случае этого достаточно.

FreeBSD прекрасно поддерживает режим загрузки UEFI. Разумеется, как и в случае других способов загрузки, процесс делится на стадии. Эти стадии практически не зависят от таблицы разделов на диске ─ GPT или MBR.

На этапе Stage 0 после включения питания запускается интерфейс прошивки UEFI и ищет загрузчик операционной системы на разделе  EFI File System Partition (ESP), отформатированном в FAT32. UUID системного раздела C12A7328-F81F-11D2-BA4B-00A0C93EC93B.

В зависимости от архитектуры файл загрузчика может называться следующим образом:

 ARCH  WIDE   PATH
   i386  32bit  /efi/boot/bootx86.efi
  amd64  64bit  /efi/boot/bootx64.efi
    arm  32bit  /efi/boot/bootarm.efi
  arm64  64bit  /efi/boot/bootaa64.efi


По умолчанию во FreeBSD файл boot1.efi установлен под именем bootx64.efi. Его исполнение означает, что мы находимся на этапе Stage 1 или Stage 2.

Для определения корневой файловой системы, с которой будет загружаться FreeBSD, файл boot1.efi использует такую последовательность:

    - Поиск загрузочных пулов для ZFS 
    - Поиск загрузочных разделов для UFS 

Раздел распознаётся как загрузочный, если boot1.efi может загрузить с него loader.efi. Если на одном устройстве есть как раздел UFS, так и ZFS, то предпочтение отдаётся ZFS. После того как UEFI исполнит код файла bootx64.efi (который на самом деле boot1.efi), начинается этап Stage 3 и загружается loader.efi, который позволяет выбрать среду загрузки и ядро. 

После того, как среда загрузки и ядро будут выбраны, loader.efi загрузит ядро FreeBSD.

    ● Ядро и многопользовательский режим

Прежде чем загрузить выбранное ядро, loader считывает и загружает параметры из файла /boot/device.hints. После выбора ядра и/или среды загрузки loader запускает ядро, которое начинает проверку наличия и инициализацию устройств.

Затем ядро передаёт управление процессу  /sbin/init (PID 1), который монтирует файловые системы. init(8) также занимается другими вещами ─ такими как виртуальные консоли, найденные в файле ttys(5), ─ и запускает процессы getty(8), которые, в свою очередь, инициализируют команды  login(1).

Закончив с этим, init(8) продолжает процесс загрузки в многопользовательский режим, после чего начинает конфигурацию системных служб FreeBSD ─ rc(8). Параметры системных служб по умолчанию считываются из файла /etc/defaults/rc.conf, а специфичные для системы данные ─ из файла /etc/rc.conf.

Затем монтируются файловые системы из /etc/fstab и выдаются адреса сетевым интерфейсам. И наконец запускаются сервисы и демоны с помощью стартовых скриптов из файлов /etc/rc.d и /usr/local/etc/rc.d. rcorder(8) гарантирует правильный порядок их запуска.

    ● nextboot(8)

Во FreeBSD есть утилита nextboot(8), которая позволяет загрузить определенное ядро, указав флаги к нему, только один раз ─ при следующей загрузке.

Это достигается тем, что loader(8) считывает информацию о ядре из файла /boot/nextboot.conf при его наличии. При перезагрузке машины nextboot.conf автоматически удаляется и система возвращается к предыдущей "постоянной" конфигурации.

Для файловых систем ZFS nextboot хранит метаданные в специально отведенном поле метки пула ZFS, поскольку загрузчик более ранней стадии не может записывать в сам пул. Метаданные nextboot стираются сразу после считывания и поэтому влияют только на один процесс загрузки после их записи.

Чтобы один раз загрузить ядро FreeBSD под названием CUSTOM, введите следующую команду:

    # nextboot -k CUSTOM

Если надо загрузить тестовое ядро TEST в однопользовательском режиме, введите команду:

    # nextboot -o "-s" -k TEST    

Следующая команда удаляет все существующие конфигурации nextboot(8):

    # nextboot -D

    ● Флаги загрузки bootme/bootonce/bootfailed 

Во FreeBSD существуют дополнительные флаги загрузки:  bootme, bootonce, и bootfailed. Флаг bootme указывает, с какого раздела должна производиться загрузка. Флаг bootonce используется вместе с bootme, чтобы загрузиться с указанного раздела один раз и затем вернуться к обычной конфигурации. Это достигается тем, что loader(8) удаляет флаги. Последний флаг ─ bootfailed ─ указывает, что с данного раздела система не смогла загрузиться. Чтобы управлять этими флагами, воспользуйтесь утилитой gpart(8). Например:

    # gpart set -a bootme -i 2 ada0

Эти флаги особенно полезны, если у вас более одного корневого раздела UFS с разными версиями FreeBSD: можно установить флаг bootme, чтобы загружаться с другого раздела.

    ● Примеры управления процессом загрузки с помощью команд

С помощью следующих команд можно изменить или обновить код загрузчика в MBR:
    
    # fdisk -B
    # fdisk -B -b /boot/boot0 ada0
    # boot0cfg -B
    # boot0cfg -s 1 -b /boot/boot0 ada0

Процесс установки zfsboot на слайс MBR:


    # gpart create -s mbr ada0
    # gpart add -t freebsd ada0
    # gpart bootcode -b /boot/boot0 ada0
    # gpart set -a active -i 1 ada0
    # dd if=/dev/zero of=/dev/ada0s1 count=2
    # dd if=/boot/zfsboot of=/dev/ada0s1 count=1
    # dd if=/boot/zfsboot of=/dev/ada0s1 iseek=1 oseek=1024

Процесс установки загрузчика для GPT:

    UFS 

# gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 ada0   

     ZFS  

# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0

Создание раздела UEFI ESP вручную:

    # gpart add -a 4K -t efi -s 200M ada0
    # newfs_msdos /dev/ada0s1
    # mount_msdosfs /dev/ada0s1 /mnt
    # mkdir -p /mnt/efi/boot
    # cp /boot/boot1.efi /mnt/efi/boot/bootx64.efi

    ● Дополнительные источники:

Вот интересные ресурсы FreeBSD, посвященные процессу загрузки, которые также могут вам пригодиться:

   ▪ FreeBSD Architecture Handbook - Chapter 1 - Bootstrapping and Kernel Initialization
   ▪ FreeBSD Handbook - Chapter 13 - FreeBSD Booting Process
   ▪ boot(8)
   ▪ boot.config(5)
   ▪ boot0cfg(8)
   ▪ boot1.efi(8)
   ▪ efibootmgr(8)
   ▪ efivar(8)
   ▪ fdisk(8)
   ▪ gptboot(8)
   ▪ gptzfsboot(8)
   ▪ zfsboot(8)
   ▪ zfsbootcfg(8)
   ▪ loader(8)
   ▪ loader.efi(8)
   ▪ nextboot(8)
   ▪ fastboot(8)