You misunderstood. It’s easy to miss, if the version wasn’t specified. That’s all I was saying. Chill, donkey. 
1 Like
And how do you reckon I’d be running any a version other than 39? We are on the Unstable branch, after all.
Well, your post did seem to be quick on the heels of previous related posts describing and resolving what appeared to be much the same issue, so it’s an easy mistake to make, don’t you think? Calling me an ass doesn’t do much more than provoke a negative response, which as you may notice, failed to with me. However, this is all completely off-topic, so, let’s move on. Cheers.
1 Like
I was just baffled when parts of my message seem to be ignored. I don’t think being this pedantic for 39-4 vs -4 is necessary. Sometimes I feel people do this on purpose just to be annoying.
Well, given that you may well have discovered yet another issue with the latest incarnation, the version is likely relevant; if not to us as users, certainly to those actively trying to fix it. I agree though, there are times when comments are made and seem totally irrelevant to anything but ego. People are people, as they say. Cheers.
2 Likes
On another thread… 
That shouldn’t happen. Does it exist twice now in this HOOKS array?
1 Like
It does not:
HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole block filesystems mdadm_udev fsck)
Last time my mkinitcpio.conf was modified was May 4th, and the kms hook has been there even before that, as seen in the other thread I linked to.
Like I said earlier, I updated from 39-1 to 39-4. My understanding of shell scripting is very limited, but maybe there’s something wrong in this part?
if [ "$(vercmp 39-2 "$2")" -eq 1 ]; then
That part should be fine. If you update from a later version then this if-clause ensures we don’t try again.
The question is rather why this condition
if [[ $(sed -n '/^HOOKS=".*\bkms\b.*/p' /etc/mkinitcpio.conf) ]]; then
doesn’t trigger.
1 Like
Would something like this work; where HOOKS is an array?:
if [[ $(sed -n '/^HOOKS=\(.*\bkms\b.*/p' /etc/mkinitcpio.conf) ]]; then
Edit:- Something like…
if [[ $(sed -n '/^HOOKS=".*\bkms\b.*/p' /etc/mkinitcpio.conf) ]]; then
elif [[ $(sed -n '/^HOOKS=\(.*\bkms\b.*/p' /etc/mkinitcpio.conf) ]]; then
...
fi
Edit2:- My point, exactly.
As I said earlier, it’s because of the assumed old HOOKS string vs new array.
edit: which might still be in place for some older installations out there, especially on stable branch where majority of users won’t touch that file.
There shouldn’t be a difference. The sed command simply checks if any line in the file fits the pattern and if yes outputs the line (so the if condition has “some content” and is fulfilled). The sed command outputs nothing if it doesn’t find the line (the if condition fails).
With the current input sed should fire also if the (..) brackets are not provided.
AFAIU you and @Jaypee have two different configurations. @Jaypee has the “normal” one with etc/mkinitpcio.conf while you moved the HOOKS line to some file in /etc/mkinitcpio.d, correct?
Ah, I got now what you meant. But as said, it should also fire if the (..) are not specified in the conditional.
You can check this by running both:
sed -n '/^HOOKS=".*\bkms\b.*/p' /etc/mkinitcpio.conf
sed -n '/^HOOKS=\(.*\bkms\b.*/p' /etc/mkinitcpio.conf
That should produce the same output.
Haha, some brainstorming helps. I know now what you guys mean.
The condition is fine. Rather the insert is wrong, because the insert expects the string structure.
1 Like
I’m not sure that’s the case:
…unless that’s changed since that post.
Yes, I’m using a dropin configuration and no I did not move the HOOKS line but overwrote it.
/etc/mkinitcpio.conf is present on my system just as provided by the mkinitcpio package - it’s just not containing all the effective configuration for my system.
exactly: 
Methinks both cases (string and array) need to be accounted for as this whole modification action is intended to cater to less technical users and who knows how old their /etc/mkinitcpio.confs are.
2 Likes
Yea, on the other side we can ignore cases like yours with users having the config separated out because that’s an advanced use case.
1 Like
While at it should we update the HOOKS line to the new array format?
I wouldn’t ignore them completely, but perhaps give a reminder for these users to check their config files?
As @freggel.doe mentioned, both should ideally be included;
it might prompt those still using a string to adopt the newer array notation. 
I see, you meant the HOOKS line itself in mkinitcpio.conf - I thought this was addressed a few months ago, and array was already the new default. Perhaps I’m wrong. I seem to recall there was a .pacnew at the time.
I recall there was some commentary about Calamares (upstream) using the wrong notation.
Edit: Yes,
1 Like
If people were still using the string annotation, I think they’d have some .pacnew files to attend to by now 