↓ 02 – EasyBCD | Free Personal
Take control of your boot loader, EasyBCD supercharges your Windows PC, allowing you to dual-boot to your heart’s content. Also boot into legacy systems Microsoft doesn’t support: MS-DOS, Windows 9x, Windows ME, and Windows 2000!
EasyBCD is geared for users of all kinds. Whether you just want to add an entry to your old XP partition or want to create a duplicate for testing purposes; if you’re interested in debugging the Windows Kernel or septuple-booting your seven test operating systems, EasyBCD is the key.
- Boot anything – Windows, Linux, macOS, & BSD! Boot both from and into USB drives, ISO images, virtual disks, and more.
- Boot anywhere – Create bootable USB sticks with repair utilities that you can take with you anywhere.
- Protect against disaster – Create entries to boot into recovery utilities or safe mode to prepare for a rainy day.
- Painless editing – Add, rename, remove, configure, and reorder entries at whim.
- Solve difficult problems – Use EasyBCD to troubleshoot Windows, back up and repair the bootloader, and more.
- Powerful scripting with NeoGrub – You’ll have the power to hide partitions, change active flags, and create complex boot scenarios.
Step 5) Create & format Linux partitions
Next, we are going to partition our hard drive and create some Linux partitions. An easy way of doing this is using the cfdisk utility. Run the command:
# cfdisk
This displays all the partitions available including Windows partitions.
As you can see, we have some free space of 19.5G that we created earlier in step 1 from shrinking drive C on the Windows side. Using this partition, we shall create the following Linux partitions :
- Root partition / 12G
- swap partition 4G
To achieve this, we will navigate to the free space with 19.5G just after /dev/sda3 volume and hit ENTER. We will then specify the volume as 12G for the root partition as shown below. Then hit ENTER.
The root partition will be created with the Linux filesystem type as shown.
Next, we will create another partition for swap. Using the same method, we will proceed to the remaining free partition of 7G and select the ‘New’ option.
Specify the partition size as 4G
Since this will be our swap partition, we need to go the extra step and modify the partition type. Therefore, we will select the ‘type’ option and hit ENTER.
In the list that appears, select ‘Linux Swap’ and hit ENTER.
At this point, both the root and Linux swap partitions are created as seen from the partition table below.
To save the partitions, select the ‘Write’ option and hit ENTER.
When prompted if you want to write the partition to disk, simply type ‘yes’ and hit ENTER.
To exit cfdisk utility, select the ‘Quit’ option and hit ENTER.
Partitoning
Run to see all of our storage device names.
This should be totally different on a Windows laptop.
The image above should look totally different from what would be on hardware. It might be ‘sda’ or ‘nvme0n1’ depending on what storage device you have:
nvme0n1 disk|--nvme0n1p1 part|--nvme0n1p2 part|--nvme0n1p3 part|--nvme0n1p4 part
You will want to run or to see which part is labeled the EFI System. This should be your Window’s EFI partition, remember these commands as we will need to reference these parts throughout partitioning our system.
Run , where block_device should be your storage’s partition system name. Note: If your storage is GPT, you will run . Otherwise, you will run . You will get an error telling you it’s not GPT if you’re mismatching your storage type. Reference for more info on block device names.
Arrow keys to move around the bottom menu
The images above show how to partition 1 section for EFI. I will be going with 3 sections:
- Linux EFI Partition
- Linux Root Partition (your main folder/drive essentially)
- Linux Swap
Usually people just go with Boot and Root, but I chose this setup for my laptop because I might use hibernate sometimes, so I need swap and a separate EFI from Windows to avoid any corruption during hibernation. You can check out the partition codes for cgdisk . You will want to go through these 3 setups:
- EFI: first sector: blank, size: , guid: , name:
- Swap: first sector: blank, size: (or your ram size), guid: , name:
- Root: first sector: blank, size: blank (fills all the way), guid: blank, name:
Just imagine having extra partitions on the top of these, which should be your Windows partition. So our Linux partitions should be EFI system, Linux swap, and Linux filesystem.
Use fdisk -l to check your partitions types
Be sure to triple check that everything is correct, because if you write over a windows partition, you will need to recover the disk as there will be no working OS on the drive anymore. Once you have those 3 partitions with the correct settings, select , ‘yes’, then . Congrats for making this far, the hardest part is over.
Firmware
Dual booting is not just a matter of software. Or, it is, but it involves changing your firmware, which among other things tells your machine how to begin the boot process. Here are some firmware-related issues to keep in mind.
UEFI vs. BIOS
Before attempting to install, make sure your firmware configuration is optimal. Most computers sold today have a new type of firmware known as Unified Extensible Firmware Interface (UEFI), which has pretty much replaced the other firmware known as Basic Input Output System (BIOS), which is often included through the mode many providers call Legacy Boot.
Secure Boot
One other important setting is Secure Boot. This feature detects whether the boot path has been tampered with, and stops unapproved operating systems from booting. For now, I disabled this option to ensure that I could install Fedora Linux. According to the Fedora Project Wiki Features/Secure Boot Fedora Linux will work with it enabled. This may be different for other Linux distributions —I plan to revisit this setting in the future.
In short, if you find that you cannot install your Linux OS with this setting active, disable Secure Boot and try again.
UEFI variables
UEFI defines variables through which an operating system can interact with the firmware. UEFI boot variables are used by the boot loader and used by the OS only for early system start-up. UEFI runtime variables allow an OS to manage certain settings of the firmware like the UEFI boot manager or managing the keys for UEFI Secure Boot protocol etc. You can get the list using:
$ efivar --list
UEFI variables support in Linux kernel
Linux kernel exposes UEFI variables data to userspace via efivarfs (EFI VARiable FileSystem) interface () — mounted using kernel module at — it has no maximum per-variable size limitation and supports UEFI Secure Boot variables. Introduced in kernel 3.8.
Requirements for UEFI variable support
- Kernel should be booted in UEFI mode via EFISTUB (optionally using a boot manager) or by a UEFI boot loader, not via BIOS or CSM, or Apple’s Boot Camp which is also a CSM.
- EFI Runtime Services support should be present in the kernel (, check if present with ).
- EFI Runtime Services in the kernel SHOULD NOT be disabled via kernel cmdline, i.e. kernel parameter SHOULD NOT be used.
- filesystem should be mounted at , otherwise follow section below.
- should list (option /) the UEFI variables without any error.
If UEFI Variables support does not work even after the above conditions are satisfied, try the below workarounds:
- If listing of the UEFI variables () leads to and the system is booted into a realtime kernel, add to the kernel parameters and reboot (efivarfs functionality is disabled by default on those kernels).
- If any userspace tool is unable to modify UEFI variable data, check for existence of files. If they exist, delete them, reboot and retry again.
- If the above step does not fix the issue, try booting with kernel parameter to disable kernel UEFI variable storage space check that may prevent writing/modification of UEFI variables.
Mount efivarfs
If is not automatically mounted at by systemd during boot, then you need to manually mount it to expose UEFI variables to like efibootmgr:
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
Note: The above command should be run both outside (before) and inside the chroot, if any.
Userspace tools
There are few tools that can access/modify the UEFI variables, namely
efivar — Library and Tool to manipulate UEFI variables (used by efibootmgr)
efibootmgr — Tool to manipulate UEFI Firmware Boot Manager Settings
uefivars — Dumps list of UEFI variables with some additional PCI related info (uses efibootmgr code internally)
efitools — Tools for manipulating UEFI secure boot platforms
Ubuntu’s Firmware Test Suite — Test suite that performs sanity checks on Intel/AMD PC firmware
efibootmgr
You will have to install the package.
Note:
- If efibootmgr does not work on your system, you can reboot into and use to create a boot entry for the bootloader.
- If you are unable to use , some UEFI firmwares allow users to directly manage UEFI boot entries from within its boot-time interface. For example, some firmwares have an «Add New Boot Option» choice which enables you to select a local EFI system partition and manually enter the EFI application location e.g. .
- The below commands use rEFInd boot manager as example.
To add a new boot option using efibootmgr you need to know three things:
- The disk containing the EFI system partition (ESP). E.g.: , .
- The partition number of the ESP on that disk. The in or .
- The path to the EFI application (relative to the root of the ESP)
For example, if you want to add a boot option for where is the mount point of the ESP, run
$ findmnt /efi
TARGET SOURCE FSTYPE OPTIONS /efi /dev/sda1 vfat rw,flush,tz=UTC
In this example, this indicates that the ESP is on disk and has partition number 1. The path to the EFI application relative to the root of the ESP is . So you would create the boot entry as follows:
# efibootmgr --create --disk /dev/sda --part 1 --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager" --verbose
# efibootmgr --create --disk /dev/nvme0n1p1 --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager" --verbose
Note: UEFI uses backward slash as path separator but efibootmgr automatically converts UNIX-style path separators.
Disable UEFI variable access
So, as the UEFI variables access is not required for daily system usage, you may want to disable it, to avoid potential security breaches or accidental harm.
Possible solutions are:
- Mount in read-only mode using fstab. For example:
efivarfs /sys/firmware/efi/efivars efivarfs ro,nosuid,nodev,noexec 0 0
- Use the kernel parameter to completely disable OS access to UEFI.
Note: UEFI cannot be used with a such setup, so perform the all necessary configurations before. Also UEFI-related commands (e.g. ) will not work either.
UEFI firmware bitness
Under UEFI, every program whether it is an OS loader or a utility (e.g. a memory testing app or recovery tool), should be a EFI application corresponding to the UEFI firmware bitness/architecture.
An x86_64 UEFI firmware does not include support for launching 32-bit EFI applications (unlike x86_64 Linux and Windows versions which include such support). Therefore the EFI application must be compiled for that specific firmware processor bitness/architecture.
Note: The official ISO does not support booting on 32-bit (IA32) UEFI systems, see for available workarounds. The installed system will require using a boot loader that supports IA32 UEFI, for example, GRUB with the target.
From Linux
On distributions running Linux kernel 4.0 or newer, the UEFI firmware bitness can be found via the sysfs interface. Run:
$ cat /sys/firmware/efi/fw_platform_size
It will return for a 64-bit (x86_64) UEFI or for a 32-bit (IA32) UEFI. If the file does not exist, then you have not booted in UEFI mode.
From macOS
Pre-2008 Macs mostly have IA32 EFI firmware while >=2008 Macs have mostly x86_64 EFI. All Macs capable of running Mac OS X Snow Leopard 64-bit Kernel have x86_64 EFI 1.x firmware.
To find out the arch of the EFI firmware in a Mac, type the following into the Mac OS X terminal:
$ ioreg -l -p IODeviceTree | grep firmware-abi
If the command returns then it is IA32 (32-bit) EFI firmware. If it returns then it is x86_64 EFI firmware. Most of the Macs do not have UEFI 2.x firmware as Apple’s EFI implementation is not fully compliant with UEFI 2.x specification.
From Microsoft Windows
64-bit versions of Windows do not support booting on a 32-bit UEFI. So, if you have a 32-bit version of Windows booted in UEFI mode, you have a 32-bit UEFI.
To check the bitness run . In the System Summary section look at the values of «System Type» and «BIOS mode».
For a 64-bit Windows on a 64-bit UEFI it will be and , for a 32-bit Windows on a 32-bit UEFI — and . If the «BIOS mode» is not , then Windows is not booted in UEFI mode.
Checking Secure Boot status
Before booting the OS
At this point, one has to look at the firmware setup. If the machine was booted and is running, in most cases it will have to be rebooted.
You may access the firmware configuration by pressing a special key during the boot process. The key to use depends on the firmware. It is usually one of , , or possibly another key. Sometimes the right key is displayed for a short while at the beginning of the boot process. The motherboard manual usually records it. You might want to press the key, and keep pressing it, immediately following powering on the machine, even before the screen actually displays anything.
After entering the firmware setup, be careful not to change any settings without prior intention. Usually there are navigation instructions, and short help for the settings, at the bottom of each setup screen. The setup itself might be composed of several pages. You will have to navigate to the correct place. The interesting setting might be simply denoted by secure boot, which can be set on or off.
After booting the OS
An easy way to check Secure Boot status on systems using systemd is to use systemd-boot:
Note: There is no need to be using systemd-boot as your boot manager for this command to work, it is more akin to the others *ctl systemd utilities (localectl, timedatectl…) and won’t touch your configuration.
$ bootctl status
System:
Firmware: UEFI 2.70 (American Megatrends 5.15)
Secure Boot: enabled
Setup Mode: user
Boot into FW: supported
...
The factual accuracy of this article or section is disputed.
Another way to check whether the machine was booted with Secure Boot is to use this command:
$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot*
If Secure Boot is enabled, this command returns as the final integer in a list of five, for example:
6 0 0 0 1
Note, however, that the kernel may be unaware of Secure Boot (even if it is enabled in the firmware) if an insufficiently capable boot loader is used. This can be verified by checking the kernel messages shortly after the system starts up:
# dmesg | grep -i secure
Secure boot disabled Secure boot could not be determined
The kernel messages will otherwise read .
BIOS
Next you will want to make sure your bios firmware is up to date. The method to update it will depend on your manufacturer, but typically you will have some kind of program preinstalled to be able to do it. If not, then check their official site for their latest bios firmware. With the bios updated, restart the PC and go into bios (usually F2 or del, depending on your laptop). In the bios, you want to do 2 things:
- Disable Secure Boot
- Change the storage to UEFI mode
Every bios is a little different, so the method to change these options will vary. Do not worry if you cannot find the UEFI mode option, we can fix that during our Arch install.
↓ 01 – Grub2Win | Free
Grub2Win supports 64 and 32 bit EFI and BIOS on Windows 10, 8, 7 and XP. Safely dual boot Windows and Linux from GPT or MBR disks. Grub2Win boots native GNU Grub version 2 code. Everything is contained in a single 20 MB directory on your Windows C: drive. On EFI systems a few small modules are installed to your EFI partition.
Using the simple Windows GUI and instructions you can install Grub2Win quickly and safely. Select from many OS choices. Supports Antergos, Android, Ubuntu, Debian, Suse, Fedora, Mint, Clover and Windows. Also boots ISO files. You can enter your own custom commands for each menu entry.
- Supports 64 and 32 bit EFI as well as BIOS firmware.
- Installs to Windows 10, 8, 7 and XP.
- Requires just one directory on the Windows C: drive, about 20 MB disk space.
- Simple Windows GUI easily sets up Grub2Win in seconds.
- Lets you set your EFI firmware boot order from within Windows.
- Preview and customize the 9 included graphic background themes.
- Works with all filesystems including Mac hfs and Btrfs.
- Can search for and boot a partition by it’s label. Supports advanced scripting.
- Works with both GPT and MBR disks – up to 128 primary partitions per drive.
- Supports extremely large (over 40 TB) disks and partitions.
- Safely multiboot Windows, Antergos, Android, Ubuntu, Debian, Suse, Fedora, Mint, Clover and more.
- Grub customization is done from Windows – Configuration in Linux is not required.
Create an UEFI System Partition in Linux
Note: The UEFISYS partition can be of any size supported by FAT32 filesystem.According to Microsoft Documentation, the minimum partition/volume size for FAT32 is 512 MiB. Therefore it is recommended for UEFISYS partition to be at least 512 MiB.Higher partition sizes are fine, especially if you use multiple UEFI bootloaders, or multiple OSes booting via UEFI, so that there is enough space to hold all the related files.If you are using Linux EFISTUB booting, then you need to make sure there is adequate space available for keeping the Kernel and Initramfs files in the UEFISYS partition.
For GPT partitioned disks
Two choices:
- Using GNU Parted/GParted: Create a FAT32 partition. Set «boot» flag on for that partition.
- Using GPT fdisk (aka gdisk): Create a partition with gdisk type code «EF00». Then format that partition as FAT32 using
Note: Setting «boot» flag in parted in a MBR partition marks that partition as active, while the same «boot» flag in a GPT partition marks that partition as «UEFI System Partition».
Warning: Do not use util-linux fdisk, cfdisk or sfdisk to change the type codes in a GPT disk. Similarly do not use gptfdisk gdisk, cgdisk or sgdisk on a MBR disk, it will be automatically converted to GPT (no data loss will occur, but the system will fail to boot).
For MBR partitioned disks
Two choices:
- Using GNU Parted/GParted: Create FAT32 partition. Change the type code of that partition to 0xEF using fdisk, cfdisk or sfdisk.
- Using fdisk: Create a partition with partition type 0xEF and format it as FAT32 using
Note: It is recommended to use always GPT for UEFI boot as some UEFI firmwares do not allow UEFI-MBR boot.
Подготовка
- Качаем дистр Arch linux Yandex mirror
-
Заливаем на флешку:
- Загружаем машину с флешки и по шагам:
1. Разбиваем хард на разделы:
На выходе необходимо получить примерно следующую структуру с указанными типами Ф.С.:
| Порядок | Описание | Раздел | Размер | Тип |
|---|---|---|---|---|
| 1 | ESP | /dev/sda1 | 1Gib | EFI System |
| 2 | /dev/sda2 | 340GiB | Linux Filesystem | |
| 3 | /home | /dev/sda3 | 340GiB | Linux Filesystem |
| 4 | SWAP | /dev/sda4 | 16GiB | Linux Swap |
2. Создаем Файловые системы на созданных разделах
UEFI раздел FAT32:
Корневой раздел EXT4:
Домашний раздел EXT4:
Раздел подкачки:
создаем его :
Подробнее здесь: ArchWiki Partitionig (Русский)
3. Монтируем Файловые системы
Монтируем корневой раздел в /mnt
Создаем директорию /boot и /home для загрузчика и домашнего раздела:
Монтируем UEFI раздел
Монтируем домашний раздел
Монтируем раздел подкачки :
4. Поднимаем сеть WiFi
Выбираем свою точку доступа и подрубаемся к ней <ИМЯ_ИНТЕРФЕЙСА> может быть например таким
wlp0s21f0u7i2:
Проверяем:
Если сети нет, то выясняем имя беспроводного интерфейса:
И поднимаем его принудительно:
5. Разворачиваем систему из репозитория
- В файле /etc/pacman.d/mirrorlist перемещаем адреса российский серверов в самый верх.
Ну, или можно сделать как здесь: ArchWiki Mirrors (Русский) -
Выполняем скрипт инициализации системы, указав ему :
- Для поддержки беспроводной сети на мой взгляд лучше использовать NetworkManager
ArchWiki NetworkManager (Русский) т.к он прост в обращении и под него реально
найти апплеты для гуевого рабочего стола. Итак укажем установщику дополнительно
установить пакеты: networkmanager, dialog, wpa_supplicant:
6. Делаем снимок точек монтирования в файл fstab
«Запечем» правила монтирования файловых систем в файл:
И обновляем данные пакетного менеджера и установленные утилиты:
8. Создадим загрузочную запись для UEFI менеджера загрузки
Необходимо поправить файл загрузчика: /boot/loader/loader.conf что бы он принял следующий вид:
Кстати этот файл в арче копируется с шаблона:
После можно проверить что наша запись с ArchLinux появилась:
Необходимо так же на случай обновления systemd разместить следующий pacman hook
в каталоге /etc/pacman.d/hooks/:
Подробнее про описанное выше здесь: ArchWiki systemd-boot (Русский)
9. Завершение установки
Теперь можно задать пароль для рута
создать дополнительных пользователей и пр.
После этого выходим из окружения и перезагружаем систему
Вытаскиваем флешку, меняем устройство загрузки и грузим новую систему.
Create the partition
The following two sections show how to create an EFI system partition (ESP).
Warning: The EFI system partition must be a physical partition in the main partition table of the disk, not under LVM or software RAID etc.
The partition size should provide adequate space for storing boot loaders and other files required for booting.
GPT partitioned disks
EFI system partition on a GUID Partition Table is identified by the .
Choose one of the following methods to create an ESP for a GPT partitioned disk:
- fdisk: Create a partition with partition type .
- gdisk: Create a partition with partition type .
- GNU Parted: Create a partition with as the file system type and set the flag on it.
After creating the partition, it should be formatted with a file system. Proceed to the section below.
MBR partitioned disks
Note:
- It is recommended to use GPT since some firmwares might not support UEFI/MBR booting due to it not being supported by Windows Setup.
See also for the advantages of GPT in general.
EFI system partition on a Master Boot Record partition table is identified by the partition type ID .
Choose one of the following methods to create an ESP for a MBR partitioned disk:
- fdisk: Create a primary partition with partition type .
- GNU Parted: Create a primary partition with as the file system type and set the flag on it.
After creating the partition, it should be formatted with a file system. Proceed to the section below.
Partitioning the boot drive
If you choose to dual boot and have both operating systems on the same drive, you have to break it into partitions. Even if you dual boot using two different drives, most Linux installations are best broken into a few basic partitions for a variety of reasons. Here are some options to consider.
GPT vs MBR
If you decide to manually partition your boot drive in advance, I recommend using the GUID Partition Table (GPT) rather than the older Master Boot Record (MBR). Among the reasons for this change, there are two specific limitations of MBR that GPT doesn’t have:
- MBR can hold up to 15 partitions, while GPT can hold up to 128.
- MBR only supports up to 2 terabytes, while GPT uses 64-bit addresses which allows it to support disks up to 8 million terabytes.
If you have shopped for hard drives recently, then you know that many of today’s drives exceed the 2 terabyte limit.
The EFI system partition
If you are doing a fresh installation or using a new drive, there are probably no partitions to begin with. In this case, the OS installer will create the first one, which is the EFI System Partition (ESP). If you choose to manually partition your drive using a tool such as gdisk, you will need to create this partition with several parameters. Based on the existing ESP, I set the size to around 500MB and assigned it the ef00 (EFI System) partition type. The UEFI specification requires the format to be FAT32/msdos, most likely because it is supportable by a wide range of operating systems.
Booting an OS using UEFI
UEFI firmware does not support booting through the above mentioned method which is the only way supported by BIOS. UEFI has support for reading both the partition table as well as understanding filesystems.
The commonly used UEFI firmwares support both MBR and GPT partition table. EFI in Apple-Intel Macs are known to support Apple Partition Map also apart from MBR and GPT. Most of the UEFI firmwares have support for accessing FAT12 (floppy disks) , FAT16 and FAT32 filesystems in HDD and ISO9660 (and UDF) in CD/DVDs. EFI in Apple-Intel Macs can access HFS/HFS+ filesystems also apart from the mentioned ones.
UEFI does not launch any boot code in the MBR whether it exists or not. Instead it uses a special partition in the partition table called «EFI SYSTEM PARTITION» in which files required to be launched by the firmware are stored. Each vendor can store its files under <EFI SYSTEM PARTITION>/EFI/<VENDOR NAME>/ folder and can use the firmware or its shell (UEFI shell) to launch the boot program. An EFI System Partition is usually formatted as FAT32.
Under UEFI, every program whether they are OS loaders or some utilities (like memory testing apps) or recovery tools outside the OS, should be a UEFI Application corresponding to the EFI firmware architecture. Most of the UEFI firmware in the market, including recent Apple Macs use x86_64 EFI firmware. Only some older macs use i386 EFI firmware while no non-Apple UEFI system is known to use i386 EFI firmware.
Note: Some older Intel Server boards are known to operate on Intel EFI 1.10 firmware, and require i386 EFI applications.
A x86_64 EFI firmware does not include support for launching 32-bit EFI apps unlike the 64-bit Linux and Windows which include such support. Therefore the bootloader must be compiled for that architecture correctly.
Multibooting on 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 UEFI application corresponding to the particular OS’s bootloader. This removes the need for relying on chainloading mechanisms of one bootloader to load another to switch OSes.
Linux Windows x86_64 UEFI-GPT Multiboot
Windows Vista (SP1+) and 7 pr 8 x86_64 versions support booting natively using UEFI firmware. But for this they need GPT partitioning of the disk used for UEFI booting.Windows x86_64 versions support either UEFI-GPT booting or BIOS-MBR booting.Windows 32-bit versions support only BIOS-MBR booting. Follow the instructions provided in the forum link given in the references sections as to how to do this. Seehttp://support.microsoft.com/default.aspx?scid=kb;EN-US;2581408 for more info.
This limitation does not exist in Linux Kernel but rather depends on the bootloader used.For the sake of Windows UEFI booting, the Linux bootloader used should also be installed in UEFI-GPT mode if booting from the same disk.
initramfs
перемещает ядро и имеющиеся файлы initramfs в память и запускает ядро. В начале работы ядро распаковывает архивы с initramfs (initial RAM filesystem, начальная файловая система) в пока что пустующую rootfs (первоначальная корневая файловая система, чаще всего ramfs или tmpfs). Сначала извлекается initramfs, которая была встроена в двоичный файл ядра в процессе сборки, а затем — внешние initramfs-файлы, если таковые имеются. Файлы внешней initramfs перезаписывают одноименные файлы встроенной. После этого ядро запускает в rootfs как первый процесс. Начинается раннее пространство пользователя (early userspace).
Arch Linux используют в качестве встроенной initramfs пустой архив (используется по умолчанию при сборке Linux). Внешние образы initramfs можно сгенерировать с помощью mkinitcpio, dracut и booster.
Назначение initramfs — загрузить систему до состояния, в котором она может работать с корневой файловой системой (подробнее см. FHS). Это означает, что любые модули, которые необходимы устройствам IDE, SCSI, SATA, USB/FW (при загрузке с внешнего носителя) и не были встроены в ядро, должны загружаться из initramfs; после подключения необходимых модулей (программой/сценарием или неявно udev), процесс загрузки продолжается. В initramfs должны быть только модули, необходимые для доступа к корневой файловой системе; нет необходимости хранить в ней все модули, которые однажды теоретически могут понадобиться. Большинство таких модулей будут позже загружены менеджером устройств udev во время работы процесса init.
