Live bootstrap to guix#578
Conversation
…compress, and debuginfod client
…mpile via rpath-link and explicit LIBS
feat(steps-guix): add libgcrypt-1.12.1 default build with gcc-detected host and pkg-config path feat(steps-guix): add guile-gcrypt-0.5.0 with dynamic libgcrypt prefix and ld library path
…and end with shared after
… out-of-tree build
…IR for libgcrypt lookup
…IB_SRCDIR and no-git
…refix and checksum
…e-gnutls flow with no-so patch
…fail-safe without panic
…GUILEC load-extension segfault
…ble them in manifest
…time/localtime declarations on linux
|
Currently running a bare metal test with this diff on top of the latest commit: $ git diff
diff --git a/steps-guix/improve/guix-daemon-and-pull.sh b/steps-guix/improve/guix-daemon-and-pull.sh
index c7625474..f61b5d9f 100644
--- a/steps-guix/improve/guix-daemon-and-pull.sh
+++ b/steps-guix/improve/guix-daemon-and-pull.sh
@@ -218,6 +218,9 @@ mkdir -p /proc /sys /dev "${guix_localstate_dir}/daemon-socket" /var/lib/guix /r
mount | grep ' on /proc ' >/dev/null 2>&1 || mount -t proc proc /proc
mount | grep ' on /sys ' >/dev/null 2>&1 || mount -t sysfs sysfs /sys
mount | grep ' on /dev ' >/dev/null 2>&1 || mount -t devtmpfs devtmpfs /dev
+# tmpfs must be unmounted to avoid overfilling memory
+mount | grep ' on /tmp ' >/dev/null 2>&1 && umount /tmp
+test -f /swapfile && swapon /swapfile
if ! mount | grep ' on /dev/pts ' >/dev/null 2>&1; then
mkdir -p /dev/pts
mount -t devpts devpts /dev/pts
diff --git a/steps-guix/jump/linux64.sh b/steps-guix/jump/linux64.sh
index 1bb6ba93..f942c2a1 100644
--- a/steps-guix/jump/linux64.sh
+++ b/steps-guix/jump/linux64.sh
@@ -37,4 +37,8 @@ else
--append="console=ttyS0 root=/dev/sda1 init=/init rw rootwait consoleblank=0"
fi
quiesce_filesystem_for_kexec
-kexec -e
+if [ "${BARE_METAL}" = True ]; then
+ echo b > /proc/sysrq-trigger || true
+else
+ kexec -e
+fiI disabled kexec for bare metal, because I couldn't get the framebuffer to work reliably after kexecing from 32-bit 4.14-openela to 64-bit 6.12-gnu. The other change activates the swapfile, and unmounts /tmp before starting the Guix bootstrap - this was needed to avoid going OOM on my 8GiB RAM bootstrap rig. |
|
I’m also thinking about running a bare-metal setup. Is using Coreboot + SeaBIOS on a modern motherboard a viable option? |
|
If you can run Coreboot on your board, it should be, especially since qemu's default BIOS implementation is SeaBIOS. Note that I had to edit that patch in that previous comment, as I got Bash's conditional syntax wrong (it's if...fi, not if...endif). |
|
Great, I’ll add the patch shortly. |
|
There is currently no reliable method for including Closure in an ISO image and performing a guided installation. |
|
The new patch is malformed: With that fixed, I had a test failure in wmin69qfszbjz0mflj2sya8sm2r5c7bs-glib-2.83.3.drv (GLib 2.83.3), that went away on retry. Maybe we should disable tests for it? |
|
OK, after lots of wrangling... I have an ISO.More to come tomorrow. I've just came home, and am quite tired. And it did took quite some wrangling to get here. |
|
So, finally got around to writing it all up.
And then, some bad news:
|
|
Could you tell in detail why the disk partitioning failed? I'm trying to use a non-default ISO for the setup, specifically, a custom ISO that defines as few components as possible, and I'm adding the |
|
dump.2026-04-28.10.12.04.tar.gz This is the dump I was able to obtain from the failed installation. Looks like maybe the target device isn't being found. With that said, I suspect the failure might be due to some packages being built with chroot off, resulting in contamination from the live-bootstrap host environment. |
|
I tried the Manual partitioning option in Setup, only to get an empty list of potential disks to partition. |
|
what |
|
Looks like I was dumb - the mounted virtual disk had a malformed partition table on it, which confused Setup. A |
Looks like it's looking for the local channel repository inside the ISO. Cloning it should work, though. EDIT: no EDIT 2: it's not actually using substitutes; while it did look for them, what it's actually downloading is all source code, because the bootstrap changes made the upstream substitutes not match. Using the L-B system as a substitute server remains a possibility. |
|
|
Not sure if it was the exact same one, but I did occasionally see a strange failure in the check phase of guix-1.5.0rc1, that wasn't a test failure (which should move on to other tests), but something that instantly interrupted execution of the test suite. It's nondeterministic, and simply retrying helps. |
I suppose part of the concept of reproducible builds is consistency in behavior. I think that if we have time, we should look into the specific cause. As for tests that fail consistently, what I want to do is fix those failing tests. First, I’ll look into why they’re failing, whether it’s because the hashes don’t match or some other reason. |
fixed in 2a58e2c |
| -s i686-linux \ | ||
| - -- guile -c '(exit (string-prefix? "i686" %host-type))' | ||
| + -- guile -c '(exit (string=? "x86_64-pc-linux-muslx32" %host-type))' | ||
| + -- guile -c '(exit (string-prefix? "x86_64" %host-type))' |
There was a problem hiding this comment.
This amounts to effectively disabling the test, as it's meant precisely to check that on a multiarch-capable machine, the correct seed is selected based on the choice of environment (i.e. a 32-bit seed when explicitly building 32-bit on 64-bit hardware).
IMO the right fix is to patch Guile 2.0.9 so it reports the correct "i686-pc-linux-musl" architecture.
|
I'm currently trying to get Guix through the test, but I've encountered some problems.
FULL LOG |
|
Here's how some previous issues were resolved: 1. Architecture check: Forced the expected i686/x86_64 to be unified to x86_64. This was just a workaround, not a formal fix. 2. Some random failures occurred because the guix defined in |
I dont know if this related to #578 (comment) , seems a network related issue? (seems not, not directly related, what would be the potential issue?) Also, regarding the issue you mentioned with Guix 1.5.0rc1, this is because the download available on the official GNU Guix website is Guix 1.5.0rc1, not the stable release that was released on January 23, 2026. |
3 participants
No description provided.