What were the reasons for :enos: to choose `dracut` over `mkinitcpio`?

Why was dracut chosen over mkinitcpio for :enos: installs?

I wanted to try a specific installation variant (for the curious: unchanged MSWindows EFI partition, fstab-less, kernel commandline-less install) which I couldn’t make to work with the standard installer and dracut. I finally succeeded with a plain Arch install (ugh) and mkinitcpio.

This made me think: What were the reasons to choose dracut over mkinitcpio?

To clarify: I’m not questioning the decision. dracut seems to be the new systemd, so to speak – you have to get used to it since it’s the future, even if it is more complex than the older system.

1 Like

Here was the reason as presented in our release notes last December (when we made the switch)

Dracut in general has seen increased usage over wide variety of distros including Fedora, RHEL, Gentoo, and Debian

mkinitcpio is an arch project and isn’t as universal as Dracut.

Maybe @dalto can chime in more as he is more knowledgeable on the topic


It requires less effort to create ISO images. EndeavourOS is run by a small team which is already overworked, so anything that streamlines and simplifies their task is beneficial.

Personally, I prefer mkinitcpio as I’m more familiar with it, but just because Dracut is the default, nothing prevents me or anyone else from using mkinitcpio with EndeavourOS. EndeavourOS is still Arch under the hood.


dracut has several advantages:

  • It requires less manual configuration. It can autodetect more by default and usually β€œjust works”.
  • It automatically includes the microcode in the initrd which makes it both more standard and easier to dual-boot other Linux distros.
  • In many cases, it decreases the boot time by a small amount. Depending on how much of a boot time fanatic you are, this may or may not matter to you.

Can you elaborate?
It made me wonder… :thinking:

Sure. Since you are an ISO tester, I hope I can be more terse:


The most important thing is to have systemd in the initramfs so that we can use systemd-gpt-autogenerator. I use mkinitcpio with the following hooks line:

HOOKS=(systemd autodetect modconf kms keyboard keymap block filesystems fsck)
cat /etc/fstab

# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>

It wasn’t existing before the restart, but some cheeky script or service seems to have regenerated an empty /etc/fstab. Good enough for me.

sudo cat /boot/loader/entries/arch.conf

title   Arch Linux
linux   /vmlinuz-linux
initrd  /intel-ucode.img
initrd  /initramfs-linux.img
options quiet loglevel=3

You can get by without the options, but for cosmetic reasons (clutter of bluetooth unrecognized command), I added these. Note the absence of any root=... stanza.


