You are not logged in.
After upgrading mkinitcpio from version 36 to 37, it exits with an error code and warning at the end, but afaict, creates the img file correctly.
I execute it as follows, and get this output from 37:
# mkinitcpio -k 6.6.0-sce+ -g /boot/initramfs-6.6.0-sce+.img
==> Starting build: '6.6.0-sce+'
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [autodetect]
-> Running build hook: [modconf]
-> Running build hook: [kms]
-> Running build hook: [keyboard]
-> Running build hook: [keymap]
-> Running build hook: [consolefont]
-> Running build hook: [block]
-> Running build hook: [filesystems]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: '/boot/initramfs-6.6.0-sce+.img'
==> WARNING: errors were encountered during the build. The image may not be complete.
When I execute 36, everything is the same, except it exits successfully and the WARNING line is replaced with:
==> Image generation successful
So, I ran both versions with the -v (verbose) flag. There's a lot of output, but here is a diff from 36 to 37:
225c225
< caching 6 modules
---
> caching 14 modules
736a737
> overwriting file: /usr/bin/setfont
781c782
< ==> Image generation successful
---
> ==> WARNING: errors were encountered during the build. The image may not be complete.
So far, I don't see what's going wrong with 37. Any ideas?
Last edited by heistp (2023-11-29 08:39:02)
Offline
Where did you get that kernel version? Does mkinitcpio exit without error for the kernels from the repository?
godisnowhere
Offline
Edit /usr/bin/mkinitcpio, add
set -exo pipefail
re-run it and hope for it to stop at some silent error return that would end up raising _builderrors
Offline
Edit /usr/bin/mkinitcpio, add
set -exo pipefail
re-run it and hope for it to stop at some silent error return that would end up raising _builderrors
That helps, as I found out that the kms module in /usr/lib/initcpio/install/kms is failing because it calls add_checked_modules_from_symbol, which can't find any modules in /lib/modules/6.6.0-sce+/kernel/drivers/platform. That directory doesn't even exist.
This is a custom kernel with a fairly minimal build config, not an official Arch kernel. That said, I don't think this should fail, so I'll file a bug for mkinitcpio, or see if this has been dealt with already.
Thanks...
Offline
The bug was already reported here, but I think the fix needs to return 0 at line 1165.
I can't seem to register for a GitLab account using the Register link though, otherwise I'd report it. It just says "An error occurred while validating username" no matter what I enter. I'll try that again later, but I think the original issue is solved for now.
Offline
You'll have to apply by mail for a login because apparently the gitlab scratchpad is worth the hassle…
Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.
Offline
For completeness, here is a patch for /usr/lib/initcpio/functions that solves the problem for me:
--- functions 2023-11-29 10:42:11.110671847 +0100
+++ functions-add-checked-fix 2023-11-29 10:41:48.834146000 +0100
@@ -1162,7 +1162,7 @@
local -a mods
mapfile -t mods < <(find_module_from_symbol "$@")
- (( ${#mods[@]} )) || return 1
+ (( ! ${#mods[@]} )) && return 0
# _autodetect_cache is declared in mkinitcpio and assigned in install/autodetect
# shellcheck disable=SC2154
The quirky syntax is because a bash trap is used to check the return code, so
(( ${#mods[@]} )) || return 0
would be identified incorrectly as returning 1.
Once I get an account I'll see if the devs agree to this fix.
Offline
For completeness, here is a patch for /usr/lib/initcpio/functions that solves the problem for me:
--- functions 2023-11-29 10:42:11.110671847 +0100 +++ functions-add-checked-fix 2023-11-29 10:41:48.834146000 +0100 @@ -1162,7 +1162,7 @@ local -a mods mapfile -t mods < <(find_module_from_symbol "$@") - (( ${#mods[@]} )) || return 1 + (( ! ${#mods[@]} )) && return 0 # _autodetect_cache is declared in mkinitcpio and assigned in install/autodetect # shellcheck disable=SC2154
The quirky syntax is because a bash trap is used to check the return code, so
(( ${#mods[@]} )) || return 0
would be identified incorrectly as returning 1.
Once I get an account I'll see if the devs agree to this fix.
This fixes the same problem I was having using mkinitcpio with the Liquorix kernel (linux-lqx) installed from https://liquorix.net/archlinux/$repo/$arch
Offline
Appears to be fixed in version 37.2
Offline
Appears to be fixed in version 37.2
can't confirm
[root@myrpi ~]# mkinitcpio --version
mkinitcpio "37.2"
[root@myrpi ~]# mkinitcpio -p linux-rpi
==> Building image from preset: /etc/mkinitcpio.d/linux-rpi.preset: 'default'
==> Using configuration file: '/etc/mkinitcpio.conf'
-> -k 6.6.11-2-rpi -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> Starting build: '6.6.11-2-rpi'
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [autodetect]
-> Running build hook: [modconf]
-> Running build hook: [kms]
-> Running build hook: [keyboard]
-> Running build hook: [keymap]
-> Running build hook: [consolefont]
-> Running build hook: [block]
-> Running build hook: [filesystems]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: '/boot/initramfs-linux.img'
==> WARNING: errors were encountered during the build. The image may not be complete.
Offline
Appears to be fixed in version 37.2
Not fixed for me with the xanmod v3 kernel and version 37.3-1 of mkinitcpio.
Offline
Not fixed for me with the xanmod v3 kernel and version 37.3-1 of mkinitcpio.
Perhaps that kernel is missing some modules.
Post the output of:
$ find "/usr/lib/modules/$(uname -r)/kernel/drivers/platform/" -name '*.ko.zst' -exec zstdgrep -El '^(drm_privacy_screen_register)' '{}' ';'
With the "linux" kernel, it returns chromeos_privacy_screen.ko.zst and thinkpad_acpi.ko.zst.
Offline
MikeDee wrote:Not fixed for me with the xanmod v3 kernel and version 37.3-1 of mkinitcpio.
Perhaps that kernel is missing some modules.
Post the output of:
$ find "/usr/lib/modules/$(uname -r)/kernel/drivers/platform/" -name '*.ko.zst' -exec zstdgrep -El '^(drm_privacy_screen_register)' '{}' ';'
With the "linux" kernel, it returns chromeos_privacy_screen.ko.zst and thinkpad_acpi.ko.zst.
There is no output (i.e., nothing is returned).
Offline
Then your kernel is built without CONFIG_THINKPAD_ACPI=m and CONFIG_CHROMEOS_PRIVACY_SCREEN=m. The failure is expected in this case.
Offline
Then your kernel is built without CONFIG_THINKPAD_ACPI=m and CONFIG_CHROMEOS_PRIVACY_SCREEN=m. The failure is expected in this case.
OK, so how do I install those (probably unneeded) kernel modules? Do you know that with the addition of these modules, that mkinitcpio will work without the warning? If so, that seems to contradict the cause is a buggy script (see above)...
Last edited by MikeDee (2024-02-04 18:23:27)
Offline
By adjusting the kernel config and ammending those parameters.
The "error" happens because you're missing files that would be necessary to fulfill the kms/amdgpu contract. If you're not actively using those the simplest would be to just ignore the error as a false positive for yourself
Last edited by V1del (2024-02-04 18:54:53)
Offline
Actually, the two modules (chromeos_privacy_screen.ko.zst and thinkpad_acpi.ko.zst) exist in the equivalent xanmod folders. They are uncompressed (all of them are) which is why the find command in post #12 couldn't find them (it looks for files ending in "ko.zst" instead of ".ko").
The patch in post #7 above worked to eliminate the warning.
Last edited by MikeDee (2024-02-08 21:48:13)
Offline
Can confirm the patch in post #7 fixes the issue for me as well, on linux-xanmod.
Offline
Finally a solution! The above patch solved the mkinitcpio warning/error with my selfcompiled kernels.
Unless it breaks something else, this fix should really be merged into mkinitcpio.
Offline
--- functions 2023-11-29 10:42:11.110671847 +0100 +++ functions-add-checked-fix 2023-11-29 10:41:48.834146000 +0100 @@ -1162,7 +1162,7 @@ local -a mods mapfile -t mods < <(find_module_from_symbol "$@") - (( ${#mods[@]} )) || return 1 + (( ! ${#mods[@]} )) && return 0 # _autodetect_cache is declared in mkinitcpio and assigned in install/autodetect # shellcheck disable=SC2154
It's not a fix. If no module with the searched symbol can be found, then the function should return 1 (i.e. failure).
The question that needs answering to create a proper fix is, what makes find_module_from_symbol fail if the chromeos_privacy_screen and/or thinkpad_acpi modules do exist?
Offline
https://gitlab.archlinux.org/archlinux/ … ions#L1165
+ set -x
while read -r -d '' mod; do
if decomp_to_stdout "$mod" | grep -Eq "^($symbols)" &> /dev/null; then
mod=${mod##*/}
mod="${mod%.ko*}"
printf '%s\n' "${mod//-/_}"
fi
done < <(LC_ALL=C.UTF-8 find "$moduledir" -name '*.ko*' -print0 2>/dev/null)
+ set +x
should tell?
Offline
Nope, the patch worked for mkinitcpio-37, but -38 broke everything again
Offline
Could you trace the script like in #21 ?
Offline
Could you trace the script like in #21 ?
Well I'm not at all sure I did how I was supposed to do, but I got no output.
(linux-xanmod-lts-6.6.19, mkinitcpio-38-4)
Offline
Empty loop?
Try to wrap the entire function
find_module_from_symbol() {
set -x
…
set +x
}
Offline