Mkinitcpio.conf correct hooks and syntax

Semantics…let’s call it an “issue with critical configuration files installed by the default installer with wrong and deprecated content” than.

1 Like

They arent related.
IMHO almost everyone should use kms though.

1 Like

last but not least: “this is the first time, i never heard before…” (my life experience)

but getting the point, none is forcing a blame-game. it’s a simple fact that manjaro (and i suggest a lot more other distros) are affected from this bug. the problem is calamares that alters the config by using a outdated convention and it should be fixed instead of wasting time finding a scapegoat.
i really appreciate the interest of all in this forum figuring out things that should be cleared and fixed to improve linux in future.
yes it’s a minor “bug” using “” instead of () but by ignoring this such minimum things end up in a lot of “minor bugs” and in the sum it ends up in problems because the system isn’t consistent.
Feb. 2024 is coming and i’m already frightened of the upcoming …
they are a bad example what happens if problems are ignored to speed up development.


It is not only the brackets, actually, there are different hooks, which is far more important.

What will happen in Feb 24 by the way?

Bbbbblasma 6 is coming

1 Like

Let me repeat - it is not a bug - it is two different ways of describing an array.

For reasons I don’t know - upstream Arch decided to use the () format for arrays in mkinitcpio.conf.

Both definitions will work with bash.

It is likely the array definition () allows for better manipulation than the quote version “”.

For the topic at hand - both definitions are correct - as they reach the correct end result.

  • 4 + 4 = 8
  • 2 x 4 = 8

Who cares which method is used as long as the result is correct.

As @papajoke already point out - bash does not change in revolutionary ways … so don’t blow this out of proportion.

As for which hooks should go into the HOOKS=() that depends on the system - and the admin of said system.


When replacing encrypt with sd-encrypt and using encrypted root, it’s important to note that either /etc/cryptab.initramfs must exist or kernel parameters need to be set. In my case I copied existing /etc/crypttab to /etc/crypttab.initramfs. Also the cryptdevice kernel parameter used by the encrypt hook can be removed as it’s not needed anymore.
See specific page in Arch Wiki.


It is not about the quotes. It is about the principle. The hooks are different… Some external developer (if i understand correctly they take calamares without even looking at the code) replaces system files and manjaro developers did not even notice for at least a year, probably 3…and when somebody finally notices, the reaction is plausible deniability, at best. Not a hint of sorry, we will fix it asap.
How can the average Joe be sure then, that they did not overlook something security related in the kernel…or maybe some external developer slipped something there too and they did not notice for the last 5 years…
That is what pisses me off.


in fact Teo i fully agree.
and once in the future some important update will search for the () in mkinitcpio for something important to change and will fail because the quotation “” is used instead of () and then lazyness becomes a bug and all users don’t “understand” how this happened.
and it’s linux-ground-hog-day as it happened in the past from time to time.


Some external developer (if i understand correctly they take calamares without even looking at the code) replaces system files and manjaro developers did not even notice for at least a year

No one can manage to follow all Linux technical changes related to kernels and applications, this is why users feedback is important, it’s the hidden task force that helps to detect problems on different hardware.

I do agree in general, but in that particular case, there is another layer of what is going on. It was already discussed months ago, calamares makes insensible stuff to fstab too, for example. So they do know, it changes some config files to values that are against the official manjaro recommendations, so to speak. And after that point, it is a decision to make. “We know calamares makes weird stuff, but it is easier for us to pretend it does not, and we do not care much” VS. “Ok, this goes massively sideways more than once, we will have to invest time and money to make our own installer or fix this one”.
I guess only time will tell which one it will be.

I’ve installed Manjaro back in February and I’m also affected by the double quotes (which aren’t a bug! I get it and understand the bash implications :slight_smile: ) I’ve posted the important parts of my mkinitcpio.conf in the most recent Stable update announcement and it turns out, I’ve got a mix of brackets and double quotes.

I wouldn’t have said anything but @Aragorn said something about ‘ages ago ‘deprecated’ double quotes’ and ‘not merged’ .pacnew files which led me to believe something might be wrong with my system because my mkinitcpio.conf was using double quotes but has only been installed in February 2023.

I have to admit I had no idea about what ‘mkinitcpio’ is and does or what all these hooks are that everyone is talking about, but I’ve read up on it meanwhile. Turns out I haven’t ever seen the splash screen my system is configured to show based on the plymouth hook and the kernel parameters.

When I turn on my monitor and system it first shows some splash screen from the ASUS (monitor) and then goes black with a ‘no displayport signal’ error only to come back with the Gnome login screen after a couple of seconds. Given the answer from 45-Oz it seems I’m missing ‘amdgpu’ being listed in the MODULES array for my installed Radeon RX6600 (CPU has no internal graphics)?

I also checked and made sure I’m using a ‘systemd’-based init but all the hooks in my array seem to be the busybox ones. ‘kms’ is missing but I’m not sure if that is on purpose. I’ve also seen the recommendations for switching to systemd, sd-vconsole and the (not) bug reports on Github and Gitlab.

