Загрузка системы: BIOS & UEFI, GRUB, initrd, systemd/sysvinit/upstart

• Трек на suno по загрузке Linux 🙂
• BIOS – Basic Input/Output System
• UEFI – Unified Extensible Firmware Interface
• Общий процесс загрузки Linux, подробнее отдельно ниже

• И BIOS и UEFI имеют уязвимости, но сейчас на слуху именно уязвимости UEFI

Аналитики компании Binarly обнаружили 23 критические уязвимости в UEFI от InsydeH2O, которая используется многими крупными вендорами, включая HP, Lenovo, Fujitsu, Microsoft, Intel, Dell, Bull (Atos) и Siemens.

• В BIOS есть настройки работы с питанием (bios power management), могут быть полезны:
  • что делать в случае неожиданного отключения
    • не включаться (по умолчанию)
    • включать сразу
  • включаться всегда при наличии питания
• Правки дампа BIOS делаются
  • (чаще работает) с использованием HEX редактора и UEFITool – дамп BIOS открывается в UEFITool, ищется модуль, содержащий необходимые для замены значения, экпортируется, изменяется в HEX редакторе, импортируется, сохраняется новый образ и при помощи программатора заливается на микросхему
  • (чаще не работает) с использованием HEX редактора – дамп BIOS открывается в HEX редакторе, далее ищутся строки которые необходимо заменить, дамп сохраняется и при помощи программатора заливается на микросхему

BOOT directory

В Boot директории содержатся ключевые файлы, необходимые для загрузки системы – grub.cfg, kernel, boot image, initrd/initramfs, config и прочие.

[root@localhost ~]# ll /boot/
total 108556
-rw-r--r--. 1 root root 126426 Nov 20 2015 config-3.10.0-327.el7.x86_64
drwxr-xr-x. 2 root root 4096 Oct 11 11:07 extlinux
drwxr-xr-x. 2 root root 26 Jul 27 17:23 grub
drwx------. 6 root root 104 Jul 27 21:05 grub2
-rw-r--r--. 1 root root 57594234 Jul 27 20:32 initramfs-0-rescue-c45de976bcc44afba871f946c3230751.img
-rw-r--r--. 1 root root 29701379 Jul 27 21:03 initramfs-3.10.0-327.el7.x86_64.img
-rw-r--r--. 1 root root 10192063 Jul 27 20:01 initrd-plymouth.img
-rw-r--r--. 1 root root 252612 Nov 20 2015 symvers-3.10.0-327.el7.x86_64.gz
-rw-------. 1 root root 2963044 Nov 20 2015 System.map-3.10.0-327.el7.x86_64
-rwxr-xr-x. 1 root root 5156528 Jul 27 20:41 vmlinuz-0-rescue-c45de976bcc44afba871f946c3230751
-rwxr-xr-x. 1 root root 5156528 Nov 20 2015 vmlinuz-3.10.0-327.el7.x86_64

[root@localhost ~]# ll /boot/grub2
total 32
-rw-r--r--. 1 root root 64 Jul 27 20:51 device.map
drwxr-xr-x. 2 root root 24 Jul 27 20:51 fonts
-rw-r--r--. 1 root root 4231 Jul 27 21:05 grub.cfg
-rw-r--r--. 1 root root 1024 Oct 17 18:56 grubenv
drwxr-xr-x. 2 root root 8192 Jul 27 20:51 i386-pc
drwxr-xr-x. 2 root root 4096 Jul 27 20:51 locale
drwxr-xr-x. 3 root root 19 Jul 27 17:59 themes

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

