After roughly two solid days compiling I terminate with an error:
cd /tmp/root && tar cf - * | xz -8 -T0 --memory=648MiB > /tmp/cdrom/distro.img
xz: Memory usage limit is too low for the given filter setup.
xz: 658 MiB of memory is required. The limit is 648 MiB.
I’m searching for the offending configuration file now but I suspect that there may be modifications needed to the scripts if this value is hard coded (or it’s a typo). I’m desperately hoping that I can get it to resume rather than having to restart all over again (!).
Is anyone aware of this issue on the 3b+? My objective is to install it on top of Raspberry Pi OS as I need additional functionality (this is a Frankenbuild but it won’t be publicly facing in use).
This looks pretty much like your machine is running out of memory and xz is unable to limit it’s proceedings to 648 MiB. I do not think this can be fixed in an easy way, please consider changing your hardware.
Hi,
Is anyone aware of this issue on the 3b+? My objective is to install it on top of Raspberry Pi OS as I need additional functionality (this is a Frankenbuild but it won’t be publicly facing in use).
Thanks Peter, I did a parallel compilation on a Pi 4b with 4gig of ram and that worked (takes just over 2 days to get to that point). I’m booting that created image on the 3b+ and it’s stuck at a flashing cursor below the four flamed penguins, not sure where to take it from there…
My ultimate objective is to build a hybrid build of this so that I can install additional applications (not GUI ones, just some low level things to run at the command line like LFTP, etc.) - is there another way that I could achieve this without a ground-up rebuild that you could suggest? Smoothwall ships a “developer’s build” which I think permits compilation of programs, etc. - the use of the final-outcome system has to be on low powered hardware as it’s running off a solar array, it’s running inside a home network (so not internet facing but is routing internet traffic).
Any suggestions would be greatly appreciated, IPFire seems to match the solution requirements about 75-80%.
This is normal if you not disable the serial console in eENV.txt which is default enabled because the most supported arm boards not have working video output.
Why this takes so long? Should the RPi4 not a bit faster than the RPi3? I have not build it on my hardware long time. The professional servers at amazon are much faster than such boards…
2 hours (with ccache) - https://nightly.ipfire.org/core145/latest/armv5tel/build.log
To be honest I’m really not sure - the Pi3b+ took over 2 days (slightly faster with a fan on the heat sink so it might have throttled a tiny bit) but I’m not yet familiar enough with this type of process to really know; I monitored disk space, CPU utilisation and memory free and found CPU was rarely at capacity on either machine so I think build was being slowed by I/O. I moved the 2nd compile attempt to an external HDD on USB2 to speed up the 2nd attempt on the Pi3b+ which made quite a difference but ultimately I’m not sure if I’m going about this properly (to achieve the ability to install 3rd party apps such as LFTP on the standard build).
I might be taking the wrong approach, is there a better way to achieve this that anyone can recommend? I appreciate this is a little off-label of course, the intended use is different in the end.
I see that there has been work on making a docker image on x86 platforms - I was wondering if there’s a way I could convert the existing image creation process to the creation of a docker file perhaps; while the target Pi4b 4gb model has enough room for a virtualisation environment I don’t see an awful lot available sadly.
Is that a plausible option perhaps?