Report forwarded
to bug-guix@gnu.org: bug#76988; Package guix.
(Wed, 12 Mar 2025 23:19:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Vagrant Cascadian <vagrant@debian.org>:
New bug report received and forwarded. Copy sent to bug-guix@gnu.org.
(Wed, 12 Mar 2025 23:19:02 GMT) (full text, mbox, link).
In trying to create an alternate kernel configuration, I noticed that
the various kernels on x86_64 that are targeted at various specific
architectures (e.g. linux-libre-arm64-generic) ... are actually built
for X86_64:
$ file $(guix build linux-libre-arm64-generic)/bzImage
gnu/packages/linux.scm:989:2: warning: package linux-libre-arm64-generic@6.13.6 does not support x86_64-linux
/gnu/store/2jj1jxirrgiq972xbfk8cz8b9i642qq5-linux-libre-arm64-generic-6.13.6/bzImage: Linux kernel x86 boot executable bzImage, version 6.13.6-arm64-generic (guix@guix) #1 SMP PREEMPT_DYNAMIC 1, RO-rootFS, swap_dev 0XF, Normal VGA
$ grep ^CONFIG_X86_64= $(guix build linux-libre-arm64-generic)/.config
gnu/packages/linux.scm:989:2: warning: package linux-libre-arm64-generic@6.13.6 does not support x86_64-linux
CONFIG_X86_64=y
Those were downloaded from the substitute servers... and guix even
helpfully warns me that something is fishy... so it is not like I was
holding it wrong, per se! :)
These packages should either refuse to build (e.g. it does not match the
architecture, so should not even try to build) or attempt to cross build
when building on a non-native architecture.
I swear they used to cross-build for the appropriate architecture on
x86_64 out-of-the box ages ago, but there have been probably significant
changes to how cross-compilation and/or linux-libre packaging is done
since then...
$ git grep -E 'define-public linux-libre.*(generic|honey|mips|arm)' gnu/packages/linux.scm | nl
1 gnu/packages/linux.scm:(define-public linux-libre-arm-generic
2 gnu/packages/linux.scm:(define-public linux-libre-arm-generic-5.10
3 gnu/packages/linux.scm:(define-public linux-libre-arm-generic-5.4
4 gnu/packages/linux.scm:(define-public linux-libre-arm-omap2plus
5 gnu/packages/linux.scm:(define-public linux-libre-arm64-generic
6 gnu/packages/linux.scm:(define-public linux-libre-lts-arm64-generic
7 gnu/packages/linux.scm:(define-public linux-libre-arm64-generic-5.10
8 gnu/packages/linux.scm:(define-public linux-libre-arm64-generic-5.4
9 gnu/packages/linux.scm:(define-public linux-libre-arm64-honeycomb
10 gnu/packages/linux.scm:(define-public linux-libre-riscv64-generic
11 gnu/packages/linux.scm:(define-public linux-libre-mips64el-fuloong2e
Building all those package variants is a waste of build resources when
the result is not usable for the intended purpose...
Thanks for maintaining linux-libre in Guix! :)
live well,
vagrant
Subject: Re: Architecture-specific kernels (arm64-generic) built for x86_64
Date: Fri, 14 Mar 2025 15:10:25 -0400
Thanks for pointing this out!
I don't do anything regarding the "generic" arm64 kernels, so I also
don't know how they work or why they are built in any particular way.
Here's a crude command to produce a list of interesting changes to the
linux-libre packaging:
`git log v1.4.0..HEAD --grep linux-libre --oneline | grep -v Update | grep -v "Remove linux-libre" | grep -v "Add linux-libre" | grep -v "news:"`
I hope that the arm64 / aarch64 users can get them working properly! And
I invite them to join the kernel team and help out in the future too!
Information forwarded
to bug-guix@gnu.org: bug#76988; Package guix.
(Mon, 17 Mar 2025 10:54:04 GMT) (full text, mbox, link).
Cc: w@wmeyer.eu, 76988@debbugs.gnu.org, Leo Famulari <leo@famulari.name>
Subject: bug#76988: Architecture-specific kernels (arm64-generic) built for,
x86_64
Date: Mon, 17 Mar 2025 10:52:46 +0000
Hello Vagrant,
This looks to me like a problem with cuirass (or cuirass settings).
The packages are marked as unsupported correctly, e.g. the arm64-generic
kenel should only support aarch64-linux (as can be seen by the warning).
However the ci server attempts to build it for all architectures.
I searched for linux-libre-arm64-generic-6.13.7 on the cuirass
interface on ci.g.g.o and there were builds for
i686-linux, x86_64_linux, powerpc64le-linux and
aarch64-linux
As the x86_64 build succeeds it then serves the substitute to someone
asking for it.
Specifying either --system=aarch64-linux or --target=aarch64-linux-gnu
gave me a substitute corresponding to a native/cross built arm64 kernel.
file $(guix build linux-libre-arm64-generic
--target=aarch64-linux-gnu)/Image
/gnu/store/*linux-libre-arm64-generic-6.13.7/Image: Linux kernel ARM64
boot executable Image, little-endian, 4K pages
Information forwarded
to bug-guix@gnu.org: bug#76988; Package guix.
(Mon, 17 Mar 2025 16:50:01 GMT) (full text, mbox, link).
On 2025-03-17, Dariqq wrote:
> This looks to me like a problem with cuirass (or cuirass settings).
> The packages are marked as unsupported correctly, e.g. the arm64-generic
> kenel should only support aarch64-linux (as can be seen by the warning).
> However the ci server attempts to build it for all architectures.
It is definitely not specific to cuirass, as I only noticed it with
"guix build" of a custom package that would not possibly have
substitutes, and only later checked the substitute servers
(ci.guix.gnu.org, bordeax.guix.gnu.org) to see that they had the same
problem...
> I searched for linux-libre-arm64-generic-6.13.7 on the cuirass
> interface on ci.g.g.o and there were builds for
> i686-linux, x86_64_linux, powerpc64le-linux and
> aarch64-linux
>
> As the x86_64 build succeeds it then serves the substitute to someone
> asking for it.
>
> Specifying either --system=aarch64-linux or --target=aarch64-linux-gnu
> gave me a substitute corresponding to a native/cross built arm64 kernel.
>
> file $(guix build linux-libre-arm64-generic
> --target=aarch64-linux-gnu)/Image
> /gnu/store/*linux-libre-arm64-generic-6.13.7/Image: Linux kernel ARM64
> boot executable Image, little-endian, 4K pages
That is consistent with what I observed too!
live well,
vagrant
On 2025-03-14, Leo Famulari wrote:
> I don't do anything regarding the "generic" arm64 kernels, so I also
> don't know how they work or why they are built in any particular way.
Yeah, in most cases I would prefer to use the regular linux-libre
package, but sometimes it is difficult to follow the module name changes
to hard-code the appropriate list of initrd modules to find the rootfs,
and some of these kernel variants make that easier by using some =y
options that might reasonably be =m options in "linux-libre", and also
might allow patches that are not appropriate to apply to the standard
"linux-libre" packages (e.g. linux-libre-arm64-mnt-reform in
bug#77090). Or just include options that are only particular to a
particular platform, but cannot be made modules for one reason or
another... anyways... :)
I made a lazy attempt at forcing a build failure by ensuring the
appropriate architecture was set in the configuration:
#:extra-options
(append
+ `(;; Ensure we are building for arm64
+ ("CONFIG_ARM64" . #true)
But the build still picks the wrong defconfig:
*** Default configuration is based on 'x86_64_defconfig'
I presume that the checks to make sure the configuration includes the
options in #:extra-options must run before the config is generated with
the wrongly selected defconfig... ??
Interestingly, linux-libre-arm-generic does usefully fail to build early
on, but by pure luck:
starting phase `set-environment'
`ARCH' set to `x86_64'
phase `set-environment' succeeded after 0.0 seconds
starting phase `configure'
HOSTCC scripts/basic/fixdep
...
HOSTLD scripts/kconfig/conf
***
*** Can't find default configuration "arch/x86/configs/multi_v7_defconfig"!
Because it is setting ARCH to x86_64, and there is obviously no
corresponding multi_v7_defconfig. For the arm64 linux-libre variants:
#:defconfig "defconfig"
So it happily picks arch/x86/configs/defconfig...
If a custom linux-libre variant could force the ARCH value (based on
supported-systems?), this just might work as desired... or at least
usefully break earlier in the build, saving considerable build time!
When cross-compiling, ARCH and CROSS_COMPILE are set appropriately:
$ guix build --check --target=aarch64-linux-gnu linux-libre-arm64-generic
...
starting phase `set-environment'
`ARCH' set to `arm64'
`CROSS_COMPILE' set to `aarch64-linux-gnu-'
But the only option for linux-libre-arm64-generic is either native or
cross compilation, since it is an aarch64-linux/arm64 specific
package... we should be able to detect that somehow and at least fail
the build early or ideally not even attempt the build if ARCH
mismatches.
Maybe somewhere in make-linux-libre* it could have a sanity check
comparing "supported-systems" against the %current-target-system and
%current-system?
;; Set ARCH and CROSS_COMPILE.
(let ((arch #$(platform-linux-architecture
(lookup-platform-by-target-or-system
(or (%current-target-system)
(%current-system))))))
(setenv "ARCH" arch)
(format #t "`ARCH' set to `~a'~%" (getenv "ARCH"))
(when target
(setenv "CROSS_COMPILE" (string-append target "-"))
(format #t "`CROSS_COMPILE' set to `~a'~%"
(getenv "CROSS_COMPILE"))))
Thanks for considering!
live well,
vagrant
On 2025-03-21, Vagrant Cascadian wrote:
> Maybe somewhere in make-linux-libre* it could have a sanity check
> comparing "supported-systems" against the %current-target-system and
> %current-system?
This more-or-less does what I want:
(use-modules (guix platform))
(use-modules (guix packages))
(use-modules (gnu packages linux))
(define arch "arm64")
(define supported-systems
(package-supported-systems linux-libre-arm64-generic))
(define linux-supported-systems
(map (lambda (s)
(platform-linux-architecture (lookup-platform-by-target-or-system s)))
supported-systems))
(if (member arch linux-supported-systems)
(display arch)
(display "BAD"))
Manually adjusting arch to various values...
But I fail in adding it as a phase to make-linux-libre*, as
supported-supported systems is just defined as #f:
(add-before 'unpack 'check-valid-arch
(lambda* (#:key supported-systems #:allow-other-keys)
(let ((arch #$(platform-linux-architecture
(lookup-platform-by-target-or-system
(or (%current-target-system)
(%current-system))))))
(if (member arch
(map (lambda (s)
(platform-linux-architecture
(lookup-platform-by-target-or-system s)))
supported-systems))
(#true)
(#false)
))))
Also not sure if #true or #false will allow the build to continue or
fail the build here... but I am mostly generating syntax errors and
tracebacks.
live well,
vagrant
Debbugs is free software and licensed under the terms of the
GNU Public License version 2. The current version can be
obtained from https://bugs.debian.org/debbugs-source/.