Mkinitcpio p linux zen

EFI system partition

The EFI system partition (also called ESP) is an OS independent partition that acts as the storage place for the EFI bootloaders, applications and drivers to be launched by the UEFI firmware. It is mandatory for UEFI boot.

This article or section is a candidate for moving to Unified Extensible Firmware Interface#UEFI drivers.

The UEFI specification mandates support for the FAT12, FAT16, and FAT32 file systems (see UEFI specification version 2.8, section 13.3.1.1), but any conformant vendor can optionally add support for additional file systems; for example, the firmware in Apple Macs supports the HFS+ file system.

Contents

Check for an existing partition

If you are installing Arch Linux on an UEFI-capable computer with an installed operating system, like Windows 10 for example, it is very likely that you already have an EFI system partition.

To find out the disk partition scheme and the system partition, use fdisk as root on the disk you want to boot from:

The command returns:

• The disk’s partition table: it indicates Disklabel type: gpt if the partition table is GPT or Disklabel type: dos if it is MBR.
• The list of partitions on the disk: Look for the EFI system partition in the list, it is usually at least 100 MiB in size and has the type EFI System or EFI (FAT-12/16/32) . To confirm this is the ESP, mount it and check whether it contains a directory named EFI , if it does this is definitely the ESP.

If you found an existing EFI system partition, simply proceed to #Mount the partition. If you did not find one, you will need to create it, proceed to #Create the partition.

Create the partition

The following two sections show how to create an EFI system partition (ESP).

To provide adequate space for storing boot loaders and other files required for booting, and to prevent interoperability issues with other operating systems[1][2] the partition should be at least 260 MiB. For early and/or buggy UEFI implementations the size of at least 512 MiB might be needed.[3]

GPT partitioned disks

EFI system partition on a GUID Partition Table is identified by the partition type GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B .

Choose one of the following methods to create an ESP for a GPT partitioned disk:

• fdisk: Create a partition with partition type EFI System .
• gdisk: Create a partition with partition type EF00 .
• GNU Parted: Create a partition with fat32 as the file system type and set the esp flag on it.

Proceed to #Format the partition section below.

MBR partitioned disks

EFI system partition on a Master Boot Record partition table is identified by the partition type ID EF .

Choose one of the following methods to create an ESP for a MBR partitioned disk:

• fdisk: Create a primary partition with partition type EFI (FAT-12/16/32) .
• GNU Parted: Create a primary partition with fat32 as the file system type and set the esp flag on it.

Proceed to #Format the partition section below.

Format the partition

The UEFI specification mandates support for the FAT12, FAT16, and FAT32 file systems[4]. To prevent potential issues with other operating systems and also since the UEFI specification only mandates supporting FAT16 and FAT12 on removable media[5], it is recommended to use FAT32.

After creating the partition, format it as FAT32. To use the mkfs.fat utility, install dosfstools .

If you get the message WARNING: Not enough clusters for a 32 bit FAT! , reduce cluster size with mkfs.fat -s2 -F32 . or -s1 ; otherwise the partition may be unreadable by UEFI. See mkfs.fat(8) for supported cluster sizes.

Mount the partition

The kernels, initramfs files, and, in most cases, the processor’s microcode, need to be accessible by the boot loader or UEFI itself to successfully boot the system. Thus if you want to keep the setup simple, your boot loader choice limits the available mount points for EFI system partition.

Typical mount points

The simplest scenarios for mounting EFI system partition are:

• mount ESP to /efi and use a boot loader which is capable of accessing the kernel(s) and initramfs image(s) that are stored elsewhere (typically /boot). See Arch boot process#Boot loader for more information on boot loader requirements and capabilities.
• mount ESP to /boot . This is the preferred method when directly booting an EFISTUB kernel from UEFI or booting it via a boot manager like systemd-boot.
• mount ESP to /efi and additionally mount an «Extended Boot Loader Partition» (XBOOTLDR) to /boot . This can be useful when a previously created ESP is too small to hold multiple boot loaders and/or kernels but the ESP cannot be easily resized (such as when installing Linux after Windows to dual boot). This method is supported by at least systemd-boot.

Alternative mount points

If you do not use one of the simple methods from #Typical mount points, you will need to copy your boot files to ESP (referred to hereafter as esp ).

Furthermore, you will need to keep the files on the ESP up-to-date with later kernel updates. Failure to do so could result in an unbootable system. The following sections discuss several mechanisms for automating it.

Using bind mount

