Hello Brendan,
> I feel the installer should not care what was on the drive to begin with, it
> should just
> format the drive how it sees fit. Why should the existing contents of the
> drive
> affect the outcome when we are reformatting everything anyway?
That's the case except for the ESP par
Hello Brendan,
> After the install completed I pulled out the USB as per instruction on the
> screen, and pressed the Reboot button. The system then Kernel panic with the
> following messages:
>
> https://brendan.scot/p/IMG_20201018_140343.png
>
> Sorry I don't have it in textual form.
Is the i
Hello Miguel & Brendan,
> AFAIU from the code, the first partition should not be created by the
> installer but it won't be removed if it was found on the disk
> beforehand. Tomorrow I'll give a try at the full installation process,
> I must have overlooked something if it still being created i
Hey Ludo,
> I confirm that the attached patch for Bytestructures solves the problem
> (running ‘guix pull’ in my childhurd :-)).
Nice catch! I guess we had the same issue when cross-compiling for armhf
from x86_64.
Thanks,
Mathieu
Hello,
I pushed and deployed several patches that:
- update metrics in a single transaction
- register builds in a single transaction
- use a single write database worker, queuing queries and submitting
them by batches (in a single transaction).
- optimize some SQLite parameters (decrease WAL s
Hello Jonathan,
> It happens when scamping around in the database:
> update Specifications set proc_args='((subset "htop" "icedove") (systems
> "x86_64-linux))';
You mean it happens only when modifying 'proc_args' while Cuirass is
running? Could you share your specifications so that I can try t
Hello,
Over the last few weeks I made sure that all Cuirass SQL queries were
using indexes. As the "Builds" and "Outputs" tables can be really large,
having queries covered by indexes is imperative for consistent queries
duration.
However, I observed that some queries have inconsistent duration
> All of this should be combined in a unique query to minimize
> overhead. The limit should also by restricted to at most 1000 builds for
> instance.
Fixed with cb2c4e3d8f7eda187adf6da1fc35aef838c49828.
Mathieu
Hello,
When "db-get-builds" is called with a limit set to N, at least ~2N
queries are executed. First the main query returns the build list, then
build outputs and build products are searched.
All of this should be combined in a unique query to minimize
overhead. The limit should also by restri
Hey Ludo,
> Isn’t that the real problem, that we’re doing one transaction per
> derivation?
Is it really better in term of performance to send batch of queries
within a single transaction? I haven't tried it yet.
I think that the real bottleneck was having N fibers fighting over 4
workers to e
> However, searching for 'hurd-barebones.qcow2%' also skips the index.
That's because the index was not created in case insensitive mode.
I dropped support for searching with "^" and "$" characters as this is
not compatible with using an index and hence way too slow.
The new search behaviour i
Hello,
Search queries can take a long time to complete.
This query took 658.67 seconds to complete:
--8<---cut here---start->8---
SELECT * FROM ( SELECT Builds.rowid, Builds.timestamp, Builds.starttime,
Builds.stoptime, Builds.log, Builds.status, Builds.job
Hello,
> I'm trying locally to spawn database workers dedicated to registration,
> that execute the evaluation queries in a single batch. Let's see if it
> helps.
I added 4 registration dedicated database workers and removed from
registration all accesses to the store. Now the evaluation return
> Would be great :)
Done with b3f5402d2d506271857d2c987b79b741d4b0ec33.
Mathieu
Hey Ludo,
> ‘par-map’ is implemented in terms of futures, and futures use their own
> thread pool. What’s likely to block is ‘touch’: it essentially waits on
> a condition variable, which Fibers cannot interrupt.
I see, thanks for explaining.
> Why not just replace ‘par-map’ with ‘map’? That
Hello Jonathan,
>> You will then probably hit this one:
>>
>> https://issues.guix.gnu.org/43757
>
> I do :(
After fixing this issue, see: 761443bca6178b4ac299a8bd368d1cac4abda5f8,
I'm able to successfully evaluate and build your specification.
I still need to update the Cuirass package accordi
Hello,
> ERROR: In procedure make-stack:
> Attempt to suspend fiber within continuation barrier
Turns out "par-map" call does not seem suspendable, even though I'm not
sure why. Maybe Ludo can help here :) ?
This is fixed with: 761443bca6178b4ac299a8bd368d1cac4abda5f8.
Thanks,
Mathieu
>> https://issues.guix.gnu.org/43757
>
> I do :(
At least it's reproducible. Using one input works, but using more than
one input causes an exception during git fetching. It seems to be broken
since at least a few months.
It makes me think that we need a stronger test suite for Cuirass.
Thanks
Hello Jonathan,
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> Wrong type (expecting string): #f
Thanks for the bug report. This should be fixed with
d6a8f0a9781a90c3037f25e51d7ff32e50f7a8c1.
You will then probably hit this one:
https://issues.guix.gnu.org/43757
but we'll see th
Hello,
Running local tests, I have the following error:
--8<---cut here---start->8---
2020-10-02T11:54:09 fatal: uncaught exception 'misc-error' in 'build' fiber!
2020-10-02T11:54:09 exception arguments: (#f "Attempt to suspend fiber within
continuation barr
Hello,
> In the best case of one pending evaluation, the registration duration is
> reduced from 1800 seconds to 320 seconds. I think that the gain is way
> larger when there are multiple pending evaluations.
>
> Pushed a fix as 461e07e14e1c8013343c0a2cb26c0e022e10d5e4.
While this improves the
Hello,
> SELECT E.id, E.status, E.timestamp, E.checkouttime, E.evaltime, B.total,
> B.succeeded, B.failed, B.scheduled FROM (SELECT id, status, timestamp,
> checkouttime, evaltime FROM Evaluations WHERE (id='8255' )) E LEFT JOIN
> (SELECT rowid, evaluation, SUM(status=0) as succeeded, SUM(sta
Hello,
> When you feel like it, we can have a .2 release of Guile-lzlib with this
> fix.
Done with af56f60ef0394b35ab7926d10a4f825c2b1245f6.
Thanks,
Mathieu
For future reference, here's a small addition. As I said, we are using
the Cuirass SQLite database in WAL mode. This means that insertion
queries are added to a separate cuirass.db-wal file. Once in a while,
this file is supposed to be merged in the main cuirass.db file.
This mechanism known as
Hello,
> As each evaluation has to register around 50k builds, there might be
> some sort of "writing" contention on the database, explaining the long
> build registration time.
Turns out, once an evaluation is over, new builds are registered. This
registration tries to insert a new build for e
Hey Ludo,
> checking dependency style of i586-pc-gnu-gcc... none
> checking lzlib's file name...
Oh, I guess the same goes for guile-zlib and all cross-compilation
targets. I'll have a look later on.
Thanks,
Mathieu
--
https://othacehe.org
Hey zimoun,
Oh I see, thanks for explaining!
It would be nice if the `guix package -i` command could also operate
from left to right then. Would you like to give it a try?
Thanks,
Mathieu
--
https://othacehe.org
Hello zimoun,
> $ guix package -i busybox diffutils -p /tmp/foo
> $ ls -l /tmp/foo/bin
> [..]
> df -> /gnu/store/…-busybox-1.31.1/bin/df
> diff -> /gnu/store/…-diffutils-3.7/bin/diff
> diff3 -> /gnu/store/…-diffutils-3.7/bin/diff3
> dirname -> /gnu/store/…-busybox-1.31.1/bin/dirname
> [..]
Hello,
I just added SQL queries logging to Cuirass. I also adapted the Guix
shepherd service accordingly and deployed it on berlin.
The results are already interesting:
--8<---cut here---start->8---
SELECT E.id, E.status, E.timestamp, E.checkouttime, E.evalt
Hello,
Today between 04:04 and 10:36 no inputs were fetched. Fetching is
supposed to happen every 5 minutes. This seem to be correlated to the
duration of the garbage collection happening on berlin.
--8<---cut here---start->8---
2020-09-22T04:04:23 fetching i
Hello,
The attached screenshot shows that 9 evaluations are currently "In
progress" for "guix-master" specification.
Evaluations 16725 to 16738 are completed, 7 hours ago and 56 minutes ago
respectively. They are still shown as "In progress" because the
"register" phase in "build-packages" is no
Hello janneke,
> 8ce6f4dc2879919c12bc76a2f4b01200af97e019
> installer: Run the installation inside a container.
>
> ...but I don't find the commit message quite clear about its intention
> to *always* run guix-daemon in a container; it could be read as
> sugessting to do so only during i
Hey Ludo,
> As discussed on IRC, builds per day should be compared to new
> derivations per day. For example, if on a day there’s 100 new
> derivations and we only manage to build 10 of them, we have a problem.
I added this line, and they sadly do not overlap :(
> 2020-09-14T21:16:21 Failed t
Hello Andreas,
> Congratulations, that looks like a very useful start already!
> (And the number of builds has doubled since yesterday, so someone already
> put it to good use!)
Thanks for your feedback :)
> How about also adding metrics per build machine? I have the impression,
> for instance
Hello,
I just pushed support for computing and displaying metrics in Cuirass. I
started with two metrics:
* Builds per day
* Average evaluation speed per specification.
Those metrics can now be seen at:
https://ci.guix.gnu.org/metrics
and are updated every hour.
I plan to add more metrics s
Hello Danny,
> 1. &invoke-error:
> program: "parted"
> arguments: ("--script" "/dev/vda" "mklabel" "msdos" "mkpart" "primary"
> "e)
So it looks like the parted script failed inside the VM, while running
"initialize-partition-table".
This work fine both on the build farm and on m
Hey Chris,
>> It looks like a memory allocation failed causing a Cuirass/Guile crash.
>
> So, I've seen this before but in a slightly different context, [1]. To
> summarise, with Guile built with libgc@8 the Guix Data Service couldn't
> processes Guix revisions, because the code it had Guile bui
Hello,
I've observed a few Cuirass crashes the past days. The log looks like:
--8<---cut here---start->8---
2020-09-11T12:55:35 next evaluation in 300 seconds
GC Warning: Repeated allocation of very large block (appr. size 28766208):
May lead to memor
Hello,
> Is it deterministic? Same story with “gui-installed-os”?
>
> I guess we can add more ‘syslog’ statements in the installer around the
> place where we restart services. Or we could run the installer entirely
> under strace.
Now that the installation is done in a container, this one do
Hello,
> Agreed. We regularly push commits that are weeks or months old
> (sometimes years), so there might be too many outliers when looking at
> the commit time.
Yes, so I used checkout time instead of commit time with
af12a80599346968fb9f52edb33b48dd26852788.
I also turned Evaluation 'in_p
Hello,
> As discussed earlier today on IRC with Clément, we could add performance
> monitoring capabilities to Cuirass. Interesting metrics would be:
>
> • time of push to time of evaluation completion;
>
> • time of evaluation completion to time of build completion.
Small update on that o
Hey Ludo,
> This might be related to recent Guile-JSON API changes, as the
> ‘proc_args’ value for core-updates-core-updates above LGTM.
>
> This is with cuirass-0.0.1-42.d332955.
You are right, the lists of 'proc_args' were not converted to vectors,
making Guile-JSON unhappy. Fixed by
b135a02b
Hey Ludo!
> Could it be that there are two different libcs involved?
I can only spot one in environment-variables file.
> Do you know which acl is fixing (commencement.scm vs. acl.scm)?
Yes it's the acl that is rooted in the bootstrap toolchain. Here's the
full build log attached. I'm also cc-
Hello,
> As you can see, this is quite a bit more complex than it needs to be.
>
> So, why not have guix upgrade recognize the --do-not-upgrade option?
Thanks for the suggestion, it has been implemented by Jakub with
7ba7d50f92416821ec4fc124a49d74149b6d4d33.
Mathieu
Hello,
> I have this same issue on my Thinkpad, no Nouveau. I also had issues on
> my AMDGPU setup. If it's related to graphics, it doesn't seem driver
> specific.
>
> It seems that reconfigure only fails during the build phase, not when
> it's actually activating the new system, because running
Hello,
This is done with 4c0c65acfade63ce0549115d19db4b639c1e9992.
Thanks,
Mathieu
preloaded: ignored. != ~
--8<---cut here---end--->8---
Any idea, what's going on?
Thanks,
Mathieu
>From 59ff84c360e25ac754cc17f285d9bbf077a5e6c3 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe
Date: Fri, 28 Aug 2020 09:32:17 +0200
Subject: [P
Hey Ludo,
> We should be able to reproduce it with much simpler tests then, right?
> Like maybe “while : ; do herd restart guix-daemon ; done” or similar?
Well I tried that without success. Then I had a closer look to the
strace log.
Turns out there are two concurrent "finalizer" threads:
--8<
Hello Maxim,
> I think it only occurs once (the following 'guix system reconfigure' on
> the same machine do not seem to suffer from that error).
This has been covered here: https://issues.guix.gnu.org/42826.
Thanks for reporting,
Mathieu
Hello Pierre,
> Thanks for confirming!
I also noticed that Ludo did push
86c926d7f2dd4906d51dbcd7d39474116768a68d that should prevent this from
happening again.
Nothing much to add here, I think we can close this one.
Thanks,
Mathieu
Hello Pierre,
> building
> /gnu/store/wd1fj9n65xpdf22bzlswi6rk166miznh-install-bootloader.scm.drv...
> guix system: bootloader successfully installed on '/dev/sdb'
> The following derivation will be built:
>
> /gnu/store/4b7pizn41jq8aayqban639c7xddby29w-upgrade-shepherd-services.scm.drv
> b
Hey,
> This should fix bugs #42217, #38460, #34107.
> (needs rttr, patch 42767).
Nice job! Pushed as a2954e2a44602a5b5d50e11428f18023395fbf1c.
Thanks,
Mathieu
Hello,
> He also showed me how to make a shorter test-suite.log file via
> make check TESTS='tests/packages.scm', which is what I'm attaching.
>
> Still the whole test-suite.log file is super long, so here's the main
> gist that you ought to see:
Thanks for the report :)
This should be fixed w
Hello Ivan,
> How to reproduce:
> 1. Start XTerm.
> 2. Notice that the mouse cursor looks totally different from everything
> else. XTerm uses several mouse cursors: one for the text area, one for
> scrollbar, one for the menus, and they all stand out like a sore thumb.
> 3. Put libxcursor into
Hello Pierre,
> Now that there is a guile-lzlib package, I suggest we replace (guix
> lzlib) with it.
This is discussed here: https://issues.guix.gnu.org/42123#9.
> I haven't checked if it supersedes (guix lzlib).
Yes it should supersedes (guix zlib), but the transition is quite
tricky. Your
> I'll investigate this issue.
Fixed with 5697a524a75efae6144fcfaad730115910a34171.
Thanks,
Mathieu
Hello,
> I'm still waiting a few days before closing this issue.
No issues so far, closing this one.
Mathieu
Hello,
> After formatting the drive completely with another live USB the NVME was then
> correctly detected by the Guix installer.
>
> This issue occured both on the 1.1.0 stable installer ISO and the latest
> installer ISO as of August 1 2020.
Thanks for the report, I'm also able to reproduc
Hello,
> that suggests that we try to write something to a closed file.
>
> To be investigated :)
Ok, so I have a better grasp on what's going on. Cuirass web server is
receiving some requests such as "/builds/1234)" which were not rejected,
but worst, caused SQL queries such as "select * from
Closing this one as the installed-os test has been fixed.
Mathieu
Closing this one, thanks to both of you!
Mathieu
Hey,
> A second issue is caused when a build product download is started, then
> aborted. In that case, sendfile throws an exception or enters an endless
> loop.
Ok, so I found a couple of errors here. First, I noticed that it was not
possible to download simultaneously two build products, beca
> And does it mess Cuirass if the connection is lost e.g. down the
> network?
Not sure yet, I also found this message:
--8<---cut here---start->8---
Uncaught exception in fiber ##f:
In ice-9/boot-9.scm:
1736:10 5 (with-exception-handler _ _ #:unwind? _ # _
> The "jfs-root-os" test is failing since a few weeks. See:
> https://ci.guix.gnu.org/build/3038686/details.
>
> The issue is that some "link" syscall fails during "guix system init"
> call.
This is fixed by 8b221b64a552d31e241701aa5c6d339287a7a15b on master. The
problem was occuring inside "ded
Hello,
The "jfs-root-os" test is failing since a few weeks. See:
https://ci.guix.gnu.org/build/3038686/details.
The issue is that some "link" syscall fails during "guix system init"
call.
Mathieu
Hello Maxim,
> The following derivation will be built:
>/gnu/store/vs11h35gq7fi90bm0h4ygi7ak4ihkck8-lib2geom-1.0-1.42e119d.drv
> building
> /gnu/store/vs11h35gq7fi90bm0h4ygi7ak4ihkck8-lib2geom-1.0-1.42e119d.drv...
> while setting up the build environment: executing
> `/gnu/store/x3gq648qnf
Hey zimoun,
> What do you mean by “build product download is started, then aborted”?
Here I mean clicking on the downloadable image here[1] and then hit
"cancel" when the download popup appears, or the abort button later on,
when the download is started.
Thanks,
Mathieu
[1]: https://ci.guix.
Hey,
> It looks very much the same though: it’s stopping itself, which most
> likely happens as a result of killing itself. I’ve merged them, we’ll
> see!
This is probably fixed in Shepherd 0.8.1. Closing this one.
Thanks,
Mathieu
e and see if it solves the
problem.
Thanks,
Mathieu
> Hello, I didn’t add a little, if I don’t change ntfs, then I still get
> another error when starting formatting: /dev/sdb is still in use. I don’t
> quite understand what it so to solve the problem.
>
>
>
> От: Mathieu
Hello,
Back from holidays, perfect time to fix some Cuirass issues :) The
Cuirass web interface frequently serves 504 errors for all requests,
requiring a service restart on berlin.
Having a look to /var/log/cuirass-web.log it seems that we have indeed
multiple things going wrong.
A first prob
Hello Alexandrov,
> Hello, during the graphical installation of guix latest 9660, during the
> manual partitioning of the disk, for example, when I want to edit an existing
> ntfs partition, the error "unhandle ntfs type"
> appears, it is impossible to install the OS, on the stable version a c
Hey Tobias,
Thanks for the report.
>> {"error":"Could not find the request build product."}
>
> There are plenty[2] to choose from.
The issue here is that, due to a bug when handling restarted builds in
Cuirass, the ISO build product for build 3016488 was not created.
I fixed the issue in Cui
Hello,
> Many ARM Single Board Computers are commonly used with microSD for
> storage, and some microSD cards are extremely slow (and sometimes
> unreliable when they are old).
>
> Could the performance issues be related to storage device I/Os?
For those ARMv7 devices, which have few substitute
Hey,
> Something is going wrong here! I'll keep investigating.
To help us investigate those issues I added a "/status" page, which is
also accessible from a new drop-down menu in the Cuirass navigation bar.
See, https://ci.guix.gnu.org/status.
Hydra has the same interface, but also a "Machine
Hello,
> (That still doesn’t tell us why our ‘guix offload’ processes would
> occasionally be stuck but at least it ensures the build farm keeps
> making progress even when that happens.)
I'm still not sure it's directly related to this bug but I observed
several offloading hangs on Berlin toda
Hey!
> [ 5%] LOAD guix/glob.scm
> [ 6%] LOAD guix/workers.scm
> [ 7%] LOAD guix/zlib.scm
> [ 7%] LOAD guix/build-system.scm
> [ 8%] LOAD guix/build-system/android-ndk.scm
>
> I suspect that weird timestamp issue could well explain many things.
Oh good catch, I didn't no
> There are two test failures on berlin during guix-1.1.0-13.26611f5
> tests. Log attached!
Note that on my own machine, I cannot reproduce this issue.
Mathieu
Hello,
With Hydra, it is possible for a derivation to have the status of all
"still succeeding jobs", "newly failing jobs", "newly succeeding
jobs". In a word, have a quick overview of an evaluation status.
You can have a look to
https://hydra.nixos.org/jobset/nixos/release-19.09-small where it
Hey Ludo,
> utimensat(AT_FDCWD,
> "/gnu/store/whhc80cx1zpi9cj3bil3sp8wwzcf8p9p-image-root/gnu/store/n6l40ygclxfysnc2nxwrslnn5ab6wv3v-profile/lib/modules/5.4.47-gnu/kernel/net/netfilter",
> [{tv_sec=1592814617, tv_nsec=396083395} /*
> 2020-06-22T10:30:17.396083395+0200 */, {tv_sec=1, tv_nsec=0
> 183605:1 futex(0x7f17981e79d0, FUTEX_WAIT, 271, NULL
I think this is caused by a "pthread_join", most probably the one in
"stop_finalization_thread" that is called right before forking a new
process. The fact that we hang here probably means that the finalizer
thread itself is hanging, no
Hey,
>> There is now a final issue, where the command restarting "guix-daemon"
>> in "umount-cow-store" hangs forever. I can only reproduce it in
>> "gui-installed-desktop-os-encrypted" test. I wonder if it's a Shepherd
>> bug or anything else. I'll keep digging.
>
> If I can be of any help, we
Hello,
Some status here.
> * The cow-store issue here:
> https://lists.gnu.org/archive/html/guix-devel/2020-06/msg00043.html.
This should be fixed with 876a8d987085b8c64f32c8a320e4219575af285c.
>
> * A new issue I discovered, whereby 'guix system init' try to
> build/download stuff, when it sh
Hey Ludo,
> It’s nice, but also a bit complicated just to print stuff on the
> screen. :-)
You're right, I went too far :p
> That’s enough to send the ‘guix system init’ output to the console,
> since we use “console=ttyS0”.
>
> It’s a gross hack of course, but maybe we can do something along
Hey,
> Let’s just set the ‘locale-libcs’ field in (gnu tests) so that it
> contains a single libc. WDYT?
I'll see first if I can get the closure smaller by other means. I think
it would be preferable to keep the tested operating-system as close as
possible to the default one.
>> * "openssh" i
> Welcome. Yes, that’s fine.
I fixed indentation, added your copyright and pushed!
Thanks,
Mathieu
Thanks for rebasing :)
Your copyright is missing, is this ok for you if I use:
"Stefan "
or would you prefer something else?
Mathieu
Mathieu
>From 18754c8c62eabb341e0f710d83ff435ef950ca8e Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe
Date: Mon, 8 Jun 2020 15:14:49 +0200
Subject: [PATCH] installer: utils: Dump command output to syslog when testing.
When debugging the installation tests, it can be very handy to be able to read
"run-command&quo
Hey Stefan,
> * gnu/bootloaders/grub.scm (eye-candy): Use gfxterm depending only on
> (bootloader-configuration (terminal-outputs …)), which defaults to '(gfxterm).
> This makes the system argument obsolete.
This looks good, however due to recent changes in this file (multiboot
support), it doe
6776c8ce4ddf2 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe
Date: Mon, 8 Jun 2020 15:14:49 +0200
Subject: [PATCH] installer: utils: Dump command output to syslog when testing.
When debugging the installation tests, it can be very handy to be able to read
"run-command" output, for instan
Hey Ludo,
> How did you do it in the example above? Perhaps we can have a local
> hack specifically in the installer (otherwise we’d find ourselves
> duplicating syslog-related logic there.)
I used a custom re-implementation of "invoke/quiet" printing every line
on the syslog port. Maybe, we c
f effort,
because of all the code layers involved. I don't have much to propose to
improve it, maybe when the CI will be more robust, we will be able to
detect those test failures as soon as they happen.
Now, the cow-store issue!
Thanks,
Mathieu
>From 25950adfa4988c31beaeb334367337ee409868c
Hey Ludo,
> Fixed:
>
>
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=b49caaa2b7f624c3395c8e872638282bcc420502
Nice, thanks a lot for fixing this!
Mathieu
Hello Brice,
> For some time now the system test 'gui-installed-desktop-os-encrypted'
> doesn't succeed, the last time it passed was 2020-04-11[0]. This is
> problematic since it exercise a lot of packages and thus can be used to
> test those packages. Ludovic attempted to fixed it[1] but it did
> (define (activation-script gexps)
>"Return the system's activation script, which evaluates GEXPS."
> + (program-file "activate.scm" (if (hurd-target?)
> + (hurd-activation-script gexps)
> + (gnu/linux-activation-script ge
> ./pre-inst-env guix system vm-image --target=i586-pc-gnu --no-grafts \
> gnu/system/examples/bare-hurd.tmpl
Not related to your serie, but I would really like the "image" catalog I
proposed to help here. Most people struggle to get the difference
between --system and --target. Plus
> + (($ label device mount-point #f () #f kernel arguments
> modules)
> + (let* ((target (%current-target-system)))
This doesn't seem to be used anymore. Plus using %current-target-system
here could not give the expected result. I think that the only two
"safe" ways are to use (curr
> + (mach (if (%current-target-system)
> + ;; A cross-built GNUmach does not work
> + (with-parameters ((%current-system "i686-linux")
> + (%current-target-system #f))
> + mach)
Hey Jan,
> +Using GNU@tie{}mach in combination with a @code{hurd} is experimental
> +and only available when building a vm-image.}.
Maybe replace "vm-image" by "virtual machine disk image"?
> +
> +@cindex hurd
> +@item @code{hurd} (default: @code{#f})
> +The hurd to be started by the kernel. T
> All in all, fixing all of this makes the closure size to drop below 1GiB
> which is already a good first step.
>
> I'll try to provide patches soon.
I also discovered that enabling CONFIG_MODULE_COMPRESS, the size of
linux-libre is reduced by 63%.
This makes the image way lighter.
--8<--
Hey Marius,
> But when you install a system using that Guix, it will install an
> _older_ Guix snapshot, from its embedded
> gnu/packages/package-management.scm, which is the broken
> 1.1.0-3.52b01cb.
Oh you are right, I didn't realize that.
>
> Probably we should make a new Guix snapshot to w
401 - 500 of 681 matches
Mail list logo