1. 1. запуск микрокода BIOS / UEFI который проверяет hardware (POST – Power-on self-test), осуществляет его низкоуровневую настройку, определяет на каком носителе будет осуществляться поиск загрузчика и выполняет программу-загрузчик ОС, как только загрузчик был обнаружен и загружен в память, BIOS передает управление ему.
   2. /boot/efi (папка может быть пустой): поиск на выбранном носителе главная загрузочной записи MBR / GPT (чаще всего сформатированном в небольшой раздел FAT32) загрузчика bootloader в boot record носителя (первые секторы раздела носителя) – именно для создания boot record на носителях (flash/usb) нужно использовать dd / rufus / unetbooting / win32diskimager и прочие утилиты, недостаточно просто ‘забросить’ файлы на носитель. MBR размещена в 1-м секторе загрузочного диска, например /dev/hda или /dev/sda. MBR занимает меньше, чем 512 байтов. Она содержит информацию о GRUB’е (или LILO) и состоит из трех компонентов:
      1. главная загрузочная информация, «живущая» в первых 446 байтах
      2. информация о таблице разделов — в следующих 64 байтах
      3.  последние 2 байта нужны для проверки корректности mbr
   3. boot/grub (тут или в /boot/grub/ или в /etc/ находится файл конфигурации grub.conf/grub.cfg): запуск bootloader (сейчас обычно в виде GRUB version 2, но раньше были разные bootloader, что привело к созданию GRand Unified Bootloader – универсального загрузчика для разных ОС/разных ядер одной ОС, который может или полностью подменить существующий загрузчик или «встать» перед ним как в случае с Windows); ключевое что содержит GRUB это местонахождение файлов с ОС на диске (путь к ядру и образу initrd), но так же в конфигурации GRUB можно задать доп. параметры типа kernel parameters в /proc/cmdline, параметры recovery feature, можно отключать аппаратные и програмные модули еще до загрузки ОС и даже управлять разрешением экрана (для извращений).
      1. Пример записи из GRUB для одной из menuentry, в конфиге grub можно указать конкретные ядра/список ядер:
         • menuentry ‘Debian GNU/Linux, with Linux 4.19.0-9-amd64 (recovery mode)’
           • linux   /boot/vmlinuz-4.19.0-9-amd64  – kernel
           • initrd  /boot/initrd.img-4.19.0-9-amd64  – RAM disk
      2. Для автоматического редактирования grub файла в случае обновления ядра делать ничего вручную не нужно – автоматически установщик добавляет menu entry с новым ядром и метит его дефолтным для загрузки, пример описан в CentOS
      3. Редактируем файл grub через sudoedit (рекомендуется) или напрямую
         • sudoedit /etc/default/grub 
      4. Пример опций/изменений, хорошо описаны на gnu.org
         • GRUB_TIMEOUT=5 – сколько будет timeout ожидания выбора ОС/ядра (-1 бесконечно, 0 не ждать вообще)
         • GRUB_DISABLE_RECOVERY=true – режимы восстановления не показываются в меню GRUB
         • GRUB_DEFAULT=saved – сохранение выбранной опции в последней загрузке (выбранной ОС) по умолчанию
         • GRUB_DEFAULT=”1>Debian GNU/Linux, with Linux 4.19.0-20-amd64″ – фиксация конкретной версии ядра Linux
         • GRUB_TERMINAL_OUTPUT=console – может быть изменение с вывода на консоль в другой источник – напр. на serial port для сетевых девайсов в среднем может быть лучше т.к. монитор для подключения к консоли может отсутствовать
         • GRUB_CMDLINE_LINUX=”default_hugepagesz=1GB hugepagesz=1G hugepages=8 transparent_hugepage=never” – пример настройки huge pages для DPDK/TRex
         • GRUB_CMDLINE_LINUX=”isolcpus=1-19″ – пример изоляции CPU ядер
      5. Кроме основного файла grub.cfg, GRUB так же считывает все конфигурационные файлы из директории /etc/grub.d и добавляет их в общую конфигурацию grub в один grub.cfg; изменения пользователя в виде кастомизированный меню-записей рекомендуется добавлять в файлы 40_custom, другую кастомазацию 41_custom, найденые ОС, добавленные в меню фигурируют в 30_os-prober

/etc/grub.d# ls -ltr
total 76
-rwxr-xr-x 1 root root 6258 Jun 13 2019 05_debian_theme
-rw-r--r-- 1 root root 483 Jun 25 2019 README
-rwxr-xr-x 1 root root 216 Jun 25 2019 41_custom
-rwxr-xr-x 1 root root 214 Jun 25 2019 40_custom
-rwxr-xr-x 1 root root 1418 Jun 25 2019 30_uefi-firmware
-rwxr-xr-x 1 root root 12059 Jun 25 2019 30_os-prober
-rwxr-xr-x 1 root root 11497 Jun 25 2019 20_linux_xen
-rwxr-xr-x 1 root root 12444 Jun 25 2019 10_linux
-rwxr-xr-x 1 root root 9783 Jun 25 2019 00_header

