[-- Attachment #1: Type: text/plain, Size: 529 bytes --] Hello, I tried the 1.2.0 graphical installer at ae0fe28, installing Guix System from a usb drive to another one. I had three issues: * The auto partitioning crashed, backtrace as attachment. * Using manual partitioning as a work-around, I started the installation and observed that the installer downloaded "python" sources and then substitutes for the whole bootstrapping chain (also as attachment). * The substitutes download speed was sometimes super low (~ 50Kb/s). An unpleasant sunday afternoon testing :(. Mathieu [-- Attachment #2: backtrace.jpg --] [-- Type: image/jpeg, Size: 231630 bytes --] [-- Attachment #3: config.jpg --] [-- Type: image/jpeg, Size: 238542 bytes --] [-- Attachment #4: bootstrap.jpg --] [-- Type: image/jpeg, Size: 317692 bytes --]
Hi, Mathieu Othacehe <othacehe@gnu.org> skribis: > I tried the 1.2.0 graphical installer at ae0fe28, installing Guix System > from a usb drive to another one. > > I had three issues: > > * The auto partitioning crashed, backtrace as attachment. Argh. > * Using manual partitioning as a work-around, I started the installation > and observed that the installer downloaded "python" sources and then > substitutes for the whole bootstrapping chain (also as attachment). Could it be that these get downloaded due to some “debug” output being pulled (perhaps unnecessarily so but grafting can do that sometimes)? > * The substitutes download speed was sometimes super low (~ 50Kb/s). Yes, unfortunately non-offloaded disk image builds (fixed by recent commits) along with GC running all day long has a terrible impact on bandwidth. It should get a bit better at least now that disk image builds will no longer happen on the head node, but OTOH there’s still a lot of build activity happening and that definitely increases pressure. I look forward to the day where using the Build Coordinator we can better decouple the build farm from the node running ‘guix publish’. Thanks, Ludo’.
Hey, I cannot reproduce the partitioning issue which is even more frustrating. I guess it was related to the original partitioning of the USB drive I used. Added some more debug logging with 8c287bb2fb1 in the meantime. > Could it be that these get downloaded due to some “debug” output being > pulled (perhaps unnecessarily so but grafting can do that sometimes)? I'm not sure yet but I'll run more tests tomorrow. >> * The substitutes download speed was sometimes super low (~ 50Kb/s). > > Yes, unfortunately non-offloaded disk image builds (fixed by recent > commits) along with GC running all day long has a terrible impact on > bandwidth. Oh, right. Thanks for your recent patches on this subject. It should definitely help. Having berlin doing nothing much that serving substitutes and coordinating the build machines will solve many issues. I'm working on that topic and will present my progress during Guix Days! Thanks, Mathieu
Hello, I tried again on commit 86e9e5c using an image built by the CI and an image built locally. I was not able to reproduce any of the issues I had initially. Closing this one until we find a reproducible way to trigger those issues. Thanks, Mathieu