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 
) 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.
2 Likes
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
https://wiki.archlinux.org/title/Mkinitcpio#Common_hooks
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… 
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.
https://wiki.archlinux.org/title/Kernel_mode_setting#Early_KMS_start
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:
MODULES=(amdgpu)
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, …
Why? Just because you can, doesn’t mean you should.
You can, but it will make absolutely no difference.
Why? Only do it if you’re confident about why you’re doing it.
That’s all laid out in the table here linked above:
Tip: If it ain’t broken, don’t fix it. 
1 Like
Why? Just because you can, doesn’t mean you should.
My current HOOKS variable looks like this:
HOOKS="base udev autodetect modconf block keyboard keymap consolefont plymouth resume filesystems fsck"
It’s missing the kms entry and as I wrote earlier:
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.
That’s why I had the impression I should add ‘kms’ as well as the AMDGPU to the MODULES for early-KMS,
You can, but it will make absolutely no difference.
To be standard-compliant but you’re right, it wouldn’t make a difference right now. But what if a future update expects the parentheses in mkinitcpio.conf which we know now have been replaced by ‘outdated syntax’ in a Calamares script?
Why? Only do it if you’re confident about why you’re doing it.
Because @Aragorn wrote above:
Why did you remove it? It’s there by default. That hook doesn’t mean you have to add anything to MODULES=().
Probably not, however, one never knows. Fair enough. 
Well, he’s very smart and explained it well.
I was only checking to make sure you understood each change you were planning to make. Sounds like you do…mostly.
2 Likes
I didn’t. I’ve installed Manjaro in February '23 from the official GNOME .iso and haven’t tinkered with mkinitcpio.conf ever. I just checked now because of a recent stable update and someone noticed that ‘kms’ was missing. No idea how that happend but I’m obviously not the only one being affected:
Oh, sorry for assuming. I just checked my other laptop with an AMD APU and it turns out at some point I added the amdgpu module (don’t remember why).That installation is from 2019. 
Maybe I should follow my own advice remove amdgpu from modules. 
Possibly you missed a pacnew along the way.
Probably the same reason most people do … early kms.
1 Like
I’ve searched with sudo find / -name "mkinitcpio.conf.pacnew" for any .pacnew files right after the stable update in question but couldn’t find anything.
Maybe I should follow my own advice and add kms to hooks and remove amdgpu from modules.
Haha. Ok, I won’t add it to MODULES then either for now.
I’m still looking for some kind of ‘safety net’ in case I really give it a try. What would I need to revert the changes in case my system is unbootable after the changes. Would a bootable USB stick with the current Manjaro GNOME .iso be enough?
Yes. Look up how to manjaro-chroot from your live usb.
Good luck!
1 Like
Right, but whatever the reason was that I thought I needed early KMS is apparently long irrelevant and /or unnecessary to begin with. I just removed it and rebooted fine.
1 Like
Or ‘did’ I meant.
Though I still dont know how accurate the kms itself is.
I wouldnt be surprised to find that certain setups still want to explicitly name some modules
Anyway, having one in modules wont hurt.