This leaves me with the question, do I have to do these changes now manually to my .conf file or should I wait for a .pacnew file in the future? Why doesn’t Manjaro configure the correct systemd hooks and also list the graphic drivers upon installation?

keep in mind that manjaro (as every other distro-supplier) is collecting and delivering the so called “packages”. the packages are not programmed nor modified from the distro-suppliers, especially if it comes to arch and arch-based systems. they are raw, pure by any means. nevertheless if some packages (in this case calamares) modify config files in a way that is no longer recommended and interfere with the given usage then they are a potential risk of a failure.
keep in mind the rule is the (…) to create a list and the “…” is no longer to be used. a update from another package might need the rule to search for the () to find the list and if calamares create this inside a “…” other programms get trapped and will fail. rules are needed that everyone can trust and use them.
this seems to be bitpeeping but in real can harm a lot, especially in config-files that are needed for the boot-process.


Those are the defaults, yes.

It is recommended to have that in there, unless you have an Nvidia GPU — Nvidia has its own hooks for kernel modesetting.

.pacnew files are only templates. They will not replace your existing configuration files, and they must also not blindly be copied over your existing configuration files.

As for whether you should change your /etc/mkinitcpio.conf or not, it’s up to you. If it works “as is”, then maybe you only need to add kms. But do note that if you’re messing up the file, then upon the next update — or any other time you run mkinitcpio — you could render your system unbootable.

Apparently we take over the configuration verbatim from Arch. And graphics drivers are somewhat of a moving target — especially with Nvidia.

calamares is supposed to be able to set everything up so you wouldn’t have to tinker with it, but as has already been discussed, the calamares developers don’t always get things right — cfr. the nonsensical noatime mount option on swap devices in /etc/fstab or the duplicate/redundant mount for /tmp in /etc/fstab even though systemd (as the init system) already automatically mounts a tmpfs at /tmp.

After analyzing all proposed variants

manjaro		base udev autodetect modconf block filesystems keyboard resume fsck
arch		base udev autodetect modconf kms keyboard keymap consolefont block filesystems resume fsck
calamares	base udev autodetect modconf block keyboard keymap consolefont plymouth filesystems resume fsck
aragorn		base systemd autodetect modconf kms block keyboard sd-vconsole filesystems fsck
cscs		autodetect systemd modconf kms block keyboard filesystems fsck

And the holy Wiki
i decided to go with the following hooks, on a Intel laptop with integrated graphics and ext4 system.

autodetect systemd modconf block keyboard sd-vconsole filesystems fsck

It is worth nothing, on some filesystems at least, fsck should be combined with base (or not used in case of btrfs?), but for ext4 there is no warning.

1 Like

You must have gotten that from an old post of mine, because I’ve already long ago removed fsck, and I have recently removed base as well. My HOOKS line looks like this now… :point_down:

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

I am not using the HOOK kms, I loaded MODULE=(i915) in the beginning of mkinitcpio.conf.

The wiki is not clear which option to use.

i915 or amdgpu should both be “in-tree” modules, so adding the kms hook should be enough, however, I can see a difference with having both amdgpu and kms: My hidpi screen has nice DPI (=readable text) for the disk encryption dialog.
Without one of them, it defaults to very small text.

Only judging from the wiki, none of them should even be required anyway but apparently they are?

My config:

MODULES=(amdgpu usbhid xhci_hcd)
HOOKS=(systemd modconf kms block keyboard autodetect sd-vconsole sd-encrypt filesystems)

I dont see how you get that.
My reading seems to suggest you want both kms and whatever module for your gfx … at least if you want “early kms” … which, yes, can have an impact on display in general.

Ah . I suppose there is these lines:

Which I might be misleading. It comes a bit after these lines:

1 Like

After reading up on all of this, I’m tempted to make changes to my mkinitcpio.conf like:

  • adding ‘AMDGPU’ to the MODULES
  • replacing all double-quotes with parantheses
  • changing from busybox to systemd hooks

I have to manually edit these changes into the file, right? After that I have to sudo mkinitcpio -P to generate the new initramfs, reboot and pray?

I’ve got a couple of questions about all of this. The one that concerns me the most is, what can I do/should I prepare in case all goes south and I render my system unbootable with this? How would I be able to revert these changes since I don’t have another system to help me out.

Then there’s this thing about the .pacnew files. Does doing these changes manually mean I’ll always get a .pacnew file from now on when mkinitcpio is updated?

I’m still not sure if I need AMDGPU in the modules section and ‘kms’ in the HOOKS at the same time but from what I understand, there is a benefit of having both entries in the .conf file.

Also not sure about the correct/final order of the hooks. I’m using an ext4 filesystem without any encryption, so I’ll probably need something like:

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

I’m confused about the placement of autodetect in all the listed configurations. Where would be the best/correct place? Before systemd, after systemd, right at the beginning, after keyboard, …