mkinitcpio-37-1 upgrade error

[tazinblack]

This is working for me -> add default_options="--skiphooks kms" in /etc/mkinitcpio.d/linux-aarch64.preset.
But you also need to modify the fallback_options so it looks like fallback_options="-S autodetect --skiphooks kms".
Otherwise the error stays at building the the fallback image phase.

[gavinbeatty]

Posting to report that with mkinitcpio-38-4 on a 64bit RPi4 with linux-rpi-6.6.18-1, I must edit /etc/mkinitcpio.d/linux-rpi.preset to set:

[code]default_options="--skiphook kms"
fallback_options="-S autodetect --skiphook kms"[/code]

in order for initcpios to complete successfully.

[code](4/4) Updating linux initcpios...
==> Building image from preset: /etc/mkinitcpio.d/linux-rpi.preset: 'default'
==> Using configuration file: '/etc/mkinitcpio.conf'
-> -k 6.6.18-1-rpi -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img --skiphook kms
==> Starting build: '6.6.18-1-rpi'
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [autodetect]
-> Running build hook: [microcode]
==> WARNING: architecture 'aarch64' not supported, skipping hook
-> Running build hook: [modconf]
-> Running build hook: [keyboard]
-> Running build hook: [keymap]
-> Running build hook: [consolefont]
==> WARNING: consolefont: no font found in configuration
-> Running build hook: [block]
-> Running build hook: [filesystems]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: '/boot/initramfs-linux.img'
==> Initcpio image generation successful[/code]

Question: Is there a way to configure default_options and fallback_options for the linux-rpi preset without having to edit the preset file directly? The linux-rpi package owns that file. The only way I got the above to work in practice, was to edit the file after the files install, but before initcpios run. I can do this relatively easily, because I use a DKMS module that takes a while to compile, but it's not a great long-term solution.

Is there no user-owned file where this can be set? Even better, is the linux-rpi package planning on adding this config?

[chriswyatt]

With mkinitcpio 38-4, the Lynix LTS kernel and the following config, it seems to build for me now. I've not checked without my changes, so they're probably unrelated to the build being (sort of) successful.

[code]
MODULES=(btrfs vfat crc32c zstd)
COMPRESSION="zstd"
[/code]

I get a bunch of errors and warnings, but it still seems to work when I reboot:make_clickable_callback(MAGIC_URL_FULL, ' ', 'https://www.codedump.xyz/txt/ZeihAuDXmWc5V0D0', '', ' class="postlink"')

Maybe I'll look into squashing the errors/warnings when I have the time, but I've got hourly filesystem snapshots, so I'm not too worried if the VM becomes unbootable again.

As far as I know, I've not done any other configuration that might affect the kernel building.

[graysky]

AFAIK you modify the global config /etc/mkinitcpio.conf not the xxx.preset. Are you certain you even need a /boot/initramfs-linux.img image at all? Standard RPi use cases boot fine without that file. On my systems, I created the following to keep the image from being generated at all.

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

[gavinbeatty]

Adding that exact config to the end of /etc/mkinitcpio.conf, then running [code]pacman -S linux-rpi{,-headers}[/code], which overwrites my preset changes before initcpios, failed.

[code]==> Creating gzip-compressed initcpio image: '/boot/initramfs-linux.img'
==> WARNING: errors were encountered during the build. The image may not be complete.
error: command failed to execute correctly[/code]

I only went with the preset file change based on previous posts by others. mkinitcpio man pages aren't particularly clear on this stuff.

graysky, do you you USB boot any 64bit RPi4s without the initramfs image? That's the maximal "non-standard" extent for my system. If you do, I'll give it a shot.

[surfcrone]

Is there a way to get some diagnostics to help with this report? Presumably there is either a packaging error, or an unsatisfied dependency that isn't present?

[tudbut]

This is present on the rpi 5 but does not cause an unbootable system. Image is functional and seems normal.