• 1. • Обновление конфигурации GRUB после изменений, при обновлении GRUB собирает все файлы конфигурационные файлы в один grub.cfg, проверяет корректность синтаксиса перед обновлением конфигурации в /boot/ директории
       • sudo update-grub или sudo update-grub2 – Debian
       • sudo grub2-mkconfig -o /boot/grub2/grub.cfg – RHEL
  2. boot/initrd.img / initramfs.img (обычно линк к конкретному файлу определенной версии ядра):
     1. ядро ОС монтирует ram disk initrd/initramfs. Initrd (Initial RAM Disk) – временный диск в оперативной памяти; в виде образа диска копируется в RAM и рассматривается как полноценный примонтированный hard drive диск, внутри initrd находится код ОС, который необходим для старта системы. initrd используется самим ядром в качестве временной корневой файловой системы, пока kernel не загрузится в реальную примонтированную файловую систему. Этот временный диск также содержит необходимые для загрузки драйверы, позволяющие получить доступ к разделам дисков и другому оборудованию.
     2. ядро ОС запускает код операционной системы через выполнение программы /sbin/init. Поскольку init — это первый процесс, запущенный ядром Linux, поэтому она имеет идентификатор процесса (PID) №1
  3. /sbin/init (обычно линк к /lib/systemd/systemd): код ядра запускает init процесс/скрипт, который в свою очередь отвечает за запуск всех остальных компонентов/сервисов/приложений системы, вариантов реализации init несколько, вьбор делает поставщик дистрибутива и поменять сложно, ключевые:
     1. 1. systemd (2010 from Red Hat) – system daemon – самый новый (среди рассматриваемых) и популярный (его сейчас используют по сути все актуальные дистрибутивы – ubuntu/rhel/devian хотя исключения типо slackware еще есть), работает в виде отдельного процесса/демона, код выложен в git https://github.com/systemd/systemd. Помимо старта системы systemd контролирует процессы, управляет сетевым стеком/firewall и проч, для этого используется как код основного бинарного файла, так и множества systemd-утилит, которые находятся в директории systemd. В нем устранены недостатки sysvinit/upstart – системные процессы могут запускаться параллельно, упавшие демоны могут автоматически перезапускаться, removable hardware/hotplug hardware (usb/audio/etc) поддерживается лучше. При этом недостатки тоже есть – несовместимость конфигурации с sysvinit/upstart, постоянно работающий процесс. При этом преимущества использования systemd явно превышают недостатки (LPIC1). Конфигурационные файлы systemd находятся в двух местах – /lib/systemd/system (от дистрибутива, могут изменяться с обновлениями, лучше не редактировать) и /etc/systemd/system (пользовательские, изменения вносятся сюда) в обеих директориях находятся разные объекты/units, которые использует systemd, типа services/daemons, mounts, sockets, timers, paths, wants. Эти файлы обычно создаются автоматически – при установке ОС или новых пакетов, но можно их создать вручную – про сервисы и их настройку подробнее в отдельной статье. Запуск тех или иных объектов/units происходит при указании на них в исполняемом target через директориб wants target, сами target это более расширенный аналог runlevel – graphical.target (GUI), multi-user.targer (CLI), сервисы так же добавляются в target (wants target) при установке или при добавлении в автозапуск ((подробнее ниже в runlevel)). ((Systemd, ubuntu)) В ubuntu сейчас появился lifepatching, который позволяет обновить ядро и systemd без перезагрузки как системы, так и сервисов!   Понять работает ли systemd просто – вводишь systemctl, если что-то возращается – значит работает.
           • # systemctl
             UNIT LOAD ACTIVE SUB
             proc-sys-fs-binfmt_misc.automount loaded active wa
             sys-devices-pci0000:00-0000:00:02.0-0000:02:00.0-n
             sys-devices-pci0000:00-0000:00:02.0-0000:02:00.1-n
           • но еще более верным способом является посмотреть на какой процесс ссылается через symlink/soft link init процесс, если не ссылается – значит это непосредственно бинарный файл и запуск происходит sysvinit/upstart (диффиренцировать между ними позволяет документация к используемому init/к дистрибутиву, как ни странно – man init, реже ldd init по библиотекам)
             • # ps aux | head
               USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
               root 1 0.0 0.0 103912 10244 ? Ss мая17 0:03 /sbin/init
               …
             • # ls -l /sbin/init
               lrwxrwxrwx 1 root root 20 июл 8 2021 /sbin/init -> /lib/systemd/systemd
             • # ls -ltr /lib/systemd/systemd*
               -rwxr-xr-x 1 root root 14320 Mar 18 2021 /lib/systemd/systemd-volatile-root
               -rwxr-xr-x 1 root root 14456 Mar 18 2021 /lib/systemd/systemd-veritysetup
               -rwxr-xr-x 1 root root 14320 Mar 18 2021 /lib/systemd/systemd-user-sessions
               -rwxr-xr-x 1 root root 18416 Mar 18 2021 /lib/systemd/systemd-user-runtime-dir
               -rwxr-xr-x 1 root root 14400 Mar 18 2021 /lib/systemd/systemd-update-utmp
               -rwxr-xr-x 1 root root 678392 Mar 18 2021 /lib/systemd/systemd-udevd
             • # ls -ltr /lib/systemd/system
               -rw-r–r– 1 root root 287 Oct 10 2016 keyboard-setup.service
               -rw-r–r– 1 root root 312 Oct 10 2016 console-setup.service
               -rw-r–r– 1 root root 192 Jan 4 2018 logrotate.timer
               -rw-r–r– 1 root root 643 Aug 25 2018 networking.service
               -rw-r–r– 1 root root 552 Aug 25 2018 ifup@.service
               -rw-r–r– 1 root root 279 Aug 25 2018 ifupdown-wait-online.service
               -rw-r–r– 1 root root 442 Aug 25 2018 ifupdown-pre.service
               -rw-r–r– 1 root root 695 Aug 29 2018 logrotate.service
               -rw-r–r– 1 root root 170 Jan 10 2019 fstrim.timer
               -rw-r–r– 1 root root 151 Jan 10 2019 fstrim.service
               -rw-r–r– 1 root root 164 Feb 10 2019 man-db.timer
               -rw-r–r– 1 root root 482 Feb 10 2019 man-db.service
               -rw-r–r– 1 root root 432 Feb 14 2019 user.slice
               -rw-r–r– 1 root root 457 Feb 14 2019 umount.target
               -rw-r–r– 1 root root 435 Feb 14 2019 time-sync.target
               -rw-r–r– 1 root root 445 Feb 14 2019 timers.target
               -rw-r–r– 1 root root 617 Feb 14 2019 system-update.target
               -rw-r–r– 1 root root 543 Feb 14 2019 system-update-pre.target
               -rw-r–r– 1 root root 1415 Feb 14 2019 system-update-cleanup.service
               -rw-r–r– 1 root root 610 Feb 14 2019 systemd-udevd-kernel.socket
               -rw-r–r– 1 root root 635 Feb 14 2019 systemd-udevd-control.socket
               -rw-r–r– 1 root root 490 Feb 14 2019 systemd-tmpfiles-clean.timer
               -rw-r–r– 1 root root 726 Feb 14 2019 systemd-rfkill.socket
               -rw-r–r– 1 root root 551 Feb 14 2019 systemd-reboot.service
               -rw-r–r– 1 root root 556 Feb 14 2019 systemd-poweroff.service
               -rw-r–r– 1 root root 631 Feb 14 2019 systemd-networkd.socket
               -rw-r–r– 1 root root 882 Feb 14 2019 systemd-journald.socket
               -rw-r–r– 1 root root 1130 Feb 14 2019 systemd-journald-dev-log.socket
               -rw-r–r– 1 root root 647 Feb 14 2019 systemd-journald-audit.socket
               -rw-r–r– 1 root root 546 Feb 14 2019 systemd-initctl.socket
               -rw-r–r– 1 root root 556 Feb 14 2019 systemd-exit.service
               -rw-r–r– 1 root root 650 Feb 14 2019 systemd-ask-password-wall.path
               -rw-r–r– 1 root root 722 Feb 14 2019 systemd-ask-password-console.path
               -rw-r–r– 1 root root 1407 Feb 14 2019 syslog.socket
               -rw-r–r– 1 root root 710 Feb 14 2019 sys-kernel-debug.mount
               -rw-r–r– 1 root root 767 Feb 14 2019 sys-kernel-config.mount
               -rw-r–r– 1 root root 558 Feb 14 2019 sysinit.target
        2. sysvinit (old from unix) – самый старый, работает в виде набора скриптов, привнес разные runlevel (конфиг запуска)
           • запуск системы с sysvinit происходит последовательно (запуск одного процесса неминуемо тормозит остальные)
           • упавшие демоны не перезапускаются автоматически
           • нет event-triggered запуск процессов в зависимости от hardware (removable hardware включая все usb девайсы, которые могут подключаться/отключаться)/других процессов
        3. upstart (backward compatible with sysvinit; создан в 2006 изначально canonical) – устранил описанные в sysvinit недостатки, при этом имел совместимость с конфигом sysvinit; но сам процесс был похожим – вызов пачки скриптов

