Leo Famulari <[email protected]> skribis: > On Mon, Jul 17, 2017 at 04:02:14PM +0200, Ludovic Courtès wrote: >> The log shows that building the disk-image derivation starts with: >> >> --8<---------------cut here---------------start------------->8--- >> creating raw image of 102400.00 MiB... >> Formatting '/gnu/store/yv5r65584aaml86hc0xrgyffnp70ri36-disk-image', fmt=raw >> size=107374182400 >> --8<---------------cut here---------------end--------------->8--- >> >> That’s a lot, no? > > Yes, I specified it manually while debugging. > >> Regardless, memory consumption in the VM is not supposed to be >> proportional to the size of the image being created. > > Indeed, the problem exists also when I don't pick a size manually. > >> The allocation failure happens while copying files: > > [...] > >> Does that work on previous master with Linux-libre 4.12.0 (current >> master is at 4.12.2)? (This would allow us to determine if this is an >> ext4 bug, who knows…) > > Yes, I tested with a variety of kernels and on the master branch as > well. > >> If it does, then the only other issue I can think of is if Guile itself, >> while running ‘copy-recursively’ from (guix build utils), eats memory >> proportional to the number of files, leading to an OOM condition. >> However the kernel message don’t report it as an OOM, AFAICS. > > I'm wondering if it's related to the Guile 2.0 / 2.2 mismatch in the > initrd, discussed previously: > > https://lists.gnu.org/archive/html/guix-devel/2017-07/msg00220.html > > Guile 2.0 would need to rebuild all the 2.2 modules it finds.
This works for me now: --8<---------------cut here---------------start------------->8--- $ ./pre-inst-env guix system disk-image gnu/system/install.scm *** output flushed *** $ file /gnu/store/37ppm08ggdds3i06h4la0wdzilcnladm-disk-image /gnu/store/37ppm08ggdds3i06h4la0wdzilcnladm-disk-image: DOS/MBR boot sector $ git describe v0.13.0-1474-gef03d8dc3 --8<---------------cut here---------------end--------------->8--- Could you check if it works for you? It’s a much smaller image than what you tried (1G vs. 102G). Ludo’.