Instead of mounting the ESP itself to /boot , you can mount a directory of the ESP to /boot using a bind mount (see mount(8) ). This allows pacman to update the kernel directly while keeping the ESP organized to your liking.

Just like in #Alternative mount points, copy all boot files to a directory on your ESP, but mount the ESP outside /boot . Then bind mount the directory:

After verifying success, edit your Fstab to make the changes persistent:

Using systemd

Systemd features event triggered tasks. In this particular case, the ability to detect a change in path is used to sync the EFISTUB kernel and initramfs files when they are updated in /boot/ . The file watched for changes is initramfs-linux-fallback.img since this is the last file built by mkinitcpio, to make sure all files have been built before starting the copy. The systemd path and service files to be created are:

Then enable and start efistub-update.path .

Using filesystem events

Filesystem events can be used to run a script syncing the EFISTUB Kernel after kernel updates. An example with incron follows.

In order to use this method, enable the incrond.service .

Using mkinitcpio hook

Mkinitcpio can generate a hook that does not need a system level daemon to function. It spawns a background process which waits for the generation of vmlinuz , initramfs-linux.img , and initramfs-linux-fallback.img before copying the files.

Add efistub-update to the list of hooks in /etc/mkinitcpio.conf .

Using mkinitcpio preset

As the presets in /etc/mkinitcpio.d/ support shell scripting, the kernel and initramfs can be copied by just editing the presets.

Replacing the above mkinitcpio hook

Edit the file /etc/mkinitcpio.d/linux.preset :

To test that, just run:

Another example

Using pacman hook

A last option relies on the pacman hooks that are run at the end of the transaction.

The first file is a hook that monitors the relevant files, and it is run if they were modified in the former transaction.

The second file is the script itself. Create the file and make it executable:

Troubleshooting

ESP on software RAID1

It is possible to make the ESP part of a RAID1 array, but doing so brings the risk of data corruption, and further considerations need to be taken when creating the ESP. See [8] and [9] for details and UEFI booting and RAID1 for an in-depth guide with a solution.

The key part is to use —metadata 1.0 in order to keep the RAID metadata at the end of the partition, otherwise the firmware will not be able to access it:

Источник

MKINITCPIO V31 и заглушки UEFI

Несколько месяцев назад я написал для скрипта mkinitcpio код, который позволяет ему создавать файлы UEFI с использованием заглушки systemd .

Само внесенное мной изменение можно найти на GitHub.

Далее я коротко продемонстрирую, чем эта возможность хороша, как она упрощает запуск системы, и как с ее помощью можно повысить безопасность, используя, например, Secure Boot.

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

В последнее десятилетие большинство компьютеров имеют два варианта загрузки. Режим Legacy BIOS и пришедший ему на замену UEFI. Возможности последнего весьма обширны, но один из наиболее интересных аспектов в том, что технически ядро Linux представляет собой исполняемый файл MS-DOS, и если считать его первые два байта, то мы увидим MZ .

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

Однако большинство из нас не хочет связываться непосредственно с UEFI, поэтому ради простоты мы используем загрузчики вроде grub или system-boot .

Защита цепочки загрузки

При использовании загрузчика мы обычно предоставляем ему файл конфигурации, initramfs , и библиотеку ядра. Файл initramfs включает в себя базовый набор компонентов дистрибутива Linux, отвечающих за разблокирование зашифрованных разделов, монтирование файловой системы и других разделов с последующим запуском системы init .

Все эти три файла лежат зашифрованные в загрузочном разделе*. С помощью безопасной загрузки можно подписать ядро, поскольку оно является исполняемым файлом UEFI, но это оставит полностью незащищенными конфигурацию и initramfs .

*Да, некоторые люди шифруют свои загрузочные разделы.

Решением будет вложить все эти составляющие в один исполняемый файл. Реализовать это доступным и вполне понятным способом позволяют образы EFI ядра.

Заглушки UEFI

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

Принцип такой: мы вставляем нужные данные в разделы двоичного файла, который затем подхватывается файлом заглушки.

Приведенный пример с Arch Linux создает исполняемый файл, содержащий информацию дистрибутива ( os-release ), считанные из файла параметры ядра, bmp-файл с логотипом дистрибутива, ядро и initramfs с микрокодом.

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

*Думаю, стоит упомянуть, что некоторые загрузчики не проверяют подписи выполняемых ими файлов. Это делает systemd-boot , но не делает grub . Имейте в виду.

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

MKINITCPIO

