From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id WFA0IwoqFWdK4gAAqHPOHw:P1 (envelope-from ) for ; Sun, 20 Oct 2024 16:04:26 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id WFA0IwoqFWdK4gAAqHPOHw (envelope-from ) for ; Sun, 20 Oct 2024 18:04:26 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=icepic.de header.s=x header.b=XSNbwvFB; spf=pass (aspmx1.migadu.com: domain of "help-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="help-guix-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1729440266; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=tiirGscilyBLx4ciAdXtCxA4FIJD7kwUoDz1H79v4vI=; b=IUsmip+ITdubfufWyZrC/4IDv5jN2VelMfxyeTvQRu50uRsLeoPz8Yq+hnZ1a272uUh1hO kM8sVSHAvxsUj7lRi4YL/dPoCXbaJoB8gwvRNY4cXv53Kj3wk+y0H0Yl+q4SHhtXlkkiaP YchtiKKoerWTZGOtdLUscSbX7SLWoXBy1HaxrXFSbtdVs95r5Juijj+jbooys5hSBwNIVb pUXh0XnZ3ajxxKzsiICaqn0KfexjwPg9bDxz0Nf9JggFNhBtGIhqZ/vfVZmyFcAXv5bmZ7 yi7U6tzZOmnuIcrKQDarq50n2ncUY5JGIgBD7k/nIRSsuzzX3av/gQDEu9m1Hg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=icepic.de header.s=x header.b=XSNbwvFB; spf=pass (aspmx1.migadu.com: domain of "help-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="help-guix-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1729440266; a=rsa-sha256; cv=none; b=biISoisD96tU7MQEhN2UPzvpn51KfcZoMVMMhC2gEMc7ScGMe8+37CjfbdC74Ui7jcS2ka FOufuiVxmiv4RVn1lm+LaYsXYQREIpMZZ8aK10RXEFCrZTRamnSbgR0QwFEvNCjDdALAya 42nFSZ2KEm13P3jPPXWF2Uz98bDOHYpLmXKCURdJlR3jcfUePhwAUzQnftSsjccmsihP8m jfVLbsaVcw77bOxzN85zSQPYlswkwhkdc5YAkSoAK34ubTOKes+7UEGYr5kACpfaTAb5DE jDdoaEGmZbj7i/opjMZzep6NcWXVcVu6tuAJLcceXkqo3JLfZTSM2t3g/13p5A== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 2AA8180F30 for ; Sun, 20 Oct 2024 18:04:26 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t2Xmj-0000CF-DR; Sun, 20 Oct 2024 11:24:01 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t2Xmh-0000Bs-8y for help-guix@gnu.org; Sun, 20 Oct 2024 11:23:59 -0400 Received: from mail-108-mta204.mxroute.com ([136.175.108.204]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t2Xmf-0002lC-B6 for help-guix@gnu.org; Sun, 20 Oct 2024 11:23:59 -0400 Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta204.mxroute.com (ZoneMTA) with ESMTPSA id 192aa871ead0003e01.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sun, 20 Oct 2024 15:23:54 +0000 X-Zone-Loop: c8272b77ae9f7350316bc5e81653f0fd644e91e426bf X-Originating-IP: [136.175.111.3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=icepic.de; s=x; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=tiirGscilyBLx4ciAdXtCxA4FIJD7kwUoDz1H79v4vI=; b=XSNbwvFBzxY54UmOxLQx2WnHrl 2EtQ1sN0j5z7ic+xnlaez/m7eyOeP9MJKu2ofLXJGz2kD/TLNnC4cos0zYMFXsHXZw5LvlRwAAw0m pU31+60kXEGVtSHFeQwWhNOjsK2+zCXVFW6FWpaRvlJo8sOzQip6YMsbv0TmJCJJlu40eONb8KfLE cp4ThGZByNQZn3DCCqOK0V5zTEkeaC0pXY0lcE6xgX+WHKOs3EZ2dPr2zS273H0x7Yosvl3xqOfkP nQ94fz7p8Bw+7tyCmNwvwJXQoUFUmfK+e9YCaqsXAf4c85G8cmSYtAizVjXEw/pptuscwPg2J0f8/ 44+e/f2g==; From: Christoph Buck To: help-guix@gnu.org Subject: Re: ABI mismatch on boot on arm32 system In-Reply-To: <87y12opdbh.fsf@icepic.de> (Christoph Buck's message of "Wed, 16 Oct 2024 12:11:30 +0200") References: <87y12opdbh.fsf@icepic.de> User-Agent: mu4e 1.12.0; emacs 30.0.50 Date: Sun, 20 Oct 2024 17:23:52 +0200 Message-ID: <87iktmhk6v.fsf@icepic.de> MIME-Version: 1.0 Content-Type: text/plain X-Authenticated-Id: dev@icepic.de Received-SPF: pass client-ip=136.175.108.204; envelope-from=dev@icepic.de; helo=mail-108-mta204.mxroute.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-guix@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+larch=yhetil.org@gnu.org Sender: help-guix-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx11.migadu.com X-Migadu-Spam-Score: 4.50 X-Spam-Score: 4.50 X-Migadu-Queue-Id: 2AA8180F30 X-TUID: Qo11uENAZbfW Hi! I played around a little bit more and i can indeed now successfully boot. Instead of using cross-compilation (cli option `--target=arm-linux-gnueabihf`) i created a build using qemu emulation (cli option `--system=armhf-linux`). This takes ages to build, but the resulting images is bootable without abi error. Unfortunatly this is not a real fix because it is too slow to be a practical workaround (at least for me). I digged a little deeper and this is what i found out so far. In case i am running off in a totally wrong direction, someone with more clue than me should please stop me ;) I think something goes wrong during crosscompilation of the guile modules in package `module-import-compiled`. The abi error is thrown early on boot in the `initrd.cpio.gz` ramdisk. I extracted and decompressed the ramdisk from both builds (crosscompilation and qemu) which contain the `module-import-compiled` guile modules. I would expect that the *.go files from the `module-import-compiled` package of both ramdisks are binary identical but they have different md5sums. Lets take for example `file-systems.go`, which cause the abi error. --8<---------------cut here---------------start------------->8--- local@host:crosscompilation-initrd/gnu/store/5ffy1h3fgikzdhfz4nkchxnibbri4ain-module-import-compiled/gnu/system$ md5sum file-systems.go 7839e9c7a0c7c6c8d9ea45566ab9f61e file-systems.go --8<---------------cut here---------------end--------------->8--- vs --8<---------------cut here---------------start------------->8--- local@host:qemu-initrd/gnu/store/hvgj80xqf70mvx460pnvwmi87kqqn2bj-module-import-compiled/gnu/system$ md5sum file-systems.go a43a7e939ae9d0cc1ce30726cb51d6d4 file-systems.go --8<---------------cut here---------------end--------------->8--- Additional it looks like different symbols are exported depending if cross-compilation or qemu was used. This is at least what `readelf -s file-system.go` reports. I naively thought these files should be identical. Additional i saw these strange errors in the build log during crosscompilation --8<---------------cut here---------------start------------->8--- ;;; WARNING: loading compiled file /gnu/store/5ffy1h3fgikzdhfz4nkchxnibbri4ain-module-import-compiled/gnu/build/file-systems.go failed: ;;; In procedure load-thunk-from-memory: ELF file does not have native word size ;;; WARNING: loading compiled file /gnu/store/5ffy1h3fgikzdhfz4nkchxnibbri4ain-module-import-compiled/gnu/system/uuid.go failed: ;;; In procedure load-thunk-from-memory: ELF file does not have native word size ;;; WARNING: loading compiled file /gnu/store/5ffy1h3fgikzdhfz4nkchxnibbri4ain-module-import-compiled/gnu/system/file-systems.go failed: ;;; In procedure load-thunk-from-memory: ELF file does not have native word size --8<---------------cut here---------------end--------------->8--- This also looks suspicious. These stem from the `check_elf_header` function in guile. Guile warns that the class type in the elf header is 32bits if executed in a cross-compiliation context on an x64 system. But until now i couldn't figure out, if i can ignore these warnings or if they might cause a problem. -- Best regards Christoph I did some further digging into this issue. it warns if the class type in the elf header is 32bit. Christoph Buck writes: > Hi! > > Currently i am trying to create an guix image which will boot on > embedded imx6 arm32 board. Following the guix manual, i was able to > create such an image. This involved adding a custom uboot version and a > kernel with custom definition file. If flashed on an sdcard, the uboot > runs and the kernel boots. However, early on boot (presumably on > executing initrd.cpio.gz), an `record-abi-mismatch-error` is thrown and > a guix recovery repl is opened > >> Use 'gnu.repl' for an initrd REPL. > >> ice-9/boot-9.scm:1685:16: In procedure raise-exception: >> Throw to key `record-abi-mismatch-error' with args `(abi-check "~a: record ABI mismatch; recompilation needed" (#>) ())'. > >> Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. >> GNU Guile 3.0.9 >> Copyright (C) 1995-2023 Free Software Foundation, Inc. > >> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. >> This program is free software, and you are welcome to redistribute it >> under certain conditions; type `,show c' for details. > > Unfortunatly i have absolutely no clue what the problem could be. Could > it be that the image was compiled with a differnt guile version than > executet on the image? Could this explain the abi mismatch in the > `file-system` record? > > Googling for the error i found the following post on this mailing list: > >> https://lists.gnu.org/archive/html/help-guix/2023-02/msg00147.html > > Seems like Maxim Cournoyer had the same problem with a board with the > same socc (imx6). Unfortunatly no followup. (I mailed him in private in > case he come up with a solution. If so, i will document it here, so that > the next unlucky soul running into this error can find the solution). > > I cross-compile the image on x64 with > >> guix build -f custom-board.scm --target=arm-linux-gnueabihf -v3 -c2 -M2 -K --no-grafts > > where `custom-board.scm` is my image definition (i can share it if > helpfull). Option `--no-grafts` is needed due to > >> https://issues.guix.gnu.org/66866 > > For tips on how to debug this issue further i would be very > grateful. Feels like i am very close to a bootable image. -- Best regards Christoph