There is a lot of options which all controls how the initrd is constructed.
If you look at the Common hooks table you find that base is optional - as it only provides the recovery shell.
As for the confusion about the MODULES=“” vs. MODULES=() the correct syntax is MODULES=()
Please also see below
Thanks @linux-aarhus to provide that simple and clear answer. hopefully this will also become clear to all devs and distro-maintainers and they start using it. sometimes it’s unbelievable that changes like this convention is invented by developers and then they don’t care about their own changes.
this issue should/must be pinned in the forum that all of us take care for it and claim it until it is fixed in the distro in general.
yes, but not for calamares ! 
Created an issue with a patch for Calamares and manjaro-tools
Upstream Calamares as well
Just for info :
3 computers with amd graphic (rx580, rx560, hd7870), running manjaro minimal (6.1 lts), before i put modules=“amdgpu” with “” and not with () in mkinitcpio.conf, alls kernels after 6.1 lts didn’t work (stuck on manjaro logo)
running sudo mkinitcpio -P, restart and alls my 3 computers work like a charm.
didn’t know that () replace “” but “” still works here.
Technically it not an error using “” - bash still understands the old array style using “” - I think it is about ambiguity - but I don’t know.
My take on why one uses () to describe an array is that using quotation marks - for a human - describes a line of text - the bash interpreter may allow iterations over the words in a line of text as it technically is also an array - albeit an array with meaning to a human
Bash understand both types
MODULES="albeit an array with meaning to a human"
MODULES=(albeit an array with meaning to a human)
Thanks that somebody cared. We now know:
How about the correct hooks? I mean should we remove plymouth and replace with kms, or use both, or one of them is enough?
And let’s just hope somebody else cares too and fixes the bug AND releases a .pacnew after that to fix all the installations for the last 3 years.
I do not care about apportioning blame / scapegoating because it is not helpful to resolve issue
Not having control of a system is not exactly a compliment for user abilities
I checked cached packages in /var/cache/pacman/pkg/
mkinitcpio-35.2-1-any.pkg.tar.zst
mkinitcpio-36-6-any.pkg.tar.zst
mkinitcpio-37-1-any.pkg.tar.zst (current version)
All 3 versions have the same hooks configuration using brackets
HOOKS=(base udev autodetect modconf kms keyboard keymap consolefont block filesystems fsck)
I suggest you consider your previous advice to another user
I also suggest you read forum rules regarding Personal Topics and Ineffective Discussion
Yes, i checked the packets too. But on installation calamares changes it. We now know that as a fact (because @linux-aarhus actually found the lines of code that do that).
I do not care about scapecoating too. What i do care very much is, when a bug is found, to be taken seriously and fixed (which will be an “effective discussion”), and not with the attitude “it cannot be true, it is not true, it is not my fault, i do not care, you are not making any sense” @Yochanan (which is not an effective discussion)
read (and response) ! no bug exists
just need to be changed so that no user is confused
there’s no revolution in bash, otherwise thousands of scripts would be broken.
calamares is not just for the arch family, perhaps some distributions don’t use brackets in this file ?
Semantics…let’s call it an “issue with critical configuration files installed by the default installer with wrong and deprecated content” than.
They arent related.
IMHO almost everyone should use kms though.
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
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.
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.