Initrd (сокращение от англ. Initial RAM Disk, диск в оперативной памяти для начальной инициализации) — временная файловая система, используемая ядром Linux при начальной загрузке. Initrd обычно используется для начальной инициализации перед монтированием «настоящих» файловых систем. В Linux Kernel HOWTO (руководстве о сборке ядра) пишут, что initrd призван решить проблему курицы и яйца для модульного ядра: для монтирования файловой системы необходим модуль для работы с диском и файловой системой, а для чтения модуля необходима файловая система, с которой этот модуль читается[1].

Init and Upstart
The init program (short for initialization) is the first process that spawns in the userland at system boot. It serves as the root process for all the processes that start on the system thereafter. It is a daemon process that is assigned PID 1. The init process debuted as a single main shell script in BSD UNIX that would call additional shell scripts one after the other in a pre-determined sequence to initialize the system. If a script had to wait for something during the execution, init had no other choice but to pause until what was required either became available to the script or the script timed out. The init process then continued to the next script in the sequence. This unexpected wait resulted in delays in the overall boot process. In order to support the system initialization, there was one configuration file listing names of enabled services and one optional script for handling miscellaneous tasks. During the initialization, the system had to start all enabled services.

init was enhanced in UNIX System V (SysVinit) with the introduction of numbered run levels. This enhanced approach mmodularized the entire initialization process by permitting the system to boot and run into one of several pre-configured operating states, such as system maintenance, and multi-user states with or without graphical support. Each operating state defined a set of services and numbered them to be started serially to get to that state of system operation. Though the services were numbered, it was the system administrator’s responsibility to ensure that each script was sequenced in an appropriate order of dependency to lessen the chances of service failures and delays. This dependency adjustment was a manual process. Additionally, there was still the issue of slower processing of shell scripts. In SysVinit, the inittab file was referenced to determine the default run level to boot the system to. Based on this default run level, the rc script (part of the init program) called numbered start/stop scripts corresponding to the default run level and executed them. On a running system, these same scripts were used to transition from one operating state to another by only stopping or starting the services associated with the desired target run level. Red Hat had had this boot model in their Linux distribution for roughly a decade before they switched over to a more competent system boot model in RHEL6 called Upstart.

