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
… arithmetic module
…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 |
No description provided.