Summary: | app-admin/eclean-kernel-2.99.7 fails tests on big-endian: ecleankernel.file.UnrecognizedKernelError: Kernel file ... terminates before expected version string position (4608) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | matoro <matoro_gentoo> |
Component: | Current packages | Assignee: | Michał Górny <mgorny> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | andrewammerlaan, matoro_gentoo |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 891511 | ||
Attachments: |
build.log and emerge --info from ppc64 BE
build.log and emerge --info from sparc |
Description
matoro
2023-12-19 01:02:02 UTC
Created attachment 879887 [details]
build.log and emerge --info from ppc64 BE
Created attachment 879888 [details]
build.log and emerge --info from sparc
Hmm, I suppose bzImage format is specific to LE platforms, so I guess I can just force LE there. Andrew, could you advise here? I suppose you know more about kernels than I do. (In reply to Michał Górny from comment #4) > Andrew, could you advise here? I suppose you know more about kernels than I > do. I have not yet dug very deeply into this, but my first guess is that we might be able to fix this issue by switching around self.read_version_from_bzimage and self.read_version_from_raw in the for loop on line 160 of file.py. I.e try the raw image method before we try the bzimage method. Or otherwise ensure that we catch any error from read_version_from_bzimage non-fatally so we can then try the next method. Took a quick look through the kernel make files, and it does look like it is possible to make a zImage (not bzImage) instead of the standard vmlinux that we use on these arches for the dist-kernels. So maybe we don't want a 'if endianness == big; then return' in self.read_version_from_bzimage. |