Upstart was introduced as a replacement for the SysVinit model. It offered three major benefits over its predecessor: asynchronous service startup; automatic restart of crashed services; and event-based service start and stop triggered by a process on the system, a change in hardware, or by the start or stop of another service. This enhanced boot model was presented in RHEL6 as the default initialization scheme. Upstart, like its predecessor, also referenced the inittab file, but only to determine the default run level to boot to. Upstart used a set of configuration files located in the /etc/init directory and processed scripts from the /etc/rc.d directory for bringing the system up to the default run level and for state transitioning. It used the initctl command for service control. Due to some shortcomings in the Upstart design, Red Hat decided not to continue with this init system in RHEL7 and they switched to an even better solution called systemd.

runlevel – исходя из настроек по умолчанию с указанием номера runlevel, система будет выполнять файлы в соответствии с нижеприведенными директориями, соответствующими runlevel. К примеру, это могут быть сообщения типа «starting Postfix … OK» (запускается Postfix). Эти службы — и называются программами уровня выполнения, выполняемые из директории, которая соответствует нужному уровню выполнения.

Выполнение уровня 0 – /etc/rc.d/rc0.d/
Выполнение уровня 1 – /etc/rc.d/rc1.d/
Выполнение уровня 2 – /etc/rc.d/rc2.d/
Выполнение уровня 3 – /etc/rc.d/rc3.d/
Выполнение уровня 4 – /etc/rc.d/rc4.d/
Выполнение уровня 5 – /etc/rc.d/rc5.d/
Выполнение уровня 6 – /etc/rc.d/rc6.d/

Чаще всего тут используются ссылки типо:
# ls -ltr /etc/rc2.d/
total 0
lrwxrwxrwx 1 root root 14 May 24 2021 S01cron -> ../init.d/cron

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