mkinitcpio – это генератор initramfs , разработанный и используемый в основном для Arch Linux, поэтому некоторые части текущего раздела будут ориентированы на этот конкретный дистрибутив. Тем не менее аналогичные возможности создания и работы с initramfs есть, к примеру, в dracut , где для этого используется — -uefi . Если ваша программа для создания initramfs такой функциональности не имеет, то ее добавление в проект не должно составить особого труда.

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

Начнем с изменения файла linux.preset , который в Arch указывает на конфигурацию ядра.

Здесь определяется расположение микрокода и имя для исполняемого файла. Кроме того, мы передаем опцию — -splash , устанавливая изображение для загрузочного экрана. Обратите внимание, что в качестве пути сохранения необходимо указать расположение, куда смонтирован текущий раздел EFI.

Далее исправляем параметры загрузки ядра. По умолчанию mkinitcpio считывает из /etc/kernel/cmdline . Если же вы не уверены, откуда происходит считывание в вашей системе, то можете проверить /proc/cmdline и использовать этот путь в качестве отправной точки. Но имейте в виду, что записи initrd , указывающие на микрокод и initramfs , нужно удалить.

Содержимое файла должно быть похожим на приведенное выше. Также учтите, что все флаги root или cyptdevices должны остаться, если вы выполняете initramfs без systemd , обеспечивающего обнаружение разделов.

Мы также добавляем в командную строку ядра команду bgrt disable . Этот флаг отключает отображение логотипа OEM после загрузки таблиц ACPI. В результате загрузочная заставка вместо замены неким невзрачным логотипом будет отображаться на несколько секунд дольше.

При выполнении mkinitcpio -P вывод должен получиться примерно таким:

Вот и все! Мы сгенерировали с помощью mkinitcpio заглушку UEFI!

Если вы используете systemd-boot , то больше ничего настраивать не нужно.
Загрузчик для отображения в меню заглушек UEFI будет искать их в каталоге EFI/Linux. Это намного упрощает настройку загрузчика, так как для его создания нужно лишь выполнить bootctl install и сгенерировать исполняемый файл.

Совет

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

Источник

mkinitcpio

mkinitcpio is a Bash script used to create an initial ramdisk environment. From the mkinitcpio(8) man page:

The initial ramdisk is in essence a very small environment (early userspace) which loads various kernel modules and sets up necessary things before handing over control to init . This makes it possible to have, for example, encrypted root file systems and root file systems on a software RAID array. mkinitcpio allows for easy extension with custom hooks, has autodetection at runtime, and many other features.

Traditionally, the kernel was responsible for all hardware detection and initialization tasks early in the boot process before mounting the root file system and passing control to init . However, as technology advances, these tasks have become increasingly complex.

Nowadays, the root file system may be on a wide range of hardware, from SCSI to SATA to USB drives, controlled by a variety of drive controllers from different manufacturers. Additionally, the root file system may be encrypted or compressed; within a software RAID array or a logical volume group. The simple way to handle that complexity is to pass management into userspace: an initial ramdisk. See also: /dev/brain0 » Blog Archive » Early Userspace in Arch Linux.

mkinitcpio has been developed by the Arch Linux developers and from community contributions. See the public Git repository.

Contents

Installation

Install the mkinitcpio package, which is a dependency of the linux package, so most users will already have it installed.

Advanced users may wish to install the latest development version of mkinitcpio from Git with the mkinitcpio-git AUR package.

Image creation and activation

Automated generation

Every time a kernel is installed or upgraded, a pacman hook automatically generates a .preset file saved in /etc/mkinitcpio.d/ . For example linux.preset for the official stable linux kernel package. A preset is simply a list of information required to create initial ramdisk images, instead of manually specifying the various parameters and the location of the output files. By default, it contains the instructions to create two images:

1. the default ramdisk image created following the directives specified in the mkinitcpio #Configuration, and
2. the fallback ramdisk image, same as above except that the autodetect hook is skipped during creation, thus including a full range of modules which supports most systems.

After creating the preset, the pacman hook calls the mkinitcpio script which generates the two images, using the information provided in the preset.

Manual generation

To run the script manually, refer to the mkinitcpio(8) manual page for instructions. In particular, to (re-)generate the preset provided by a kernel package, use the -p / —preset option followed by the preset to utilize. For example, for the linux package, use the command:

To (re-)generate all existing presets, use the -P / —allpresets switch. This is typically used to regenerate all the initramfs images after a change of the global #Configuration:

Users may create any number of initramfs images with a variety of different configurations. The desired image must be specified in the respective boot loader configuration file.

Customized generation

