On 04/11/25 4:47 pm, Samir M wrote:
Hello,
I am observing below error while running the make modules_install command on latest mainline kernel on IBM Power11 server.
Error: DEPMOD /lib/modules/6.18.0-rc4 depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix
IBM CI has also reported this error.
Error:
depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix INSTALL /boot depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix
Git bisect is pointing to below commit as first bad commit.
d50f21091358b2b29dc06c2061106cdb0f030d03 is the first bad commit commit d50f21091358b2b29dc06c2061106cdb0f030d03 Author: Dimitri John Ledkov dimitri.ledkov@surgut.co.uk Date: Sun Oct 26 20:21:00 2025 +0000
kbuild: align modinfo section for Secureboot Authenticode EDK2 compat
Previously linker scripts would always generate vmlinuz that has sections aligned. And thus padded (correct Authenticode calculation) and unpadded calculation would be same. As in https://github.com/rhboot/pesign userspace tool would produce the same authenticode digest for both of the following commands:
pesign --padding --hash --in ./arch/x86_64/boot/bzImage pesign --nopadding --hash --in ./arch/x86_64/boot/bzImage
The commit 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped") added .modinfo section of variable length. Depending on kernel configuration it may or may not be aligned.
All userspace signing tooling correctly pads such section to calculation spec compliant authenticode digest.
However, if bzImage is not further processed and is attempted to be loaded directly by EDK2 firmware, it calculates unpadded Authenticode digest and fails to correct accept/reject such kernel builds even when propoer Authenticode values are enrolled in db/dbx. One can say EDK2 requires aligned/padded kernels in Secureboot.
Thus add ALIGN(8) to the .modinfo section, to esure kernels irrespective of modinfo contents can be loaded by all existing EDK2 firmware builds.
Fixes: 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped") Cc: stable@vger.kernel.org Signed-off-by: Dimitri John Ledkov dimitri.ledkov@surgut.co.uk Link: https://patch.msgid.link/20251026202100.679989-1-dimitri.ledkov@surgut.co.uk Signed-off-by: Nathan Chancellor nathan@kernel.org
include/asm-generic/vmlinux.lds.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Git Bisect log:
git bisect log git bisect start # status: waiting for both good and bad commits # bad: [c9cfc122f03711a5124b4aafab3211cf4d35a2ac] Merge tag 'for-6.18-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux git bisect bad c9cfc122f03711a5124b4aafab3211cf4d35a2ac # status: waiting for good commit(s), bad commit known # good: [dcb6fa37fd7bc9c3d2b066329b0d27dedf8becaa] Linux 6.18-rc3 git bisect good dcb6fa37fd7bc9c3d2b066329b0d27dedf8becaa # good: [3ad81aa52085a7e67edfa4bc8f518e5962196bb3] Merge tag 'v6.18-p4' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 git bisect good 3ad81aa52085a7e67edfa4bc8f518e5962196bb3 # good: [f414f9fd68797182f8de4e1cd9855b6b28abde99] Merge tag 'pci-v6.18-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci git bisect good f414f9fd68797182f8de4e1cd9855b6b28abde99 # good: [41dacb39fe79cd2fce42d31fa6658d926489a548] Merge tag 'drm-xe-fixes-2025-10-30' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes git bisect good 41dacb39fe79cd2fce42d31fa6658d926489a548 # bad: [f9bc8e0912b8f6b1d60608a715a1da575670e038] Merge tag 'perf-urgent-2025-11-01' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect bad f9bc8e0912b8f6b1d60608a715a1da575670e038 # good: [c44b4b9eeb71f5b0b617abf6fd66d1ef0aab6200] objtool: Fix skip_alt_group() for non-alternative STAC/CLAC git bisect good c44b4b9eeb71f5b0b617abf6fd66d1ef0aab6200 # bad: [cb7f9fc3725a11447a4af69dfe8d648e4320acdc] Merge tag 'kbuild-fixes-6.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux git bisect bad cb7f9fc3725a11447a4af69dfe8d648e4320acdc # bad: [d50f21091358b2b29dc06c2061106cdb0f030d03] kbuild: align modinfo section for Secureboot Authenticode EDK2 compat git bisect bad d50f21091358b2b29dc06c2061106cdb0f030d03 # good: [5ff90d427ef841fa48608d0c19a81c48d6126d46] kbuild: install-extmod-build: Fix when given dir outside the build dir git bisect good 5ff90d427ef841fa48608d0c19a81c48d6126d46 # first bad commit: [d50f21091358b2b29dc06c2061106cdb0f030d03] kbuild: align modinfo section for Secureboot Authenticode EDK2 compat
Please add below tag as well, if you happen to fix this.
Reported-by: Venkat Rao Bagalkote venkat88@linux.ibm.com
Regards,
Venkat.
If you happen to fix the above issue, then please add below tag. Reported-by: Samir M samir@linux.ibm.com
Regards, Samir.
On Tue, Nov 04, 2025 at 04:54:38PM +0530, Venkat Rao Bagalkote wrote:
On 04/11/25 4:47 pm, Samir M wrote:
Hello,
I am observing below error while running the make modules_install command on latest mainline kernel on IBM Power11 server.
Error: DEPMOD /lib/modules/6.18.0-rc4 depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix
IBM CI has also reported this error.
Error:
depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix INSTALL /boot depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix
Git bisect is pointing to below commit as first bad commit.
d50f21091358b2b29dc06c2061106cdb0f030d03 is the first bad commit commit d50f21091358b2b29dc06c2061106cdb0f030d03 Author: Dimitri John Ledkov dimitri.ledkov@surgut.co.uk Date: Sun Oct 26 20:21:00 2025 +0000
kbuild: align modinfo section for Secureboot Authenticode EDK2 compat
Previously linker scripts would always generate vmlinuz that has sections aligned. And thus padded (correct Authenticode calculation) and unpadded calculation would be same. As in https://github.com/rhboot/pesign userspace tool would produce the same authenticode digest for both of the following commands:
pesign --padding --hash --in ./arch/x86_64/boot/bzImage pesign --nopadding --hash --in ./arch/x86_64/boot/bzImage
The commit 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped") added .modinfo section of variable length. Depending on kernel configuration it may or may not be aligned.
All userspace signing tooling correctly pads such section to calculation spec compliant authenticode digest.
However, if bzImage is not further processed and is attempted to be loaded directly by EDK2 firmware, it calculates unpadded Authenticode digest and fails to correct accept/reject such kernel builds even when propoer Authenticode values are enrolled in db/dbx. One can say EDK2 requires aligned/padded kernels in Secureboot.
Thus add ALIGN(8) to the .modinfo section, to esure kernels irrespective of modinfo contents can be loaded by all existing EDK2 firmware builds.
Fixes: 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped") Cc: stable@vger.kernel.org Signed-off-by: Dimitri John Ledkov dimitri.ledkov@surgut.co.uk Link: https://patch.msgid.link/20251026202100.679989-1-dimitri.ledkov@surgut.co.uk Signed-off-by: Nathan Chancellor nathan@kernel.org
include/asm-generic/vmlinux.lds.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drgn's CI hit this same failure. FWIW, the commit fixed by this bisected commit, 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped"), also results in ELF segments of size 0 in vmlinux for some configurations, which confused drgn until I added a workaround (https://github.com/osandov/drgn/commit/2a9053de8796af866fd720a3c8c23013595d3...). So there's some funkiness in this area.
Thanks, Omar
On Tue, 4 Nov 2025 at 18:12, Omar Sandoval osandov@osandov.com wrote:
On Tue, Nov 04, 2025 at 04:54:38PM +0530, Venkat Rao Bagalkote wrote:
On 04/11/25 4:47 pm, Samir M wrote:
Hello,
I am observing below error while running the make modules_install command on latest mainline kernel on IBM Power11 server.
Error: DEPMOD /lib/modules/6.18.0-rc4 depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix
IBM CI has also reported this error.
Error:
depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix INSTALL /boot depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix
Git bisect is pointing to below commit as first bad commit.
d50f21091358b2b29dc06c2061106cdb0f030d03 is the first bad commit commit d50f21091358b2b29dc06c2061106cdb0f030d03 Author: Dimitri John Ledkov dimitri.ledkov@surgut.co.uk Date: Sun Oct 26 20:21:00 2025 +0000
kbuild: align modinfo section for Secureboot Authenticode EDK2 compat Previously linker scripts would always generate vmlinuz that hassections aligned. And thus padded (correct Authenticode calculation) and unpadded calculation would be same. As in https://github.com/rhboot/pesign userspace tool would produce the same authenticode digest for both of the following commands:
pesign --padding --hash --in ./arch/x86_64/boot/bzImage pesign --nopadding --hash --in ./arch/x86_64/boot/bzImage The commit 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped") added .modinfo section of variable length.Depending on kernel configuration it may or may not be aligned.
All userspace signing tooling correctly pads such section to calculation spec compliant authenticode digest. However, if bzImage is not further processed and is attempted to beloaded directly by EDK2 firmware, it calculates unpadded Authenticode digest and fails to correct accept/reject such kernel builds even when propoer Authenticode values are enrolled in db/dbx. One can say EDK2 requires aligned/padded kernels in Secureboot.
Thus add ALIGN(8) to the .modinfo section, to esure kernels irrespectiveof modinfo contents can be loaded by all existing EDK2 firmware builds.
Fixes: 3e86e4d74c04 ("kbuild: keep .modinfo section invmlinux.unstripped") Cc: stable@vger.kernel.org Signed-off-by: Dimitri John Ledkov dimitri.ledkov@surgut.co.uk Link: https://patch.msgid.link/20251026202100.679989-1-dimitri.ledkov@surgut.co.uk Signed-off-by: Nathan Chancellor nathan@kernel.org
include/asm-generic/vmlinux.lds.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drgn's CI hit this same failure. FWIW, the commit fixed by this bisected commit, 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped"), also results in ELF segments of size 0 in vmlinux for some configurations, which confused drgn until I added a workaround (https://github.com/osandov/drgn/commit/2a9053de8796af866fd720a3c8c23013595d3...). So there's some funkiness in this area.
The expectation is that said section is removed from the final binary. But the fact that it is present with 0 length, indicates incorrect linking. It also now makes sense why on x86/arm it is tripping up section alignment.
As it is likely that it is the same underlying issue that such segment exists in the first place.
I wonder if the original implementation of moving sections about and when/where the builtin module info is kept is not as tidy as it was intended to be.
I wonder if we should: - rollback to the state of how things were before that feature was added - keep the production / stripped / installed kernel build as is - reshuffle of how modinfo is preserved in the unstripped kernel with a bespoke linker script
Such that hopefully we have correct alignment, without any zero length segments.
Or possibly even link / split the built-in module info somewhere else entirely.
As in revert both: - d50f21091358b (kbuild: align modinfo section for Secureboot Authenticode EDK2 compat, 2025-10-26) - 3e86e4d74c049 (kbuild: keep .modinfo section in vmlinux.unstripped, 2025-09-18)
And try implementing the keeping of .modinfo section again.
Better structure tests, after linking would be nice to catch such issues, because linker scripts are hard and trying to understand how a linker script change affects the result.
On Tue, Nov 04, 2025 at 08:35:57PM +0000, Dimitri John Ledkov wrote:
On Tue, 4 Nov 2025 at 18:12, Omar Sandoval osandov@osandov.com wrote:
drgn's CI hit this same failure. FWIW, the commit fixed by this bisected commit, 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped"), also results in ELF segments of size 0 in vmlinux for some configurations, which confused drgn until I added a workaround (https://github.com/osandov/drgn/commit/2a9053de8796af866fd720a3c8c23013595d3...). So there's some funkiness in this area.
Omar, could you provide me with a configuration file that reproduces this for you? Is there an easy way to check for this situation on the command line?
The expectation is that said section is removed from the final binary. But the fact that it is present with 0 length, indicates incorrect linking. It also now makes sense why on x86/arm it is tripping up section alignment.
If I diff the output of 'llvm-readelf -e' for vmlinux.unstripped and vmlinux when building 'ARCH=arm64 defconfig' using my suggested diff on top of 6.18-rc4, I do see .modinfo get removed and I am not sure I see an empty segment as a result?
diff --git a/tmp/.psub.Rg1zsq b/tmp/.psub.nGpcxI index 2f079cb57f58..dcca71062760 100644 --- a/tmp/.psub.Rg1zsq +++ b/tmp/.psub.nGpcxI @@ -10,15 +10,15 @@ ELF Header: Version: 0x1 Entry point address: 0xffff800080000000 Start of program headers: 64 (bytes into file) - Start of section headers: 157810560 (bytes into file) + Start of section headers: 156417384 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) - Number of program headers: 5 + Number of program headers: 4 Size of section headers: 64 (bytes) - Number of section headers: 47 - Section header string table index: 46 -There are 47 section headers, starting at offset 0x967ff80: + Number of section headers: 46 + Section header string table index: 45 +There are 46 section headers, starting at offset 0x952bd68:
Section Headers: [Nr] Name Type Address Off Size ES Flg Lk Inf Al @@ -56,19 +56,18 @@ Section Headers: [31] .mmuoff.data.read PROGBITS ffff80008270b800 271b800 000008 00 WA 0 0 8 [32] .pecoff_edata_padding PROGBITS ffff80008270b808 271b808 0001f8 00 A 0 0 1 [33] .bss NOBITS ffff80008270c000 271ba00 0ac970 00 WA 0 0 4096 - [34] .debug_aranges PROGBITS 0000000000000000 27d09d0 047550 00 0 0 16 - [35] .debug_info PROGBITS 0000000000000000 2817f20 38fdcf1 00 0 0 1 - [36] .debug_abbrev PROGBITS 0000000000000000 6115c11 4845e1 00 0 0 1 - [37] .debug_line PROGBITS 0000000000000000 659a1f2 1848e28 00 0 0 1 - [38] .debug_frame PROGBITS 0000000000000000 7de3020 3e2858 00 0 0 8 - [39] .debug_str PROGBITS 0000000000000000 81c5878 58f8cc 01 MS 0 0 1 - [40] .debug_line_str PROGBITS 0000000000000000 8755144 057ff7 01 MS 0 0 1 - [41] .debug_rnglists PROGBITS 0000000000000000 87ad13b 4d3fc6 00 0 0 1 - [42] .modinfo PROGBITS ffff8000827d0000 2720000 0b09c8 00 A 0 0 1 - [43] .comment PROGBITS 0000000000000000 8c81101 000012 01 MS 0 0 1 - [44] .symtab SYMTAB 0000000000000000 8c81118 671a60 18 45 250028 8 - [45] .strtab STRTAB 0000000000000000 92f2b78 38d1f3 00 0 0 1 - [46] .shstrtab STRTAB 0000000000000000 967fd6b 000215 00 0 0 1 + [34] .debug_aranges PROGBITS 0000000000000000 271ba00 047550 00 0 0 16 + [35] .debug_info PROGBITS 0000000000000000 2762f50 38fdcf1 00 0 0 1 + [36] .debug_abbrev PROGBITS 0000000000000000 6060c41 4845e1 00 0 0 1 + [37] .debug_line PROGBITS 0000000000000000 64e5222 1848e28 00 0 0 1 + [38] .debug_frame PROGBITS 0000000000000000 7d2e050 3e2858 00 0 0 8 + [39] .debug_str PROGBITS 0000000000000000 81108a8 58f8cc 01 MS 0 0 1 + [40] .debug_line_str PROGBITS 0000000000000000 86a0174 057ff7 01 MS 0 0 1 + [41] .debug_rnglists PROGBITS 0000000000000000 86f816b 4d3fc6 00 0 0 1 + [42] .comment PROGBITS 0000000000000000 8bcc131 000012 01 MS 0 0 1 + [43] .symtab SYMTAB 0000000000000000 8bcc148 612990 18 44 233806 8 + [44] .strtab STRTAB 0000000000000000 91dead8 34d07e 00 0 0 1 + [45] .shstrtab STRTAB 0000000000000000 952bb56 00020c 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), @@ -77,21 +76,19 @@ Key to Flags:
Elf file type is DYN (Shared object file) Entry point 0xffff800080000000 -There are 5 program headers, starting at offset 64 +There are 4 program headers, starting at offset 64
Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x010000 0xffff800080000000 0xffff800080000000 0x11cc000 0x11cc000 R E 0x10000 LOAD 0x11e0000 0xffff8000811d0000 0xffff8000811d0000 0x153ba00 0x15e8970 RWE 0x10000 - LOAD 0x2720000 0xffff8000827d0000 0xffff8000827d0000 0x0b09c8 0x0b09c8 R 0x10000 NOTE 0x1e83cf4 0xffff800081e73cf4 0xffff800081e73cf4 0x000054 0x000054 R 0x4 - GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10 + GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x8
Section to Segment mapping: Segment Sections... 00 .head.text .text 01 .rodata .pci_fixup __ksymtab __ksymtab_gpl __ksymtab_strings __param __modver __ex_table .notes .hyp.rodata .got .got.plt .rodata.text .init.text .exit.text .altinstructions .init.data runtime_shift_d_hash_shift runtime_ptr_dentry_hashtable .data..percpu .hyp.data..percpu .hyp.reloc .rela.dyn .relr.dyn .data __bug_table .hyp.data .mmuoff.data.write .mmuoff.data.read .pecoff_edata_padding .bss - 02 .modinfo - 03 .notes - 04 + 02 .notes + 03 None .debug_aranges .debug_info .debug_abbrev .debug_line .debug_frame .debug_str .debug_line_str .debug_rnglists .comment .symtab .strtab .shstrtab
As it is likely that it is the same underlying issue that such segment exists in the first place.
I wonder if the original implementation of moving sections about and when/where the builtin module info is kept is not as tidy as it was intended to be.
This is entirely possible. It would be helpful to know why exactly this is happening to be certain.
I wonder if we should:
- rollback to the state of how things were before that feature was added
- keep the production / stripped / installed kernel build as is
- reshuffle of how modinfo is preserved in the unstripped kernel with
a bespoke linker script
Such that hopefully we have correct alignment, without any zero length segments.
Or possibly even link / split the built-in module info somewhere else entirely.
As in revert both:
- d50f21091358b (kbuild: align modinfo section for Secureboot
Authenticode EDK2 compat, 2025-10-26)
- 3e86e4d74c049 (kbuild: keep .modinfo section in vmlinux.unstripped,
2025-09-18)
And try implementing the keeping of .modinfo section again.
Better structure tests, after linking would be nice to catch such issues, because linker scripts are hard and trying to understand how a linker script change affects the result.
I think if we cannot figure out these issues by -rc6 timeframe, it may be worth reverting the entire builtin .modinfo series and trying again for 6.20 (it will probably be too late for 6.19 at that point) but I would like to avoid doing that to Alexey if possible. I am not sure the zero length segment issue is worth an entire back out at this point alone, as I have proposed a fix for the original issue brought up by this thread.
Cheers, Nathan
On Tue, Nov 04, 2025 at 06:15:48PM -0700, Nathan Chancellor wrote:
On Tue, Nov 04, 2025 at 08:35:57PM +0000, Dimitri John Ledkov wrote:
On Tue, 4 Nov 2025 at 18:12, Omar Sandoval osandov@osandov.com wrote:
drgn's CI hit this same failure. FWIW, the commit fixed by this bisected commit, 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped"), also results in ELF segments of size 0 in vmlinux for some configurations, which confused drgn until I added a workaround (https://github.com/osandov/drgn/commit/2a9053de8796af866fd720a3c8c23013595d3...). So there's some funkiness in this area.
Omar, could you provide me with a configuration file that reproduces this for you? Is there an easy way to check for this situation on the command line?
The expectation is that said section is removed from the final binary. But the fact that it is present with 0 length, indicates incorrect linking. It also now makes sense why on x86/arm it is tripping up section alignment.
If I diff the output of 'llvm-readelf -e' for vmlinux.unstripped and vmlinux when building 'ARCH=arm64 defconfig' using my suggested diff on top of 6.18-rc4, I do see .modinfo get removed and I am not sure I see an empty segment as a result?
diff --git a/tmp/.psub.Rg1zsq b/tmp/.psub.nGpcxI index 2f079cb57f58..dcca71062760 100644 --- a/tmp/.psub.Rg1zsq +++ b/tmp/.psub.nGpcxI @@ -10,15 +10,15 @@ ELF Header: Version: 0x1 Entry point address: 0xffff800080000000 Start of program headers: 64 (bytes into file)
- Start of section headers: 157810560 (bytes into file)
- Start of section headers: 156417384 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes)
- Number of program headers: 5
- Number of program headers: 4 Size of section headers: 64 (bytes)
- Number of section headers: 47
- Section header string table index: 46
-There are 47 section headers, starting at offset 0x967ff80:
- Number of section headers: 46
- Section header string table index: 45
+There are 46 section headers, starting at offset 0x952bd68: Section Headers: [Nr] Name Type Address Off Size ES Flg Lk Inf Al @@ -56,19 +56,18 @@ Section Headers: [31] .mmuoff.data.read PROGBITS ffff80008270b800 271b800 000008 00 WA 0 0 8 [32] .pecoff_edata_padding PROGBITS ffff80008270b808 271b808 0001f8 00 A 0 0 1 [33] .bss NOBITS ffff80008270c000 271ba00 0ac970 00 WA 0 0 4096
- [34] .debug_aranges PROGBITS 0000000000000000 27d09d0 047550 00 0 0 16
- [35] .debug_info PROGBITS 0000000000000000 2817f20 38fdcf1 00 0 0 1
- [36] .debug_abbrev PROGBITS 0000000000000000 6115c11 4845e1 00 0 0 1
- [37] .debug_line PROGBITS 0000000000000000 659a1f2 1848e28 00 0 0 1
- [38] .debug_frame PROGBITS 0000000000000000 7de3020 3e2858 00 0 0 8
- [39] .debug_str PROGBITS 0000000000000000 81c5878 58f8cc 01 MS 0 0 1
- [40] .debug_line_str PROGBITS 0000000000000000 8755144 057ff7 01 MS 0 0 1
- [41] .debug_rnglists PROGBITS 0000000000000000 87ad13b 4d3fc6 00 0 0 1
- [42] .modinfo PROGBITS ffff8000827d0000 2720000 0b09c8 00 A 0 0 1
- [43] .comment PROGBITS 0000000000000000 8c81101 000012 01 MS 0 0 1
- [44] .symtab SYMTAB 0000000000000000 8c81118 671a60 18 45 250028 8
- [45] .strtab STRTAB 0000000000000000 92f2b78 38d1f3 00 0 0 1
- [46] .shstrtab STRTAB 0000000000000000 967fd6b 000215 00 0 0 1
- [34] .debug_aranges PROGBITS 0000000000000000 271ba00 047550 00 0 0 16
- [35] .debug_info PROGBITS 0000000000000000 2762f50 38fdcf1 00 0 0 1
- [36] .debug_abbrev PROGBITS 0000000000000000 6060c41 4845e1 00 0 0 1
- [37] .debug_line PROGBITS 0000000000000000 64e5222 1848e28 00 0 0 1
- [38] .debug_frame PROGBITS 0000000000000000 7d2e050 3e2858 00 0 0 8
- [39] .debug_str PROGBITS 0000000000000000 81108a8 58f8cc 01 MS 0 0 1
- [40] .debug_line_str PROGBITS 0000000000000000 86a0174 057ff7 01 MS 0 0 1
- [41] .debug_rnglists PROGBITS 0000000000000000 86f816b 4d3fc6 00 0 0 1
- [42] .comment PROGBITS 0000000000000000 8bcc131 000012 01 MS 0 0 1
- [43] .symtab SYMTAB 0000000000000000 8bcc148 612990 18 44 233806 8
- [44] .strtab STRTAB 0000000000000000 91dead8 34d07e 00 0 0 1
- [45] .shstrtab STRTAB 0000000000000000 952bb56 00020c 00 0 0 1
Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), @@ -77,21 +76,19 @@ Key to Flags: Elf file type is DYN (Shared object file) Entry point 0xffff800080000000 -There are 5 program headers, starting at offset 64 +There are 4 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x010000 0xffff800080000000 0xffff800080000000 0x11cc000 0x11cc000 R E 0x10000 LOAD 0x11e0000 0xffff8000811d0000 0xffff8000811d0000 0x153ba00 0x15e8970 RWE 0x10000
- LOAD 0x2720000 0xffff8000827d0000 0xffff8000827d0000 0x0b09c8 0x0b09c8 R 0x10000 NOTE 0x1e83cf4 0xffff800081e73cf4 0xffff800081e73cf4 0x000054 0x000054 R 0x4
- GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10
- GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x8
Section to Segment mapping: Segment Sections... 00 .head.text .text 01 .rodata .pci_fixup __ksymtab __ksymtab_gpl __ksymtab_strings __param __modver __ex_table .notes .hyp.rodata .got .got.plt .rodata.text .init.text .exit.text .altinstructions .init.data runtime_shift_d_hash_shift runtime_ptr_dentry_hashtable .data..percpu .hyp.data..percpu .hyp.reloc .rela.dyn .relr.dyn .data __bug_table .hyp.data .mmuoff.data.write .mmuoff.data.read .pecoff_edata_padding .bss
- 02 .modinfo
- 03 .notes
- 04
- 02 .notes
- 03 None .debug_aranges .debug_info .debug_abbrev .debug_line .debug_frame .debug_str .debug_line_str .debug_rnglists .comment .symtab .strtab .shstrtab
As it is likely that it is the same underlying issue that such segment exists in the first place.
I wonder if the original implementation of moving sections about and when/where the builtin module info is kept is not as tidy as it was intended to be.
This is entirely possible. It would be helpful to know why exactly this is happening to be certain.
I wonder if we should:
- rollback to the state of how things were before that feature was added
- keep the production / stripped / installed kernel build as is
- reshuffle of how modinfo is preserved in the unstripped kernel with
a bespoke linker script
Such that hopefully we have correct alignment, without any zero length segments.
Or possibly even link / split the built-in module info somewhere else entirely.
As in revert both:
- d50f21091358b (kbuild: align modinfo section for Secureboot
Authenticode EDK2 compat, 2025-10-26)
- 3e86e4d74c049 (kbuild: keep .modinfo section in vmlinux.unstripped,
2025-09-18)
And try implementing the keeping of .modinfo section again.
Better structure tests, after linking would be nice to catch such issues, because linker scripts are hard and trying to understand how a linker script change affects the result.
I think if we cannot figure out these issues by -rc6 timeframe, it may be worth reverting the entire builtin .modinfo series and trying again for 6.20 (it will probably be too late for 6.19 at that point) but I would like to avoid doing that to Alexey if possible. I am not sure the zero length segment issue is worth an entire back out at this point alone, as I have proposed a fix for the original issue brought up by this thread.
Nathan, if you see that my changes are creating more problems than they are solving, feel free to revert them.
My changes were based on Masahiro Yamada's patches. I didn't expect his changes to cause many problems. Before his changes, I tried to use a different approach. If you think it's worth it, we can return to discussing it.
https://lore.kernel.org/all/cover.1748335606.git.legion@kernel.org/
On Wed, Nov 05, 2025 at 01:51:22PM +0100, Alexey Gladkov wrote:
Nathan, if you see that my changes are creating more problems than they are solving, feel free to revert them.
Thanks for that permission! I will keep it in mind as we get closer to the end of the release cycle if these problems are too much to overcome.
My changes were based on Masahiro Yamada's patches. I didn't expect his changes to cause many problems. Before his changes, I tried to use a different approach. If you think it's worth it, we can return to discussing it.
https://lore.kernel.org/all/cover.1748335606.git.legion@kernel.org/
Right, I had noticed that in the development history and wondered if we would want to revisit it. I will have to take a closer look at that depending on how things go here.
Cheers, Nathan
On Tue, Nov 04, 2025 at 06:15:48PM -0700, Nathan Chancellor wrote:
On Tue, Nov 04, 2025 at 08:35:57PM +0000, Dimitri John Ledkov wrote:
On Tue, 4 Nov 2025 at 18:12, Omar Sandoval osandov@osandov.com wrote:
drgn's CI hit this same failure. FWIW, the commit fixed by this bisected commit, 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped"), also results in ELF segments of size 0 in vmlinux for some configurations, which confused drgn until I added a workaround (https://github.com/osandov/drgn/commit/2a9053de8796af866fd720a3c8c23013595d3...). So there's some funkiness in this area.
Omar, could you provide me with a configuration file that reproduces this for you? Is there an easy way to check for this situation on the command line?
Here's a script that reproduces it:
``` #!/bin/sh
set -e
host_arch=x86_64 compiler_version="12.4.0"
compiler_dir="/tmp/arm64-gcc-$compiler_version" if [ ! -e "$compiler_dir" ]; then rm -rf "$compiler_dir.tmp" mkdir "$compiler_dir.tmp" curl -L "https://mirrors.kernel.org/pub/tools/crosstool/files/bin/%24host_arch/%24com..." | tar -C "$compiler_dir.tmp" -Jx mv "$compiler_dir.tmp" "$compiler_dir" fi
export PATH="$compiler_dir/gcc-$compiler_version-nolibc/aarch64-linux/bin:$PATH" make ARCH=arm64 CROSS_COMPILE=aarch64-linux- tinyconfig make ARCH=arm64 CROSS_COMPILE=aarch64-linux- -j$(nproc) vmlinux readelf -W -l vmlinux | awk '$1 == "LOAD" && $6 ~ /0x0+>/' ```
It prints something like:
LOAD 0x1ef008 0x0000000000000000 0xffff800080220000 0x000000 0x000000 R 0x10000
I.e., a segment with FileSiz and MemSiz 0.
Using a newer crosstool version fixes it, so maybe this was a GCC or binutils bug.
Thanks, Omar
On Wed, Nov 05, 2025 at 01:53:13PM -0800, Omar Sandoval wrote:
Here's a script that reproduces it:
#!/bin/sh set -e host_arch=x86_64 compiler_version="12.4.0" compiler_dir="/tmp/arm64-gcc-$compiler_version" if [ ! -e "$compiler_dir" ]; then rm -rf "$compiler_dir.tmp" mkdir "$compiler_dir.tmp" curl -L "https://mirrors.kernel.org/pub/tools/crosstool/files/bin/$host_arch/$compiler_version/$host_arch-gcc-$compiler_version-nolibc-aarch64-linux.tar.xz" | tar -C "$compiler_dir.tmp" -Jx mv "$compiler_dir.tmp" "$compiler_dir" fi export PATH="$compiler_dir/gcc-$compiler_version-nolibc/aarch64-linux/bin:$PATH" make ARCH=arm64 CROSS_COMPILE=aarch64-linux- tinyconfig make ARCH=arm64 CROSS_COMPILE=aarch64-linux- -j$(nproc) vmlinux readelf -W -l vmlinux | awk '$1 == "LOAD" && $6 ~ /0x0+\>/'It prints something like:
LOAD 0x1ef008 0x0000000000000000 0xffff800080220000 0x000000 0x000000 R 0x10000
I.e., a segment with FileSiz and MemSiz 0.
Thank you, that was incredibly helpful.
Using a newer crosstool version fixes it, so maybe this was a GCC or binutils bug.
Good observation, as this was reproducible with GCC 12.4.0 from kernel.org but not GCC 12.5.0, which I noticed has a newer binutils version. I was able to reproduce it with a self compiled copy of binutils 2.42 but not with binutils 2.44 so I reverse bisected the fix to [1], which certainly makes sense :)
The diff of 'readelf -lW' before that change:
diff --git a/tmp/.psub.9QY0ZO b/tmp/.psub.6lHG9T index 7f7f4de7be8..ea3a9b4ffb0 100644 --- a/tmp/.psub.9QY0ZO +++ b/tmp/.psub.6lHG9T @@ -7,14 +7,14 @@ Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x010000 0xffff800080000000 0xffff800080000000 0x14f000 0x14f000 R E 0x10000 LOAD 0x160000 0xffff800080150000 0xffff800080150000 0x08f008 0x0c4c40 RWE 0x10000 - LOAD 0x1f0000 0xffff800080220000 0xffff800080220000 0x000d08 0x000d08 R 0x10000 + LOAD 0x1ef008 0x0000000000000000 0xffff800080220000 0x000000 0x000000 R 0x10000 NOTE 0x1860f8 0xffff8000801760f8 0xffff8000801760f8 0x000054 0x000054 R 0x4 - GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10 + GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x8
Section to Segment mapping: Segment Sections... 00 .head.text .text 01 .rodata __param __ex_table .notes .rodata.text .init.text .exit.text .altinstructions .init.data runtime_shift_d_hash_shift runtime_ptr_dentry_hashtable .data..percpu .data .mmuoff.data.write .mmuoff.data.read .bss - 02 .modinfo + 02 03 .notes 04
After:
diff --git a/tmp/.psub.x5uqM8 b/tmp/.psub.LHoP7d index 7f7f4de7be8..27bda6ea7cc 100644 --- a/tmp/.psub.x5uqM8 +++ b/tmp/.psub.LHoP7d @@ -1,20 +1,18 @@
Elf file type is EXEC (Executable file) Entry point 0xffff800080000000 -There are 5 program headers, starting at offset 64 +There are 4 program headers, starting at offset 64
Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x010000 0xffff800080000000 0xffff800080000000 0x14f000 0x14f000 R E 0x10000 LOAD 0x160000 0xffff800080150000 0xffff800080150000 0x08f008 0x0c4c40 RWE 0x10000 - LOAD 0x1f0000 0xffff800080220000 0xffff800080220000 0x000d08 0x000d08 R 0x10000 NOTE 0x1860f8 0xffff8000801760f8 0xffff8000801760f8 0x000054 0x000054 R 0x4 - GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10 + GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x8
Section to Segment mapping: Segment Sections... 00 .head.text .text 01 .rodata __param __ex_table .notes .rodata.text .init.text .exit.text .altinstructions .init.data runtime_shift_d_hash_shift runtime_ptr_dentry_hashtable .data..percpu .data .mmuoff.data.write .mmuoff.data.read .bss - 02 .modinfo - 03 .notes - 04 + 02 .notes + 03
I am not really sure how to workaround this in a concise way... at least for arm64 since it does not seem to use PHDRS to describe ELF segments, it just relies on the default linker heuristics? It also seems seems like this is a generic problem not specific to .modinfo, we just so happen to see it with this section since it is in its own segment and we are removing it.
[1]: https://sourceware.org/git/?p=binutils-gdb.git%3Ba=commit%3Bh=7f26d260ef76a4...
Cheers, Nathan
+ Nicolas and Alexey, just as an FYI.
Top of thread is:
https://lore.kernel.org/7fef7507-ad64-4e51-9bb8-c9fb6532e51e@linux.ibm.com/
On Tue, Nov 04, 2025 at 04:54:38PM +0530, Venkat Rao Bagalkote wrote:
IBM CI has also reported this error.
Error:
depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix INSTALL /boot depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix
Git bisect is pointing to below commit as first bad commit.
d50f21091358b2b29dc06c2061106cdb0f030d03 is the first bad commit commit d50f21091358b2b29dc06c2061106cdb0f030d03 Author: Dimitri John Ledkov dimitri.ledkov@surgut.co.uk Date: Sun Oct 26 20:21:00 2025 +0000
kbuild: align modinfo section for Secureboot Authenticode EDK2 compat
Thank you for the bisect. I can reproduce this with at least kmod 29.1, which is the version I can see failing in drgn's CI from Ubuntu Jammy (but I did not see it with kmod 34, which is the latest version in Arch Linux at the moment).
Could you and Omar verify if the following diff resolves the error for you? I think this would allow us to keep Dimitri's fix for the Authenticode EDK2 calculation (i.e., the alignment) while keeping kmod happy. builtin.modules.modinfo is the same after this diff as it was before Dimitri's change for me.
Cheers, Nathan
diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux index ced4379550d7..c3f135350d7e 100644 --- a/scripts/Makefile.vmlinux +++ b/scripts/Makefile.vmlinux @@ -102,11 +102,23 @@ vmlinux: vmlinux.unstripped FORCE # modules.builtin.modinfo # ---------------------------------------------------------------------------
+# .modinfo in vmlinux is aligned to 8 bytes for compatibility with tools that +# expect sufficiently aligned sections but the additional NULL bytes used for +# padding to satisfy this requirement break certain versions of kmod with +# +# depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix +# +# Strip the trailing padding bytes after extracting the .modinfo sections to +# comply with what kmod expects to parse. +quiet_cmd_modules_builtin_modinfo = GEN $@ + cmd_modules_builtin_modinfo = $(cmd_objcopy); \ + sed -i 's/\x00+$$/\x00/g' $@ + OBJCOPYFLAGS_modules.builtin.modinfo := -j .modinfo -O binary
targets += modules.builtin.modinfo modules.builtin.modinfo: vmlinux.unstripped FORCE - $(call if_changed,objcopy) + $(call if_changed,modules_builtin_modinfo)
# modules.builtin # ---------------------------------------------------------------------------
On 05/11/25 6:26 am, Nathan Chancellor wrote:
- Nicolas and Alexey, just as an FYI.
Top of thread is:
https://lore.kernel.org/7fef7507-ad64-4e51-9bb8-c9fb6532e51e@linux.ibm.com/
On Tue, Nov 04, 2025 at 04:54:38PM +0530, Venkat Rao Bagalkote wrote:
IBM CI has also reported this error.
Error:
depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix INSTALL /boot depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix
Git bisect is pointing to below commit as first bad commit.
d50f21091358b2b29dc06c2061106cdb0f030d03 is the first bad commit commit d50f21091358b2b29dc06c2061106cdb0f030d03 Author: Dimitri John Ledkov dimitri.ledkov@surgut.co.uk Date: Sun Oct 26 20:21:00 2025 +0000
kbuild: align modinfo section for Secureboot Authenticode EDK2 compat
Thank you for the bisect. I can reproduce this with at least kmod 29.1, which is the version I can see failing in drgn's CI from Ubuntu Jammy (but I did not see it with kmod 34, which is the latest version in Arch Linux at the moment).
Could you and Omar verify if the following diff resolves the error for you? I think this would allow us to keep Dimitri's fix for the Authenticode EDK2 calculation (i.e., the alignment) while keeping kmod happy. builtin.modules.modinfo is the same after this diff as it was before Dimitri's change for me.
Cheers, Nathan
diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux index ced4379550d7..c3f135350d7e 100644 --- a/scripts/Makefile.vmlinux +++ b/scripts/Makefile.vmlinux @@ -102,11 +102,23 @@ vmlinux: vmlinux.unstripped FORCE # modules.builtin.modinfo # --------------------------------------------------------------------------- +# .modinfo in vmlinux is aligned to 8 bytes for compatibility with tools that +# expect sufficiently aligned sections but the additional NULL bytes used for +# padding to satisfy this requirement break certain versions of kmod with +# +# depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix +# +# Strip the trailing padding bytes after extracting the .modinfo sections to +# comply with what kmod expects to parse. +quiet_cmd_modules_builtin_modinfo = GEN $@
cmd_modules_builtin_modinfo = $(cmd_objcopy); \sed -i 's/\x00\+$$/\x00/g' $@- OBJCOPYFLAGS_modules.builtin.modinfo := -j .modinfo -O binary
targets += modules.builtin.modinfo modules.builtin.modinfo: vmlinux.unstripped FORCE
- $(call if_changed,objcopy)
- $(call if_changed,modules_builtin_modinfo)
# modules.builtin # ---------------------------------------------------------------------------
This change fixes the reported issue. You can add below tag as well, while sending a patch.
Tested-by: Venkat Rao Bagalkote venkat88@linux.ibm.com
Regards,
Venkat.
On Tue, Nov 04, 2025 at 05:56:03PM -0700, Nathan Chancellor wrote:
- Nicolas and Alexey, just as an FYI.
Top of thread is:
https://lore.kernel.org/7fef7507-ad64-4e51-9bb8-c9fb6532e51e@linux.ibm.com/
On Tue, Nov 04, 2025 at 04:54:38PM +0530, Venkat Rao Bagalkote wrote:
IBM CI has also reported this error.
Error:
depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix INSTALL /boot depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix
Git bisect is pointing to below commit as first bad commit.
d50f21091358b2b29dc06c2061106cdb0f030d03 is the first bad commit commit d50f21091358b2b29dc06c2061106cdb0f030d03 Author: Dimitri John Ledkov dimitri.ledkov@surgut.co.uk Date: Sun Oct 26 20:21:00 2025 +0000
kbuild: align modinfo section for Secureboot Authenticode EDK2 compat
Thank you for the bisect. I can reproduce this with at least kmod 29.1, which is the version I can see failing in drgn's CI from Ubuntu Jammy (but I did not see it with kmod 34, which is the latest version in Arch Linux at the moment).
Could you and Omar verify if the following diff resolves the error for you? I think this would allow us to keep Dimitri's fix for the Authenticode EDK2 calculation (i.e., the alignment) while keeping kmod happy. builtin.modules.modinfo is the same after this diff as it was before Dimitri's change for me.
Cheers, Nathan
diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux index ced4379550d7..c3f135350d7e 100644 --- a/scripts/Makefile.vmlinux +++ b/scripts/Makefile.vmlinux @@ -102,11 +102,23 @@ vmlinux: vmlinux.unstripped FORCE # modules.builtin.modinfo # --------------------------------------------------------------------------- +# .modinfo in vmlinux is aligned to 8 bytes for compatibility with tools that +# expect sufficiently aligned sections but the additional NULL bytes used for +# padding to satisfy this requirement break certain versions of kmod with +# +# depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix +# +# Strip the trailing padding bytes after extracting the .modinfo sections to +# comply with what kmod expects to parse. +quiet_cmd_modules_builtin_modinfo = GEN $@
cmd_modules_builtin_modinfo = $(cmd_objcopy); \sed -i 's/\x00\+$$/\x00/g' $@OBJCOPYFLAGS_modules.builtin.modinfo := -j .modinfo -O binary targets += modules.builtin.modinfo modules.builtin.modinfo: vmlinux.unstripped FORCE
- $(call if_changed,objcopy)
- $(call if_changed,modules_builtin_modinfo)
# modules.builtin # ---------------------------------------------------------------------------
Thanks for the quick fix, this worked for me on a machine with kmod version 28.
Tested-by: Omar Sandoval osandov@fb.com
Thanks, Omar
On 05/11/25 6:26 am, Nathan Chancellor wrote:
- Nicolas and Alexey, just as an FYI.
Top of thread is:
https://lore.kernel.org/7fef7507-ad64-4e51-9bb8-c9fb6532e51e@linux.ibm.com/
On Tue, Nov 04, 2025 at 04:54:38PM +0530, Venkat Rao Bagalkote wrote:
IBM CI has also reported this error.
Error:
depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix INSTALL /boot depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix
Git bisect is pointing to below commit as first bad commit.
d50f21091358b2b29dc06c2061106cdb0f030d03 is the first bad commit commit d50f21091358b2b29dc06c2061106cdb0f030d03 Author: Dimitri John Ledkov dimitri.ledkov@surgut.co.uk Date: Sun Oct 26 20:21:00 2025 +0000
kbuild: align modinfo section for Secureboot Authenticode EDK2 compat
Thank you for the bisect. I can reproduce this with at least kmod 29.1, which is the version I can see failing in drgn's CI from Ubuntu Jammy (but I did not see it with kmod 34, which is the latest version in Arch Linux at the moment).
Could you and Omar verify if the following diff resolves the error for you? I think this would allow us to keep Dimitri's fix for the Authenticode EDK2 calculation (i.e., the alignment) while keeping kmod happy. builtin.modules.modinfo is the same after this diff as it was before Dimitri's change for me.
Cheers, Nathan
diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux index ced4379550d7..c3f135350d7e 100644 --- a/scripts/Makefile.vmlinux +++ b/scripts/Makefile.vmlinux @@ -102,11 +102,23 @@ vmlinux: vmlinux.unstripped FORCE # modules.builtin.modinfo # --------------------------------------------------------------------------- +# .modinfo in vmlinux is aligned to 8 bytes for compatibility with tools that +# expect sufficiently aligned sections but the additional NULL bytes used for +# padding to satisfy this requirement break certain versions of kmod with +# +# depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix +# +# Strip the trailing padding bytes after extracting the .modinfo sections to +# comply with what kmod expects to parse. +quiet_cmd_modules_builtin_modinfo = GEN $@
cmd_modules_builtin_modinfo = $(cmd_objcopy); \sed -i 's/\x00\+$$/\x00/g' $@- OBJCOPYFLAGS_modules.builtin.modinfo := -j .modinfo -O binary
targets += modules.builtin.modinfo modules.builtin.modinfo: vmlinux.unstripped FORCE
- $(call if_changed,objcopy)
- $(call if_changed,modules_builtin_modinfo)
# modules.builtin # ---------------------------------------------------------------------------
Hi,
This change fixes the reported issue. You can add below tag as well, while sending a patch.
Tested-by: Samir M samir@linux.ibm.com
Thank you for the fix !!
Regards,
Samir
linux-stable-mirror@lists.linaro.org
-
Alexey Gladkov -
Dimitri John Ledkov -
Nathan Chancellor -
Omar Sandoval -
Samir M -
Venkat Rao Bagalkote