Conversation
…flow - add --stage0-image in rootfs.py for qemu to boot an existing kernel-bootstrap image - when --stage0-image is combined with --build-guix-also, update BUILD_GUIX_ALSO in image config and sync /steps-guix into the image - require stage0 /init to contain guix handoff marker instead of patching /init implicitly - add run_steps_guix_if_requested() to make_bootable-generated /init so rebooted stage0 images can enter steps-guix directly - run /steps-guix/0.sh with bash in after.sh - make script-generator start mode convention-based: /steps stays kaem-first, alternate roots (e.g. /steps-guix) start in bash - remove redundant explicit /steps config-root argument from seed/preseeded/reconfigure script-generator calls
Drop the manual make -C opcodes i386-gen call from pass1.sh and rely on default_src_compile instead. This avoids failures when opcodes/ is not yet available in the current build context (make: *** opcodes: No such file or directory) and matches the stable top-level recursive build flow used elsewhere in the project.
- add gcc-15.2.0 to steps-guix manifest after binutils-2.41 - keep full gcc-15.2.0 pass1 src_prepare cleanup/regeneration flow - switch configure/build/install to kernel toolchain bootstrap mode: --without-headers, --enable-multilib, all-gcc, all-target-libgcc - install into /kernel-toolchain and prioritize /kernel-toolchain/bin in PATH - add missing gcc distfiles entry for SARIF spec - include decDPD helper files used during src_prepare
The stage1 gcc build runs with --without-headers, but all-target-libgcc was still pulling in gthr-default.h and failing on missing pthread.h. Adjust steps-guix/gcc-15.2.0/pass1.sh configure flags to match a headers-free bootstrap profile: - add --disable-threads - add --disable-shared - add --disable-libssp - add --disable-libsanitizer - add --disable-libquadmath - add --disable-libatomic - add --disable-libgomp Keep the existing multilib bootstrap flow: - make all-gcc - make all-target-libgcc - make install-gcc - make install-target-libgcc
- add steps-guix/argp-standalone-1.4.1/pass1.sh - run autoreconf before configure - build/install with standard flow into /kernel-toolchain - wire argp-standalone-1.4.1 into steps-guix manifest after gcc - prepare argp for later kernel-side elfutils dependency
When booting with --stage0-image, mirror ports can change between runs (e.g. file:// -> transient SimpleMirror port), but the reused image kept stale MIRRORS/MIRRORS_LEN values in /steps/bootstrap.cfg. Update stage0-work image preparation to patch bootstrap.cfg on each run: - rewrite MIRRORS and MIRRORS_LEN from current CLI mirrors - keep existing --build-guix-also handoff checks/sync behavior This fixes guest downloads trying old 10.0.2.2:<stale-port> endpoints during steps-guix builds.
…stsuite argp-standalone pass1 builds in a separate build directory. Its testsuite compiles sources that include <argp.h>, but without an explicit include path the header in the source root is not found and build fails. Set: - CPPFLAGS=-I/Users/luoyanpan/CLionProjects/guix/live-bootstrap/.. in src_configure so testsuite objects can resolve argp.h during the normal phase.
…olchain instead of relying on make install
…generation and fts/argp env wiring
…al LIBS and setting host/build + kernel-toolchain env
…ied sha256 and wire it before elfutils
…hs, and disable unused-but-set-variable as error
…compress, and debuginfod client
…mpile via rpath-link and explicit LIBS
…r and make rootfs resume dispatch direct
…nd move build script to pass2
|
I've run into a new problem. While building glibc-2.2.5-mesboot0, it's been stuck at this step for a long time (about 12 hours now), and I'm not sure what's causing it(maybe a deadlock? I am not sure, It may related to the bootstrap binary). Could you please take a look at this issue please? pstree command shows like this: |
|
I've seen the same issue as well on bare metal. Seems like an issue with our bootstrap Guile - did you try if using the official binary one (2.0.9) fixes it? |
sorry maybe that is my issue, i didn't put https://ftpmirror.gnu.org/guix/bootstrap/i686-linux/20190815/ base on this, it shows that 2.2.4 is what actually been used So the key is to figure out exactly how these Bootstrap binaries are built. Of course, we also need to debug why it’s getting stuck here. EDIT: not the |
|
@Googulator I hope these issues can be resolved. A standard Guix system works fine, so perhaps the problem still lies in the preparation of the bootstrap binaries. Debugging these binaries is quite difficult, and I’m afraid there’s not much I can do about it. If you have the time, I’d really love for us to work together to solve this problem. |
|
I am trying guile 2.0.9 right now |
|
Using Guile 2.0.9 with the official patches, I successfully built to see the content I'll run it again right away to see if I can get the full log, It might still be related to a Bootstrap Guile bug or a memory issue. EDIT: i didn't see the issue now, if anyone have a idea, pls share |
|
Managed to reproduce the glibc-headers-mesboot-2.16.0 issue - bootar's xz implementation is failing to decompress glibc's tarball: |
it's likely still a bootstrap Guile issue? Is this a problem caused by using i686-linux bootstrap guix on guix x86_64-linux target? |
|
i686-linux Guile is correct for bootstrapping x86_64 Guix - the bootstrap sequence includes an explicit cross-compiler step to move from i686 to x86_64. IMO it's more likely to be either a musl vs. glibc issue, or something caused by our too-new GCC (the original bootstrap-guile was built using GCC 4.7 or 4.8 - it's not entirely clear; both versions are referenced in the binary). One option would be to build native coreutils & compression tools earlier (maybe also a real Bash), as that not only takes responsibilities off of bootstrap-guile, avoiding future issues like this, but it would also greatly speed up the build, as most of the time is currently spent starting up instances of bootstrap-guile for each invocation of "test" in shell scripts. (Coreutils "test" is 100x faster on my bootstrap rig than its gash-utils reimplementation, and the real Bash has a built-in "test" command which is 100x faster than coreutils, making "test" operations effectively instantaneous.) |
|
You're absolutely right. However, my question is, when using the official Guix image, running the same command doesn't seem to cause any issues. Is this really a problem with glibc and musl? If that's the case, I think we need evidence to prove that this bug is caused by differences in libc, or we just give it a try, build a glibc for guile and its dependencies, if that solve problem, then it prove that it's because of the libc difference But I should also mention that I encountered the same issue when I compiled Guile using glibc by hand last time, uses a 64-bit toolchain, glibc 2.34, and guile 2.2, idk if I change to a older glibc and 32-bit toolchain can solve the problem The complete log from that time: guix-pull-2.log.txt.zip So, The current evidence does not support the idea that the behavioral differences are caused by libc variations. It might be due to GCC, since I was also using a very recent version of GCC at the time, which is GCC 13. I'd still like to know exactly how to solve this problem And also, based on the guix code, it actually use different guile version for The hash values are different. When I run It is worth noting that this package is not downloaded directly from a remote server; instead, after downloading and extracting it, it is repackaged using an existing |
…e xz 5.0.6, just give it a try to solve problem
3 participants
No description provided.