Users can generate an image using an alternative configuration file. For example, the following will generate an initial ramdisk image according to the directions in /etc/mkinitcpio-custom.conf and save it as /boot/initramfs-custom.img .

If generating an image for a kernel other than the one currently running, add the kernel release version to the command line. The installed kernel releases can be found in /usr/lib/modules/ , the syntax is consistent with the output of the command uname -r for each kernel.

Configuration

The primary configuration file for mkinitcpio is /etc/mkinitcpio.conf . Additionally, preset definitions are provided by kernel packages in the /etc/mkinitcpio.d directory (e.g. /etc/mkinitcpio.d/linux.preset ).

Users can modify six variables within the configuration file, see mkinitcpio.conf(5) for more details:

MODULES Kernel modules to be loaded before any boot hooks are run. BINARIES Additional binaries to be included in the initramfs image. FILES Additional files to be included in the initramfs image. HOOKS Hooks are scripts that execute in the initial ramdisk. COMPRESSION Used to compress the initramfs image. COMPRESSION_OPTIONS Extra arguments to pass to the COMPRESSION program. Usage of this setting is strongly discouraged. mkinitcpio will handle special requirements for compressors (e.g. passing —check=crc32 to xz), and misusage can easily lead to an unbootable system.

MODULES

The MODULES array is used to specify modules to load before anything else is done.

Modules suffixed with a ? will not throw errors if they are not found. This might be useful for custom kernels that compile in modules which are listed explicitly in a hook or configuration file.

BINARIES and FILES

These options allow users to add files to the image. Both BINARIES and FILES are added before hooks are run, and may be used to override files used or provided by a hook. BINARIES are auto-located within a standard PATH and are dependency-parsed, meaning any required libraries will also be added. FILES are added as-is. For example:

Note that as both BINARIES and FILES are Bash arrays, multiple entries can be added delimited with spaces.

HOOKS

The HOOKS array is the most important setting in the file. Hooks are small scripts which describe what will be added to the image. For some hooks, they will also contain a runtime component which provides additional behavior, such as starting a daemon, or assembling a stacked block device. Hooks are referred to by their name, and executed in the order they exist in the HOOKS array of the configuration file.

The default HOOKS setting should be sufficient for most simple, single disk setups. For root devices which are stacked or multi-block devices such as LVM, RAID, or dm-crypt, see the respective wiki pages for further necessary configuration.

Build hooks

Build hooks are found in /usr/lib/initcpio/install/ , custom build hooks can be placed in /etc/initcpio/install/ . These files are sourced by the bash shell during runtime of mkinitcpio and should contain two functions: build and help . The build function describes the modules, files, and binaries which will be added to the image. An API, documented by mkinitcpio(8) , serves to facilitate the addition of these items. The help function outputs a description of what the hook accomplishes.

For a list of all available hooks:

Use mkinitcpio’s -H / —hookhelp option to output help for a specific hook, for example:

Runtime hooks

Runtime hooks are found in /usr/lib/initcpio/hooks/ , custom runtime hooks can be placed in /etc/initcpio/hooks/ . For any runtime hook, there should always be a build hook of the same name, which calls add_runscript to add the runtime hook to the image. These files are sourced by the busybox ash shell during early userspace. With the exception of cleanup hooks, they will always be run in the order listed in the HOOKS setting. Runtime hooks may contain several functions:

run_earlyhook : Functions of this name will be run once the API file systems have been mounted and the kernel command line has been parsed. This is generally where additional daemons, such as udev, which are needed for the early boot process are started from.

run_hook : Functions of this name are run shortly after the early hooks. This is the most common hook point, and operations such as assembly of stacked block devices should take place here.

run_latehook : Functions of this name are run after the root device has been mounted. This should be used, sparingly, for further setup of the root device, or for mounting other file systems, such as /usr .

run_cleanuphook : Functions of this name are run as late as possible, and in the reverse order of how they are listed in the HOOKS array in the configuration file. These hooks should be used for any last minute cleanup, such as shutting down any daemons started by an early hook.

Common hooks

A table of common hooks and how they affect image creation and runtime follows. Note that this table is not complete, as packages can provide custom hooks.

This article or section needs expansion.

busybox init	systemd init	Build hook	Runtime hook (busybox init only)
base		Sets up all initial directories and installs base utilities and libraries. Always keep this hook as the first hook unless you know what you are doing, as it provides critical busybox init when not using systemd hook. Provides a busybox recovery shell when using systemd hook.

