Which hooks should mkinitcpio.conf have?

Hi all,

Which Hooks should /etc/mkinitcpio.conf be loaded with?

I read in /etc/default/grub that fsck can be skipped, for instance if GRUB_ROOT_FS_RO=true

# Uncomment to ensure that the root filesystem is mounted read-only so that
# systemd-fsck can run the check automatically. We use 'fsck' by default, which
# needs 'rw' as boot parameter, to avoid delay in boot-time. 'fsck' needs to be
# removed from 'mkinitcpio.conf' to make 'systemd-fsck' work.
# See also Arch-Wiki: https://wiki.archlinux.org/index.php/Fsck#Boot_time_checking

but I read in the link below that that’s not recommended:

Which hooks should, and which hooks should not be loaded in /etc/mkinitcpio.conf ?

It is really site-specific, but I believe the Manjaro default to be… :arrow_down:

HOOKS=(base udev autodetect modconf kms block keyboard keymap filesystems fsck)

Mine is a little different, but equivalent. :arrow_down:

HOOKS=(base systemd autodetect modconf kms block keyboard sd-vconsole filesystems)

I have /usr on a separate partition, and I am also using btrfs for almost all of my filesystems. btrfs does not require the fsck hook because it conducts its own filesystem integrity check at mount time.

Depending on when you last updated your system, there have been a few modifications to the default config, supplied as /etc/mkinitcpio.conf.pacnew. The idea of .pacnew files is that you would merge them in with your existing configuration if necessary, so check your filesystem for any .pacnew files. :arrow_down:

sudo updatedb && locate .pacnew
1 Like

Hi thanks!

That’s exactly how I got to this question; instead, I used sudo pacdiff to find and merge new configs. Maybe a small tip to try pacdiff instead :slight_smile:

In my mkinitcpio.conf.pacnew there was also the consolefont hook, do you recommend inserting that one as well?

my mkinitcpio.conf.pacnew HOOKS:

HOOKS=(base udev autodetect modconf kms keyboard keymap consolefont block filesystems fsck)

And my second side question: My partitions are /, /home, /var
Do you recommend putting /usr, /opt and /tmp in separate partitions as well and why?
And on that note; why don’t you call the usr hook in your mkinitcpio hooks?

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. 


If you’re using the udev hook instead of the systemd and sd-vconsole hooks, then yes.

Well, first of all, /tmp does not need a designated partition in Arch-based distributions, because the contents of /tmp reside on a tmpfs, which is a filesystem in virtual memory. Its contents live in RAM, albeit that they can get paged out to the swap device if necessary.

Is a separate /usr recommended? Well, this is a matter of personal preference. /usr is a static filesystem — its contents do not change during normal system operation. For this reason, having it separate from the root filesystem is always a good idea, because then if something happens that damages the root filesystem — e.g. a rogue process running with root privileges — the separate /usr filesystem is not affected.

Furthermore, having /usr on a separate partition and mounted read-only also allows it to be shared across the network, e.g. for booting and running diskless nodes.

The considerations with /opt are basically the same as with /usr, albeit that there’s one big difference: /opt does not have to be mounted at boot time, while /usr does.

Keeping /var separate is analogous to the above, but in reverse. /var is a dynamic filesystem; it contains data that gets modified all the time while the system is in normal operation, and new data is being added to it as well. Therefore it is not a bad idea to keep that separate from the root filesystem as well.

Should you do all of that? Well, like I said, it’s a matter of personal preference. If you want to maximize robustness and set up your system for the greatest UNIX-style flexibility and scalability, then it’s recommended, yes. For home use, it doesn’t matter all that much, and if you use the btrfs setup with bootable snapshots via GRUB, then /usr and /opt should be on the root filesystem, or else there’s no point in creating those snapshots — they only contain what’s on the @ subvolume.


That’s a very good question. :wink: If you’re using the systemd hook instead of the udev hook, mkinitcpio will automatically detect your configuration with a separate /usr and will thus include all the necessary modules for mounting /usr in early userspace. Therefore, the usr hook is not needed anymore. But if you use the udev hook when /usr is on a separate partition (or btrfs subvolume), then you do also need to add the usr hook.:wink:


You convinced me, I thought I was already safe with /var and /home and / in separate partitions. I will be making another partition for /usr

If this is an existing installation in which you are going to split off /usr, then do make sure you read my HowTo below. :arrow_down:

If on the other hand it’s a new installation, then make sure you modify /etc/mkinitcpio.conf and rebuild the initcpios for all of your kernels before rebooting, because Calamares does not set up the required hooks for a separate /usr partition or an @usr btrfs subvolume. I discovered that the hard way. :stuck_out_tongue:

1 Like

Hi Aragorn

in /etc/fstab, you said in the tutorial:
UUID=the-UUID-you-wrote-down /home ext4 auto,defaults 0 0

But some people use ‘2’ as the last number, what does the last number mean, and what do you recommend?
And what does auto mean and do, before defaults?

UUID=634c31a5-e27c-4e33-ac67-2e22491a30c2 /usr ext4 defaults 0 2

Btw, I plan on booting with a liveusb into my current system, slice a new partition with GParted, encrypt the partition and edit fstab, crypttab and mkinitcpio with chroot accordingly and rsync /usr to the new partition.

See my tutorial below… :arrow_down:

And I quote… :arrow_down:

As for the auto mount option, it means that the filesystem must be mounted at boot time, or whenever the command mount -a is issued.

By default, filesystems on fixed drives will be mounted automatically anyway. In other words, this is already covered by the defaults option, but given that HDD- and SDD-type storage can sometimes be connected via USB — e.g. a USB thumb drive — it may be necessary to use noauto (usually in combination with nofail) for such storage. Conversely, explicitly specifying the auto option is just a way to make sure that the filesystem is mounted automatically, for instance if you don’t know which mount options are the defaults and which ones aren’t.

Personally, I like explicitly writing out the mount options as much as possible for anything in /etc/fstab, so that I can immediately check the mount options for every filesystem on my system. But so strictly speaking, for partitions on an internal SDD and HDD drive, you don’t need it. :wink:

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.