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

• Трек на 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 в /proc/cmdline можно задать доп. параметры (kernel parameters), которые будут передаваться от загрузчика ядру, типа: параметры 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 классически (sysvinit) реализуется командой telinit, но она поддерживается и в системах с systemd.
telinit 1  - однопользовательский режим
telinit 6  - перезагружаемся

telinit may be used to change the SysV system runlevel. Since the concept of SysV runlevels is obsolete the runlevel requests will be transparently translated into systemd unit activation requests.

runlevel+systemd: На более актуальных системах с управлением systemd файл /etc/inittab не используется, аналог runlevel задается в конфигурации systemd с использованием target, уровни приближенные к старым, но в целом они могут отличаться в разных дистрибутивах. Чтобы узнать реальный 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

uefi

Хорошее описание UEFI в объяснении вопроса.

What is true regarding UEFI firmware? (Choose two.)

A. It can read and interpret partition tables

B. It can use and read certain file systems

C. It stores its entire configuration on the /boot/ partition

D. It is stored in a special area within the GPT metadata

E. It is loaded from a fixed boot disk position

Answer: BE

Explanation
UEFI firmware is a software program that provides the interface between the hardware and the operating system on a computer. UEFI stands for Unified Extensible Firmware Interface and it is a replacement for the traditional BIOS (Basic Input/Output System). UEFI firmware has several advantages over BIOS, such asfaster boot times, better security, larger disk support, and graphical user interface. Some of the features of UEFI firmware are:

* It can use and read certain file systems: UEFI firmware can access files on partitions formatted with FAT12, FAT16, or FAT32 file systems. This allows UEFI to load boot loaders, kernels, and configuration files from these partitions without relying on the legacy MBR (Master Boot Record) or boot sector code. UEFI firmware can also support other file systems, such as NTFS or ext4, with additional drivers.

* It is loaded from a fixed boot disk position: UEFI firmware is stored in a ROM chip on the motherboard, but it also requires a special partition on the boot disk to store additional files and drivers. This partition is called the EFI System Partition (ESP) and it is usually the first partition on the disk. The ESP must have a specific GUID (Globally Unique Identifier) and must be formatted with a FAT file system. The UEFI firmware will look for the ESP on the boot disk and load the files from there.


The other options are false or irrelevant. 
* UEFI firmware does not read and interpret partition tables, it relies on the operating system to do that. * UEFI firmware does not store its entire configuration on the /boot/ partition, it stores some of its settings in the NVRAM (Non-Volatile Random Access Memory) on the motherboard and some of its files on the ESP. 
* UEFI firmware is not stored in a special area within the GPT (GUID Partition Table) metadata, it is stored in a ROM chip and an ESP. GPT is a partitioning scheme that supports larger disks and more partitions than the legacy MBR scheme.

Questions

Where does the BIOS search for a bootloader?

A. On all connected storage media regardless of the boot device order.

B. On all connected storage media in the defined boot device order.

C. Only on hard disk drives in the defined boot device order.

D. Only on the last added storage media.

E. The BIOS is not responsible to search for a valid bootloader.

Answer: B

Answer: D

Answer: A

Which of the following information is stored within the BIOS? (Choose TWO correct answers.)

A. Boot device order
B. Linux kernel version
C. Timezone
D. Hardware configuration

E. The system’s hostname

Answer: AD

Option A: The BIOS stores the boot device order, which specifies the priority of bootable devices from which the system will attempt to boot. The boot device order can be configured in the BIOS settings and determines which devices the BIOS will check for a bootable operating system. 

Option B: The Linux kernel version is not stored within the BIOS. The kernel is an operating system component that is typically stored on a bootable device, such as a hard drive or a USB drive and is loaded by the bootloader after the BIOS has completed its tasks during the boot process.
Option C: The timezone is not stored within the BIOS. Timezone information is typically stored in the operating system and can be configured through the system's time and date settings. 

Option D: The BIOS stores information about the hardware configuration of the system, including the types and configurations of connected devices and the system's memory and processor. This information is used by the BIOS to initialize the hardware and hand off control to the bootloader. 

Option E: The system's hostname is not stored within the BIOS. The hostname is a unique name that identifies a computer on a network and is typically configured in the operating system.

Which of the following commands reboots the system when using SysV init? (Choose TWO correct answers.)

A. shutdown -r now

B. shutdown -r “rebooting”

C. telinit 6

D. telinit 0

E. shutdown -k now “rebooting”

Answer: AC

Which of the following commands brings a system running SysV init into a state in which it is safe to perform maintenance tasks? (Choose TWO correct answers.)

A. shutdown -R 1 now

B. shutdown -single now

C. init 1

D. telinit 1

E. runlevel 1

Answer: CD

From the user's point of view there is (afaik) no difference. telinit 5 and init 5 executed from the commandline will produce identical results.

Answer: B