• • Программы, начинающиеся на S используются для запуска. S, потому что startup.
  • Программы, которые начинаются с литеры K используются — правильно — для завершения работы. K, потому что kill.
  • Еще есть номера рядом с буквами S и K в именах программ. Эти номера используются для определения порядка запуска этих программ.

К примеру, 
- S12syslog предназначен для запуска демона syslog, его порядковый номер 12. 
- S80sendmail — для запуска демона sendmail, имеющего порядковый номер 80. 
Таким образом, программа syslog будет запущена перед sendmail.

По факту сейчас в Debian так:
# ls -ltr /etc/rc5.d/
total 0
lrwxrwxrwx 1 root root 14 May 24 2021 S01cron -> ../init.d/cron
lrwxrwxrwx 1 root root 17 May 24 2021 S01rsyslog -> ../init.d/rsyslog
lrwxrwxrwx 1 root root 26 May 24 2021 S01console-setup.sh -> ../init.d/console-setup.sh
lrwxrwxrwx 1 root root 14 May 24 2021 S01dbus -> ../init.d/dbus
lrwxrwxrwx 1 root root 13 May 24 2021 S01ssh -> ../init.d/ssh
lrwxrwxrwx 1 root root 15 Mar 14 2022 S01squid -> ../init.d/squid
lrwxrwxrwx 1 root root 14 Sep 29 2023 S01atop -> ../init.d/atop
lrwxrwxrwx 1 root root 18 Sep 29 2023 S01atopacct -> ../init.d/atopacct

runlevel+sysvinit: на старых системах под управлением sysvinit используется файл /etc/inittab для того, чтобы определить уровень выполнения (runlevel). Init определяет уровень выполнения по умолчанию (initdefault) и использует его для загрузки всех необходимых программ.

Есть следующие уровни выполнения: 
0 – прервать выполнение 
1 – однопользовательский режим, так называемый «Single user mode», или иными словами, консоль восстановления 
2 – многопользовательский режим без поддержки NFS 
3 – полноценный многопользовательский режим ((CLI like a server))
4 – не используется 
5 – X11 ((GUI))
6 – перезагрузка

runlevel+systemd: На более актуальных системах с управлением systemd файл /etc/inittab не используется, runlevel задается в конфигурации systemd, уровни приближенные к старым, но в целом они могут отличаться в разных дистрибутивах. Чтобы узнать реальный runlevel/default target используется команда systemctl get-default, сам дефолт организован через symlink/soft link – при загрузке система загружает то, что указано в этом soft link, при изменении soft link через конфигурацию systemd systemctl set-default <target> изменяется и symlink и соответственно и исполняемый runlevel (после перезагрузки). Так же есть возможность мгновенного перехода в любой/нужный target/runlevel командой systemctl isolate <target>. При этом по факту в systemctl для стандартных multi-user/graphical target используются вложенные в них nested target, которые исполняются как обязательные для целевого target (multi-user -> basic -> sysinit).

root@serv:~# systemctl get-default
graphical.target
root@serv:~# runlevel
N 5
root@serv:~# ls -ltr /etc/systemd/system/ | grep default
lrwxrwxrwx 1 root root 16 Jul 8 2021 default.target -> graphical.target


root@serv:~# systemctl set-default multi-user.target
Created symlink /etc/systemd/system/default.target → /lib/systemd/system/multi-user.target.
root@serv:~# ls -la /lib/systemd/system/runlevel*
lrwxrwxrwx 1 root root 15 Mar 18 2021 /lib/systemd/system/runlevel0.target -> poweroff.target
lrwxrwxrwx 1 root root 13 Mar 18 2021 /lib/systemd/system/runlevel1.target -> rescue.target
lrwxrwxrwx 1 root root 17 Mar 18 2021 /lib/systemd/system/runlevel2.target -> multi-user.target
lrwxrwxrwx 1 root root 17 Mar 18 2021 /lib/systemd/system/runlevel3.target -> multi-user.target
lrwxrwxrwx 1 root root 17 Mar 18 2021 /lib/systemd/system/runlevel4.target -> multi-user.target
lrwxrwxrwx 1 root root 16 Mar 18 2021 /lib/systemd/system/runlevel5.target -> graphical.target
lrwxrwxrwx 1 root root 13 Mar 18 2021 /lib/systemd/system/runlevel6.target -> reboot.target