– udev systemd Adds udevd, udevadm, and a small subset of udev rules to your image. Starts the udev daemon and processes uevents from the kernel; creating device nodes. As it simplifies the boot process by not requiring the user to explicitly specify necessary modules, using it is recommended. usr Adds support for /usr on a separate partition. See #/usr as a separate partition for details. Mounts the /usr partition after the real root has been mounted. resume – Tries to resume from the «suspend to disk» state. See Hibernation for further configuration. btrfs — Sets the required modules to enable Btrfs for using multiple devices with Btrfs. You need to have btrfs-progs installed to use this. This hook is not required for using Btrfs on a single device. Runs btrfs device scan to assemble a multi-device Btrfs root file system when udev hook or systemd hook is not present. The btrfs-progs package is required for this hook. autodetect Shrinks your initramfs to a smaller size by creating a whitelist of modules from a scan of sysfs. Be sure to verify included modules are correct and none are missing. This hook must be run before other subsystem hooks in order to take advantage of auto-detection. Any hooks placed before ‘autodetect’ will be installed in full. – modconf Includes modprobe configuration files from /etc/modprobe.d/ and /usr/lib/modprobe.d/ . – block Adds all block device modules, formerly separately provided by the fw, mmc, pata, sata, scsi, usb, and virtio hooks. – net not implemented Adds the necessary modules for a network device. You must have mkinitcpio-nfs-utils installed to use this, see #Using net for details. Provides handling for an NFS-based root file system. dmraid ? Provides support for fakeRAID root devices. You must have dmraid installed to use this. Note that it is preferred to use mdadm with the mdadm_udev hook with fakeRAID if your controller supports it. See #Using RAID for details. Locates and assembles fakeRAID block devices using dmraid . mdadm_udev Provides support for assembling RAID arrays via udev. You must have mdadm installed to use this. If you use this hook with a FakeRAID array, it is recommended to include mdmon in BINARIES . See #Using RAID for details. – keyboard Adds the necessary modules for keyboard devices. Use this if you have an USB or serial keyboard and need it in early userspace (either for entering encryption passphrases or for use in an interactive shell). As a side effect, modules for some non-keyboard input devices might be added too, but this should not be relied on. Supersedes old usbinput hook. – keymap sd-vconsole Adds the specified keymap(s) from /etc/vconsole.conf to the initramfs. If you use system encryption, especially full-disk encryption, make sure you add it before the encrypt hook. Loads the specified keymap(s) from /etc/vconsole.conf during early userspace. consolefont Adds the specified console font from /etc/vconsole.conf to the initramfs. Loads the specified console font from /etc/vconsole.conf during early userspace. encrypt sd-encrypt Adds the dm_crypt kernel module and the cryptsetup tool to the image. You must have cryptsetup installed to use this. Detects and unlocks an encrypted root partition. See #Runtime customization for further configuration. lvm2 Adds the device mapper kernel module and the lvm tool to the image. You must have lvm2 installed to use this. This is necessary if you have your root file system on LVM. – fsck Adds the fsck binary and file system-specific helpers to allow running fsck against your root device (and /usr if separate) prior to mounting. If added after the autodetect hook, only the helper specific to your root file system will be added. Usage of this hook is strongly recommended, and it is required with a separate /usr partition. It is highly recommended that if you include this hook that you also include any necessary modules to ensure your keyboard will work in early userspace.
The use of this hook requires the rw parameter to be set on the kernel command line (discussion). See fsck#Boot time checking for more details. – filesystems This includes necessary file system modules into your image. This hook is required unless you specify your file system modules in MODULES . –

COMPRESSION

The kernel supports several formats for compression of the initramfs: gzip , bzip2 , lzma, xz , lzo , lz4 and zstd . mkinitcpio uses zstd compressed images by default, note that the zstd compression runs in multi-threading mode (with the -T0 option which spawns as many threads as detected cores).

The provided mkinitcpio.conf has the various COMPRESSION options commented out. Uncomment one if you wish to switch to another compression method and make sure you have the corresponding compression utility installed. If none is specified, the zstd default method is used. If you wish to create an uncompressed image, specify COMPRESSION=cat in the config file or use -z cat on the command line.

COMPRESSION_OPTIONS

These are additional flags passed to the program specified by COMPRESSION , such as:

Runtime customization

This article or section needs expansion.

Runtime configuration options can be passed to init and certain hooks via the kernel command line. Kernel command-line parameters are often supplied by the bootloader. The options discussed below can be appended to the kernel command line to alter default behavior. See Kernel parameters and Arch boot process for more information.