sudo gdisk -l /dev/sda
Disk /dev/sda: 3907029168 sectors, 1.8 TiB
Model: Samsung SSD 870 
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): BC298696-417A-412F-870A-0CE790682171
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2157 sectors (1.1 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          206847   100.0 MiB   EF00  EFI system partition
   2          206848          239615   16.0 MiB    0C01  Microsoft reserved ...
   3          239616       204802047   97.5 GiB    0700  Basic data partition
   4       204802048       205926399   549.0 MiB   2700  Windows RE
   5       205926400       206950399   500.0 MiB   EA00  XBOOTLDR partition
   6       206950400       215339007   4.0 GiB     8200  Linux swap
   7       215339008       267767807   25.0 GiB    8304  Linux x86-64 root (/)
   8       267767808       372625407   50.0 GiB    8302  Linux /home
   9       372625408      3907028991   1.6 TiB     8306  Linux /srv

This is how the system was set up. Note the specific Linux partitions (8304 instead of 8300 for an x86-64 root etc). See Poettering’s Linux Boot Partitions and How to Set Them Up (to work with systemd-gpt-auto-generator, available in every systemd install).

Setup itself was very easy, I just had to mount the partitions to their respective directories:

β”‚filesystemβ”‚typeβ”‚diskβ”‚usedβ”‚   use   β”‚freeβ”‚sizeβ”‚mount pointβ”‚
β”‚/dev/sda9 β”‚ext4β”‚SSD β”‚ 74Gβ”‚ 9% β–Œ    β”‚723Gβ”‚798Gβ”‚/srv       β”‚
β”‚/dev/sda8 β”‚ext4β”‚SSD β”‚2.8Gβ”‚ 5% β–Ž    β”‚ 50Gβ”‚ 53Gβ”‚/home      β”‚
β”‚/dev/sda7 β”‚ext4β”‚SSD β”‚4.2Gβ”‚16% β–Š    β”‚ 22Gβ”‚ 26Gβ”‚/          β”‚

sda       8:0    0 931.5G  0 disk 
β”œβ”€sda1    8:1    0   100M  0 part /efi
β”œβ”€sda2    8:2    0    16M  0 part 
β”œβ”€sda3    8:3    0  91.9G  0 part 
β”œβ”€sda4    8:4    0   773M  0 part 
β”œβ”€sda5    8:5    0   500M  0 part /boot
β”œβ”€sda6    8:6    0   7.3G  0 part [SWAP]
β”œβ”€sda7    8:7    0    25G  0 part /
β”œβ”€sda8    8:8    0    50G  0 part /home
└─sda9    8:9    0 755.9G  0 part /srv
nvme0n1 259:0    0   3.7T  0 disk 

The difference between dysk and lsblk is that the latter uses the cached data and dysk gets the info real-time, so it cannot see /boot and /efi which are only accessible for root. /dev/sda2 to /dev/sda4 are the MSWindows partitions.

After mounting, the rest of the install followed the Arch Install Guide.


  • Shorter boot time (gut feeling)
  • Clean system:
    System is not relying on UUID, Labels or device names.
    /etc/fstab can be used exclusively for added fixed storage.

I mount removable storage at login with the following snippet in


# mount unmounted disks with unspecified labels

for disk in /dev/disk/by-uuid/*; do
    if ! [[ $(lsblk -no FSTYPE $disk) =~ ^(swap|zfs-member)$ ]]; then
    findmnt $disk >/dev/null || udisksctl mount -b $disk

so everything has a separate section. System partitions are not visible, fixed storage is in /etc/fstab, removable stuff gets mounted to /run/media/user at login.

  • Easy backup and restore without adjustments in initrd and /etc/fstab for new UUIDs.
  • Lower possibility of screwups due to user errors, /boot and /efi are shielded.
  • No need to make the risky enlargement of the MSWindows-generated UEFI partition.


  • Only possible for first Linux system on disk
  • More complicated disk partioning

If only this would work with dracut. But the standard :enos: install won’t install kernels, they all end up in /dev/null (wtf?). Maybe @dalto can help here…

1 Like

That should definitely work with dracut.

The issue is that it isn’t supported by Calamares since it needs to manually mount the partitions to install into them. An easy work-around would be to use manual partitioning and then make the changes post-install. It should be pretty straightforward.


I have done this. The kernels end up nowhere. It’s not too difficult to mount the partitions post-install. I scratched my head and decided for the Arch install with mkinitcpio.

Likely an issue with manual partitioning setup. I would have to see what you did in manual partitioning or an installer log to know what was happening.

1 Like

I come back with this after the backup of the existing system.


I have now made an install with the :enos: installer and found several interesting things:

  • the installer doesn’t format an existing partition. It really deletes it and creates a new one with the same size. This resets the partition types. If you want a fat32 format, the installer sets the type of the XBOOTLDR partition to 0700 - Microsoft basic data.
  • during this process, the partition labels are set to <blank> if you don’t label them – gdisk -l /dev/sda doesn’t show the descriptions anymore for the new partitions.

I used gdisk via ssh to retype the partitions back to their original ones – see explanation post above for how they look (same install). After the installer did its thing, the β€˜name’ column from gdisk is empty for partitions 5-9, the newly created ones. This shows that the labels are not unset but set to <blank>.

Install log is at https://0x0.st/HYri.log .

After the install, the PC boots into the newly installed system. The /boot partition is empty. Kernel and initramfs end up in /efi, which is 99% full because of that. Lucky that the PC booted at all. This constraint might have made boot impossible in my first attempt to install this way.

Now I have two questions:

  • How do I get the kernel and the initramfs over to /boot in a way that they stay there for updates?
  • How do I configure dracut similar to the HOOKS line from mkinitcpio – see explanation post?
1 Like