Which hooks should mkinitcpio.conf have?

[whatthe]

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
#GRUB_ROOT_FS_RO=true

but I read in the link below that that’s not recommended:
https://wiki.archlinux.org/title/Mkinitcpio

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

[Aragorn]

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

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

Mine is a little different, but equivalent.

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.

sudo updatedb && locate .pacnew

[whatthe]

Hi thanks!

@Aragorn

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.

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

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. 

Thanks

[Aragorn]

@whatthe

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

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

@whatthe

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?

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.

@whatthe

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. 

That’s a very good question. 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.

[whatthe]

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

[Aragorn]

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

[Tip] Root filesystem nearly full but got a spare partition sitting around? Split off some stuff!

Difficulty: ★★★☆☆ Introduction As you should all already know by now, GNU/Linux is a FLOSS variant of the UNIX operating system design, and UNIX does not know the concept of drive letters, nor does it approach storage from the vantage of having different volumes. Instead, everything is mounted into a uniform directory hierarchy, so that regardless of what physical medium any particular group of files resides on ─ even if this physical medium is actually located in another computer across the …

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.

[whatthe]

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
source:
https://askubuntu.com/questions/656/how-to-move-usr-to-a-new-partition

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.

[Aragorn]

@whatthe

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?

See my tutorial below…

[Tutorial] Understanding and working with UNIX filesystems and permissions

Difficulty: ★★★☆☆ Note: This post is meant as a tutorial. Please do not post on this thread regarding any problems you’re having with permissions, but start a new thread instead. Thank you. PREAMBLE: THE HISTORICAL BACKGROUND If you are new to the world of GNU/Linux ─ and especially if you come from the Microsoft Windows ecosystem ─ then you will undoubtedly have already noticed that GNU/Linux handles permissions and storage volumes quite differently from what you might be used to …

And I quote…

@Aragorn

We’ve already briefly touched upon the file /etc/fstab. Essentially, this file is a simple table, or otherwise put, a flat database, in which each line is a record, and each record contains six fields separated by whitespace ─ i.e. space characters or tabs. The layout of the fields (with an example) is as follows…

# STORAGE DEVICE  |  MOUNTPOINT |  TYPE  |  MOUNT OPTIONS  |  DUMP  |  PASS

/dev/sda3            /home         ext4     defaults          0        1

Now let’s take a look at what each of these fields represents…

The first field refers to the storage device that is to be mounted. In the example above, I have used the designation /dev/sda3, but because the order of the different drives in a machine with multiple drives attached is never guaranteed to remain the same across reboots, much better is to use the UUID, which is a unique identifier stored in the filesystem header when the filesystem is created. Alternatively, one can also use a LABEL, which is also stored in the filesystem header, but a LABEL is not guaranteed to be unique, given that it must be set by the biological unit between the keyboard and the chair. A couple of examples follow below…

UUID=some-long-string   /home                   ext4   defaults  0   1
LABEL=movies            /home/my-name/movies    ext4   defaults  0   0

Note: Instead of the UUID or a LABEL, both of which are stored in the filesystem’s own headers, it is also possible to use the PARTUUID or (if present) PARTLABEL, which are similar, but which are stored in the partition table itself on GPT drives, and which, unlike the regular UUID or LABEL, will not change if the filesystem is reformatted. (Note: You cannot do this if the partition table is in the MS-DOS MBR format.)

The second field is easy. It contains the name of the directory that the filesystem is to be mounted on. However, do note that when a filesystem is mounted on this directory, whatever was in the directory before the filesystem was mounted will be obscured until the filesystem is unmounted again. You can actually use this as a trick to help you diagnose problems with mounting, i.e. if you create a directory that another filesystem is to be mounted on later, then you can create a zero-length file in this directory with the name NOT_MOUNTED. By consequence, if you later on visit this directory by way of a file manager or you attempt to list the contents of this directory by way of the command line, and you then get to see a file named NOT_MOUNTED while you were expecting a whole list of other files, then you know what the problem is.

The third field specifies the type of filesystem, although in the event of a swap partition or a swap file, there actually isn’t any filesystem ─ the kernel directly accesses the raw drive blocks for paging data to the swap partition or swap file ─ but you can use sw or swap as a placeholder. Note that for NTFS filesystems, one should use the type ntfs-3g here and not ntfs. The ntfs driver in the kernel is only good for read-only acccess and editing a file by overwriting existing bytes without that the file changes in size. So it’s not really usable. Much better is therefore to use the ntfs-3g type, which has a more functional driver. This more functional driver runs in userspace, not in the kernel ─ it could not be included in the kernel itself because of licensing reasons, which is why it must be explicitly specified in place of the built-in ntfs driver.

The fourth field comprises the mount options. Multiple mount options can be specified, so long as they are separated by commas without spaces. Which options all exist independently from the filesystem types and which ones are the defaults for each suppported type of filesystem can be gleaned from the man page…:

man mount

The fifth field can be set to either 0 or 1, but these days it should not be set to anything other than 0 anymore, although technically speaking, the value of 1 is still functional. This field denotes whether the filesystem must be backed up when using the dump command, an older utility for making backups. Nowadays much better and more flexible backup solutions exist, and so dump isn’t used much anymore, but it’s still supported for compatibility reasons.

The sixth field can be set to 0, 1 or 2. If set to 1 or 2, it denotes the order in which a filesystem must be checked for errors at boot. If set to 0, the filesystem will not be checked, but concretely in Manjaro, the root filesystem is always checked from within the initramfs at every boot, even if the value is set to 0 in /etc/fstab.

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.