Hi List, I noticed that when live-build runs mksquashfs to create the squashfs file for a foreign architecture, it does so by calling the mksquashfs inside the chroot - which means it gets executed by qemu, rather than using the host-native mksquashfs and in addition to that, this means it has access to only one CPU core.
I have worked around this with a hack. Whenever I'm building for a foreign architecture, I am basically checking when ./chroot/usr/bin/mksquashfs starts to exist. As soon as it does, I move it to ./chroot/usr/bin/mksquashfs.real and replace it with a shell script. This shell script echoes $0 and $@ into a semaphore file /tmp/filesystem.squashfs.temp (inside the chroot), then checks for the existence of said file, and as long as that file exists, simply loops with a 1 second interval. Once this semaphore file is gone, the script deletes itself, and moves the real executable back into its place. Now, on the host, I start a background task that checks if $CHROOTDIR/tmp/filesystem.squashfs.temp exists. While it doesn't - you've guessed it - it loops with a 1 second interval. It then parses the contents of the file to call the mksquashfs on the host, in its native architecture, with the corresponding parameters. Once the mksquashfs job completes, it deletes the semaphore file. As mksquashfs is now running natively, and able to make use of all cores, the job completes significantly faster. I wonder if this functionality could be built into live-build directly, somehow, so it becomes less hackish? Kind Regards, Stefan Baur
