Arch linux systemd boot

systemd-firstboot

Starting with version 216 of systemd, the command systemd-firstboot allows for setting of basic system settings before or during the first boot of a newly created system. The tool is able of initialize the following system settings: timezone, locale, hostname, the root password, as well as automated generation of a machine ID.

As systemd-firstboot interacts with the filesystem directly and does not make use of the related systemd services (such as timedatectl, hostnamectl or localectl), it should not be executed on an already running system.

Settings can be specified non-interactively when externally used on filesystem images, or interactively if executed during the early boot process.

A default Arch Linux installation will set most variables systemd-firstboot is able to manipulate, or facilitate the creation of skeleton files which prevent its use when installing the systemd package through pacstrap.

Installation

systemd-firstboot is part of and packaged with systemd .

Usage Example

Warning: Doing this on an existing Arch Linux instance may break your system. The following steps should only be used on new installations.

Interactively configure system settings during boot of a fresh Arch Linux installation

Allowing systemd-firstboot to manipulate a previously un-booted Arch Linux installation is particularly useful in situations where installation is undertaken by an individual other than the eventual end user, such as in the distribution of laptops with a pre-loaded install.

The following steps should be appended to the end of the Configure the system section of the Installation guide, before the target partitions are unmounted, thus taking place within the chroot of the new installation. Make sure all locales you want available have been generated, non-generated ones will not be offered as a possible setting.

Delete existing settings

If the following files are present, systemd-firstboot will not prompt for the setting they relate to.

Modify and enable systemd-firstboot.service

Use a drop-in file in which —prompt makes systemd-firstboot query for all possible settings and the [Install] section specifies where in the boot process the service is to be activated.

/etc/systemd/system/systemd-firstboot.service.d/install.conf

[Service] ExecStart= ExecStart=/usr/bin/systemd-firstboot --prompt [Install] WantedBy=sysinit.target

Finalize installation

Continue installing as per the Installation guide. Unless more configuration is to be undertaken, exit the chroot, unmount the partitions and shut down. Upon the next boot, systemd-firstboot will execute. Presuming no other changes to system configuration are made, removing the files above and rebooting will trigger systemd-firstboot again, in case you wish to test whether the installation worked.

See also

Источник

Arch boot process

In order to boot Arch Linux, a Linux-capable boot loader must be set up. The boot loader is responsible for loading the kernel and initial ramdisk before initiating the boot process. The procedure is quite different for BIOS and UEFI systems. A detailed description is given on this or linked pages.

Firmware types

The firmware is the very first program that is executed once the system is switched on.

BIOS

A BIOS or Basic Input-Output System is in most cases stored in a flash memory in the motherboard itself and independent of the system storage. Originally created for the IBM PC to handle hardware initialization and the boot process, it has been replaced progressively since 2010 by the UEFI which does not suffer from the same technical limitations.

UEFI

The Unified Extensible Firmware Interface has support for reading both the partition table as well as file systems. UEFI does not launch any boot code from the Master Boot Record (MBR) whether it exists or not, instead booting relies on boot entries in the NVRAM.

The UEFI specification mandates support for the FAT12, FAT16, and FAT32 file systems (see UEFI specification version 2.10, section 13.3.1.1), but any conformant vendor can optionally add support for additional file systems; for example, HFS+ or APFS in some Apple’s firmwares. UEFI implementations also support ISO-9660 for optical discs.

UEFI launches EFI applications, e.g. boot loaders, boot managers, UEFI shell, etc. These applications are usually stored as files in the EFI system partition. Each vendor can store its files in the EFI system partition under the /EFI/vendor_name directory. The applications can be launched by adding a boot entry to the NVRAM or from the UEFI shell.

The UEFI specification has support for legacy BIOS booting with its Compatibility Support Module (CSM). If CSM is enabled in the UEFI, the UEFI will generate CSM boot entries for all drives. If a CSM boot entry is chosen to be booted from, the UEFI’s CSM will attempt to boot from the drive’s MBR bootstrap code.

Note: Intel is phasing out support for CSM, relying on the feature may not be feasible in the future.[1]

System initialization

Under BIOS

1. System switched on, the power-on self-test (POST) is executed.
2. After POST, BIOS initializes the hardware required for booting (disk, keyboard controllers etc.).
3. BIOS launches the first 440 bytes (the Master Boot Record bootstrap code area) of the first disk in the BIOS disk order.
4. The boot loader’s first stage in the MBR boot code then launches its second stage code (if any) from either:
   • next disk sectors after the MBR, i.e. the so called post-MBR gap (only on a MBR partition table),
   • a partition’s or a partitionless disk’s volume boot record (VBR),
   • for GRUB on a GPT partitioned disk—a GRUB-specific BIOS boot partition (it is used in place of the post-MBR gap that does not exist in GPT).
5. The actual boot loader is launched.
6. The boot loader then loads an operating system by either chain-loading or directly loading the operating system kernel.

Under UEFI