Explanation
The GRUB boot process consists of three stages:
* Stage 1: This stage is located in the Master Boot Record (MBR) of the first hard disk or the boot sector of a partition. Its main function is to load either Stage 1.5 or Stage 22.
* Stage 1.5: This stage is located in the first 30 KB of hard disk immediately following the MBR or in the boot sector of a partition. It contains the code to access the file system that contains the GRUB configuration file. Its main function is to load Stage 22.
* Stage 2: This stage is located in an ordinary file system, usually in the /boot/grub directory. It contains the code to display the GRUB menu and to load the kernel and initrd images. It can also load additional modules to support other file systems or features2.
The message "Hard Disk Error" is displayed on the screen during Stage 1 of the GRUB boot process. This indicates that the next Stage (either Stage 1.5 or Stage 2) cannot be read from the hard disk because GRUB was unable to determine the size and geometry of the disk3. This could occur because the BIOS translated geometry has been changed by the user or the disk is moved to another machine or controller after installation, or GRUB was not installed using itself (if it was, the Stage 2 version of this error would have been seen during that process and it would not have completed the install)3.

The other options in the question are not correct because:
* A. The kernel was unable to execute /bin/init: This error would occur in Stage 2, after the kernel and initrd images are loaded, not in Stage 14.
* C. One or more of the filesystems on the hard disk has errors and a filesystem check should be run: This error would also occur in Stage 2, when GRUB tries to access the file system that contains the GRUB configuration file, not in Stage 15.
* D. The BIOS was unable to read the necessary data from the Master Boot Record to begin the boot process: This error would prevent GRUB from starting at all, not in Stage 16.

Answer: E

The correct answer is E. systemd.unit=rescue.target.
Explanation:
Systemd is the system and service manager for modern Linux systems. Systemd defines the target units for system bootup and provides commands to manage services and units. Targets are units which represent different system states like booting up, multi-user mode, graphical mode, and shutdown.
The default target is the target that systemd activates when the system is booted. In most cases, the default target is the multi-user.target, which is used to start a fully functional system in multi-user mode. However, sometimes it may be necessary to change the default target to a different target, such as the rescue target.
The rescue target is a special target used to troubleshoot and fix system problems. When the system is booted into the rescue target, the only basic services necessary to bring the system up are started, and the user is dropped into a single-user shell without network access.
To change the default target to the rescue target, you can add the following option to the kernel command line when booting the system:
systemd.unit=rescue.target 

This option tells systemd to start the rescue.target instead of the default target.
The other options listed in the question are incorrect:
A. systemd.target=rescue.target is not a valid option. The correct option is systemd.unit=rescue.target.
B. systemd.runlevel=rescue.target is not a valid option. Runlevels are a legacy concept used in SysVinit systems, and systemd uses targets instead.
C. systemd.service=rescue.target is not a valid option. Services are units that represent specific system services, not targets.
D. systemd.default=rescue.target is not a valid option. The correct option is systemd.unit=rescue.target.

cmdline ((/proc/cmdline))

Answer: C

The command that overwrites the bootloader located on '/dev/sda' without overwriting the partition table or any data following it is 'dd if=/dev/zero of=/dev/sda bs=440 count=1'. The correct answer is Option C. 

The 'dd' command is a utility for copying data from one location to another. It can be used to overwrite data on a device, such as a hard drive or a bootloader. 
The 'if' option specifies the input file, and the 'of' option specifies the output file. 
The 'bs' option specifies the block size, and the 'count' option specifies the number of blocks to copy. 

In this case, the command will copy a single block of data ('count=1') from '/dev/zero' (a special file that provides an endless stream of zero bits) to '/dev/sda' using a block size of '440' bytes. This will overwrite the bootloader located on '/dev/sda' without overwriting the partition table or any data following it.

The other options will overwrite more data on the device, potentially causing data loss or corruption. Option C will overwrite the first 440 bytes of the device, which is the correct block size to overwrite the bootloader without overwriting the partition table or any data following it. 

Option A will overwrite the entire device, including the partition table and all data. 

Option B will overwrite the first 512 bytes of the device, potentially causing data loss or corruption. 

Option D will overwrite the entire device, including the partition table and all data.

Which of the following commands instructs SysVinit to reload its configuration file?

A. reinit

B. initreload

C. telinit 7

D. telinit q

E. init reinit

Answer: D

