mkinitcpio-37-1 upgrade error

[mtnflyr]

I have been performing upgrades as normal with the previously mentioned line commented out in /usr/lib/initcpio/install/kms. All updates that have prompted image rebuild have been successful. Have not yet noticed any side effects from this workaround.

(5/7) Updating linux-rpi initcpios...
==> Building image from preset: /etc/mkinitcpio.d/linux-rpi.preset: 'default'
....
==> Image generation successful

[xywdcrebzughfcfaba]

Commenting the line
[code]add_checked_modules_from_symbol 'drm_privacy_screen_register' '=drivers/platform'[/code]
in [b]/usr/lib/initcpio/install/kms[/b] is still needed for [code]mkinitcpio-37.1-2[/code].

[mcloaked]

I had a look at the file /usr/lib/initcpio/install/kms on both my archlinuxarm machines and my laptop running arch linux.

The line concerned is different in archlinuxarm!

On archlinuxarm the line is:

add_module_from_symbol 'drm_privacy_screen_register' '=drivers/platform'

and on the Arch Linux laptop the line is:

add_checked_modules_from_symbol 'drm_privacy_screen_register' '=drivers/platform'

I am wondering if the difference is behind this problem?

[bulletmark]

@mcloaked, on my Arch and my Arch-arm boxes the file is the same as the second line you show.

[mcloaked]

I should have been clearer - with the update mkinitcpio 36-1 -> 37.1-2 is where that file had the line changed to be the same as you quote. Prior to version 37.1 it was as I quoted. Commenting our the line leads to no warning when running mkinitcpio - so I am wondering whether putting the line back as it was in the mkinitcpio version 36.1 might also lead to no warning! However as other users have posted commenting out the line leads to no warning and no problem rebooting.

[mcloaked]

With the update mkinitcpio 37.1-2 -> 37.2-1 the file /usr/lib/initcpio/install/kms is recreated during the update back to the original and then needs to be edited again to comment out the problematic line.

I wonder if kms is actually needed in the line in /etc/mkinitcpio.conf ?

So if kms was removed from:

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

is it possible that this is an alternate way to work around the problem?

[mtnflyr]

@mccloaked - Just tried your suggestion to remove kms from the HOOKS array in mkinitcpio.conf

I was then able to uncomment the troublesome line in /usr/lib/initcpio/install/kms and successfully rebuild the image with:

[code]sudo mkinitcpio -p linux-rpi[/code]

Reboot was also successful. So far, so good on my headless RPi4 system.

[graysky]

Do you actually need the initramfs for your use case? All of my Pis boot without the image. I actually suppress its generation with a symlink:

[code]
% ls -l /etc/pacman.d/hooks/
total 0
lrwxrwxrwx 1 root root 9 Jan 19 07:10 90-mkinitcpio-install.hook -> /dev/null
[/code]

[mcloaked]

Interesting suggestion - I will have to look at my logs.... I am using a rock64 but clearly I need to learn how the boot process actually works in detail. The initial install instructions from this site set up the boot process, and I never questioned the need for the initramfs it always generated. I will look to see if there is a description of the boot process that allows me to understand the flow for getting the kernel running - and go from there. My initial search didn't lead me to the detail I need.

[graysky]

Ah, I was referring to booting RPi series of hardware which in my experience do not need the file at all. I have no experience with SOCs.