1. System switched on, the power-on self-test (POST) is executed.
2. After POST, UEFI initializes the hardware required for booting (disk, keyboard controllers etc.).
3. Firmware reads the boot entries in the NVRAM to determine which EFI application to launch and from where (e.g. from which disk and partition).
   • A boot entry could simply be a disk. In this case the firmware looks for an EFI system partition on that disk and tries to find an EFI application in the fallback boot path \EFI\BOOT\BOOTx64.EFI ( BOOTIA32.EFI on systems with a IA32 (32-bit) UEFI). This is how UEFI bootable removable media work.
4. Firmware launches the EFI application.
   • This could be a boot loader or the Arch kernel itself using EFISTUB.
   • It could be some other EFI application such as the UEFI shell or a boot manager like systemd-boot or rEFInd.

If Secure Boot is enabled, the boot process will verify authenticity of the EFI binary by signature.

Multibooting in UEFI

Since each OS or vendor can maintain its own files within the EFI system partition without affecting the other, multi-booting using UEFI is just a matter of launching a different EFI application corresponding to the particular operating system’s boot loader. This removes the need for relying on the chain loading mechanisms of one boot loader to load another OS.

Boot loader

A boot loader is a piece of software started by the firmware (BIOS or UEFI). It is responsible for loading the kernel with the wanted kernel parameters and any external initramfs images. In the case of UEFI, the kernel itself can be directly launched by the UEFI using the EFI boot stub. A separate boot loader or boot manager can still be used for the purpose of editing kernel parameters before booting.

Warning: A boot loader must be able to access the kernel and initramfs image(s), otherwise the system will not boot. Thus, in a typical setup, it must support accessing /boot . That means it must have support for everything starting from the block devices, stacked block devices (LVM, RAID, dm-crypt, LUKS, etc) and ending with the file system on which the kernel(s) and initramfs image(s) reside.

Feature comparison

• As GPT is part of the UEFI specification, all UEFI boot loaders support GPT disks. GPT on BIOS systems is possible, using either «hybrid booting» with Hybrid MBR, or the new GPT-only protocol. This protocol may however cause issues with certain BIOS implementations; see rodsbooks for details.
• Encryption mentioned in file system support is filesystem-level encryption, it has no bearing on block-level encryption.

Kernel

The boot loader boots the vmlinux image containing the kernel.

The kernel functions on a low level (kernelspace) interacting between the hardware of the machine and the programs. The kernel initially performs hardware enumeration and initialization before continuing to userspace. See Wikipedia:Kernel (operating system) and Wikipedia:Linux kernel for a detailed explanation.

initramfs

The root file system at / starts out as an empty rootfs, which is a special instance of ramfs or tmpfs. This is the temporary root file system where the initramfs (initial RAM file system) images will be unpacked to.

The purpose of the initramfs is to bootstrap the system to the point where it can access the root file system (see FHS for details). It does not need to contain every module one would ever want to use; it should only have modules required for the root device like IDE, SCSI, SATA or USB/FW (if booting from an external drive) and encryption. The majority of modules will be loaded later on by udev, during the init process.

First, the kernel unpacks its builtin initramfs into the temporary root. Arch Linux’s official kernels use an empty archive for the builtin initramfs, which is the default when building Linux. Then, the kernel unpacks external initramfs files specified by the command line passed by the boot loader, overwriting any files from the embedded initramfs. These external initramfs images can be generated with mkinitcpio, dracut or booster, and are Arch’s preferred method for setting up for early userspace.

Early userspace

The early userspace stage takes place while the temporary rootfs is mounted, operating on the files provided by the #initramfs.

The function of early userspace is configurable, but generally does the following:

• systemd-modules-load(8) loads kernel modules, such as any block device modules needed to mount the real root file system.
• Handle decryption of the real root file system, if applicable.
• Load the DRM module, as early KMS is enabled by default for in-tree modules.

At the final stage of early userspace, the real root is mounted at /sysroot , and then switched to. The late userspace starts by executing the init program from the real root file system.

Late userspace

The startup of late userspace is executed by the init process. Arch officially uses systemd which is built on the concept of units and services, but the functionality described here largely overlaps with other init systems.

getty

The init process calls getty once for each virtual terminal (typically six of them). getty initializes each terminal and protects it from unauthorized access. When the username and password are provided, getty checks them against /etc/passwd and /etc/shadow , then calls login(1) .

Login

The login program begins a session for the user by setting environment variables and starting the user’s shell, based on /etc/passwd . The login program displays the contents of /etc/motd (message of the day) after a successful login, just before it executes the login shell. It is a good place to display your Terms of Service to remind users of your local policies or anything you wish to tell them.

Shell

Once the user’s shell is started, it will typically run a runtime configuration file, such as bashrc, before presenting a prompt to the user. If the account is configured to start X at login, the runtime configuration file will call startx or xinit. Jump to #Graphical session for the end.

Display manager

This article or section needs expansion.

Reason: This section only describes the process with Xorg but does not explain what happens with Wayland. (Discuss in Talk:Arch boot process)

Additionally, init can be configured to start a display manager instead of getty on a specific virtual terminal. This requires manually enabling its systemd service file. The display manager then starts a graphical session.

Graphical session

xinit runs the user’s xinitrc runtime configuration file, which normally starts a window manager or a desktop environment. When the user is finished and exits, xinit, startx, the shell, and login will terminate in that order, returning to getty or the display manager.

See also

Источник