Live bootstrap to guix#578
Conversation
…hs, and disable unused-but-set-variable as error
…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
What's the status of this issue? One thing that puzzles me is, aren't all Guix builds supposed to run in a chroot or namespace environment? |
is it something like this? |
|
No, it was a different issue. Sourcing the Guix profile ( I did encounter the issue you describe - I solved it differently, by making the 2nd copy operation conditional on the i686 and x86_64 bootstrap guile paths being different. Now, I'm facing another issue, where tests fail for the "guix-1.5.0rc1.drv" derivation. The cause seems to be that it's trying to download the official bootstrap binaries to run the tests with, but is failing to do so. IMO the right way to fix this is to inject the patches we use when building our Guix into this derivation, so it too uses the locally built bootstrap binaries instead. |
Where I am doing is to copy the original Bootstrap Guile directory, then add
Where is the definition file for this? And another question: Do you think we should make the generated ISO to be installed offline? (Because the default ISO image downloads external substitutes during the installation process, which undermines our assumption of a fully source-code-based build.) |
|
The definition file is gnu/packages/package-management.scm - I've attached the patch I used for the double-bootstrap-guile bug. The issue where tests fail due to trying to access the official binaries is also in the same package definition. IMO we should keep the ISO's ability to use substitutes, but have it default to using the bootstrap machine as its sole substitute source. The packages there are properly bootstrapped, and therefore fine to use as substitutes. |
|
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. |
3 participants
No description provided.