init from base hook

See Boot debugging and mkinitcpio(8) for other parameters.

Using RAID

Using net

net requires the mkinitcpio-nfs-utils package.

Comprehensive and up-to-date information can be found in the official kernel documentation.

This parameter tells the kernel how to configure IP addresses of devices and also how to set up the IP routing table. It can take up to nine arguments separated by colons: ip= : : : : : :: : .

If this parameter is missing from the kernel command line, all fields are assumed to be empty, and the defaults mentioned in the kernel documentation apply. In general this means that the kernel tries to configure everything using autoconfiguration.

For parameters explanation, see the kernel documentation.

If you have multiple network cards, this parameter can include the MAC address of the interface you are booting from. This is often useful as interface numbering may change, or in conjunction with pxelinux IPAPPEND 2 or IPAPPEND 3 option. If not given, eth0 will be used.

If the nfsroot parameter is NOT given on the command line, the default /tftpboot/%s will be used.

Run mkinitcpio -H net for parameter explanation.

Using LVM

Using encrypted root

If using an encrypted root see dm-crypt/System configuration#mkinitcpio for detailed information on which hooks to include.

/usr as a separate partition

If you keep /usr as a separate partition, you must adhere to the following requirements:

• Add the fsck hook, mark /usr with a passno of 2 in /etc/fstab to run the check on the partition at startup. While recommended for everyone, it is mandatory if you want your /usr partition to be fsck’ed at boot-up. Without this hook, /usr will never be fsck’d.
• If not using the systemd hook, add the usr hook. This will mount the /usr partition after root is mounted.

Troubleshooting

Extracting the image

If you are curious about what is inside the initramfs image, you can extract it and poke at the files inside of it.

The initramfs image is an SVR4 CPIO archive, generated via the find and bsdcpio commands, optionally compressed with a compression scheme understood by the kernel. For more information on the compression schemes, see #COMPRESSION.

mkinitcpio includes a utility called lsinitcpio which will list and/or extract the contents of initramfs images.

You can list the files in the image with:

And to extract them all in the current directory:

You can also get a more human-friendly listing of the important parts in the image:

Recompressing a modified extracted image

Invoke the build_image function of the /usr/bin/mkinitcpio script with parameters

It can be done by creating a new script with the contents of the build_image function and running it with the above parameters. This will compress the contents present in the current directory in a file named outfile .

«/dev must be mounted» when it already is

The test used by mkinitcpio to determine if /dev is mounted is to see if /dev/fd/ is there. If everything else looks fine, it can be «created» manually by:

(Obviously, /proc must be mounted as well. mkinitcpio requires that anyway, and that is the next thing it will check.)

Possibly missing firmware for module XXXX

When initramfs are being rebuild after a kernel update, you might get these or similar warnings:

These appear to most Arch Linux users, as the firmware is not included in the linux-firmware package. If you do not use hardware which uses these firmwares you can safely ignore this message. Currently, the only solution for suppressing warnings for wd719x and aic94xx modules is actually installing firmware packages for them. For aic94xx, install aic94xx-firmware AUR . For wd719x, install wd719x-firmware AUR . For xhci_pci, install upd72020x-fw AUR . See related discussion here.

Most common firmware files can be acquired by installing the linux-firmware package. For other packages proving firmware, try searching for the module name in the official repositories or AUR.

No PS/2 controller found

On some motherboards (mostly ancient ones, but also a few new ones), the i8042 controller cannot be automatically detected. It is rare, but some people will surely be without keyboard. You can detect this situation in advance. If you have a PS/2 port and get i8042: PNP: No PS/2 controller found. Probing ports directly message, add atkbd to the MODULES array.

Standard rescue procedures

With an improper initial ram-disk a system often is unbootable. So follow a system rescue procedure like below:

Boot succeeds on one machine and fails on another

mkinitcpio’s autodetect hook filters unneeded kernel modules in the primary initramfs scanning /sys and the modules loaded at the time it is run. If you transfer your /boot directory to another machine and the boot sequence fails during early userspace, it may be because the new hardware is not detected due to missing kernel modules. Note that USB 2.0 and 3.0 need different kernel modules.

To fix, first try choosing the fallback image from your bootloader, as it is not filtered by autodetect . Once booted, run mkinitcpio on the new machine to rebuild the primary image with the correct modules. If the fallback image fails, try booting into an Arch Linux live CD/USB, chroot into the installation, and run mkinitcpio on the new machine. As a last resort, try manually adding modules to the initramfs.

Источник