Correct Answer: D
Explanation
SysVinit is a program for Linux and Unix-based systems that initializes the system and spawns all other processes. It runs as a daemon and has PID 1. The boot loader starts the kernel and the kernel starts SysVinit.
A Linux or Unix based system can be started up into various runlevels, which are modes of operation that define what services and processes are running. The /etc/inittab file is the configuration file for SysVinit, which defines the default runlevel, the available runlevels, and the actions to be taken when entering or leaving a runlevel.
The telinit command is used to change the current runlevel of the system or to send a signal to SysVinit. The telinit command takes a single argument, which can be either a runlevel number (0-6) or a special character.
The syntax of the telinit command is:
telinit [runlevel|character]
The runlevel argument instructs SysVinit to switch to the specified runlevel. For example, to switch to runlevel 3, which is the multi-user mode with networking, use the following command:
telinit 3
The character argument instructs SysVinit to perform a special action. For example, to reboot the system, use the following command:
telinit 6
The q character argument instructs SysVinit to reload its configuration file, /etc/inittab, without changing the current runlevel. This is useful when the /etc/inittab file has been modified and the changes need to be applied.
For example, to reload the /etc/inittab file, use the following command:
telinit q
The other options are not correct because:
* A. reinit: This command does not exist in the Linux system. There is no such command as reinit in the Linux documentation or the man pages.
* B. initreload: This command does not exist in the Linux system. There is no such command as initreload in the Linux documentation or the man pages.
* C. telinit 7: This command is not valid because 7 is not a valid runlevel number. The valid runlevel numbers are 0-6, where 0 means halt, 1 means single-user mode, 2 means multi-user mode without networking, 3 means multi-user mode with networking, 4 means user-defined, 5 means graphical mode, and 6 means reboot. If you run this command, you will get an error message saying:
telinit: invalid runlevel: 7
* E. init reinit: This command is not valid because reinit is not a valid argument for the init command. The init command is a synonym for the telinit command, and it takes the same arguments as the telinit command. The valid arguments for the init command are either a runlevel number (0-6) or a special character. If you run this command, you will get an error message saying:
init: invalid runlevel: reinit

Which of the following commands installs GRUB 2 into the master boot record on the third hard disk?

A. grub2 install /dev/sdc

B. grub-mkrescue /dev/sdc

C. grub-mbrinstall /dev/sdc

D. grub-setup /dev/sdc

E. grub-install /dev/sdc

Answer: E

The command that installs GRUB 2 into the master boot record on the third hard disk is grub-install /dev/sdc.
The grub-install command is the high-level tool for installing GRUB 2 on a disk or a partition. It takes a device name as an argument and writes the GRUB 2 boot loader information to the specified location. If the device name is a disk, such as /dev/sdc, the boot loader information is written to the master boot record (MBR) of the disk, which is the first sector that contains the boot code and the partition table. If the device name is a partition, such as /dev/sdc1, the boot loader information is written to the boot sectorof the partition, which is the first sector of the partition that contains the boot code and the file system information. The grub-install command is part of the 101.1 Determine and configure hardware settings topic of the LPI Linux Essentials certification program.
The other commands are either invalid or do not perform the desired task. The grub2 install command does not exist, as grub2 is not a valid command name. The grub-mkrescue command is used to create a bootable GRUB 2 rescue image, not to install GRUB 2 on a disk or a partition. The grub-mbrinstall command does not exist, as mbrinstall is not a valid subcommand for grub. The grub-setup command is a low-level tool for installing GRUB 2 on a disk or a partition, but it is not recommended for normal use, as it requires specifying the location of the GRUB 2 core image file.

The system is having trouble and the engineer wants to bypass the usual /sbin/init start up and run /bin/sh. What is the usual way to pass this change to the kernel from your boot loader?

A. Start in runlevel 1.
B. Pass init=/bin/sh on the kernel parameter line.

C. Pass /bin/sh on the kernel parameter line.

D. Pass start=/bin/sh on the kernel parameter line.

Answer: B
The other options in the question are not correct because:
* A. Start in runlevel 1: This option would not bypass the /sbin/init program, but rather instruct it to start the system in single-user mode, which is a mode that allows only the root user to log in, and disables all network services and graphical interfaces. To start in runlevel 1, the user would need to pass single or 1 on the kernel parameter line, not init=/bin/sh.
* C. Pass /bin/sh on the kernel parameter line: This option would not work, because the kernel would not recognize /bin/sh as a valid parameter and would ignore it. The kernel only accepts parameters that have a specific format, such as name=value or name.flag3. To specify the init program, the user would need to use the init= prefix, as in init=/bin/sh3.
* D. Pass start=/bin/sh on the kernel parameter line: This option would also not work, because the kernel does not have a start parameter. The user would need to use the init parameter, as in init=/bin/sh3.

Which of the following options is used in a GRUB Legacy configuration file to define the amount of time that the GRUB menu will be shown to the user?

A. hidemenu

B. splash

C. timeout

D. showmenu

Answer: C

The timeout option in a GRUB Legacy configuration file is used to define the amount of time (in seconds) that the GRUB menu will be shown to the user before booting the default entry. The timeout option is usually located in the /boot/grub/menu.lst file. For example, timeout 10 will display the GRUB menu for 10 seconds.
To disable the timeout and wait for user input indefinitely, the value of timeout can be set to -1. To boot immediately without displaying the menu, the value of timeout can be set to 0. The other options are not valid for the GRUB Legacy configuration file.