One thing that would be interesting would be auto load to ram, just guessing here but hook could test available ram on system and run from there. On Sunday, 4 October 2015, <arch-releng-request@archlinux.org> wrote:

Send arch-releng mailing list submissions to arch-releng@archlinux.org <javascript:;>

To subscribe or unsubscribe via the World Wide Web, visit https://lists.archlinux.org/listinfo/arch-releng or, via email, send a message with subject or body 'help' to arch-releng-request@archlinux.org <javascript:;>

You can reach the person managing the list at arch-releng-owner@archlinux.org <javascript:;>

When replying, please edit your Subject line so it is more specific than "Re: Contents of arch-releng digest..."

Today's Topics:

1. Re: reduce image size (Gerardo Exequiel Pozzi)

----------------------------------------------------------------------

Message: 1 Date: Sat, 3 Oct 2015 17:25:29 -0300 From: Gerardo Exequiel Pozzi <vmlinuz386@gmail.com <javascript:;>> To: Arch Linux Release Engineering <arch-releng@archlinux.org <javascript:;>> Subject: Re: [arch-releng] reduce image size Message-ID: <561039B9.7050106@gmail.com <javascript:;>> Content-Type: text/plain; charset="windows-1252"

On 10/02/2015 08:10 PM, Gerardo Exequiel Pozzi wrote:

...

...

Some general thoughts... In make_prepare() we do a 'cp -a ...' - does that make sense? We can

skip

...

that step when bootstrapping to the correct directory, no? Moreover, sometimes we call 'mkarchiso -w "${work_dir}" ...' and add the subdirectories later in function, sometimes we call 'mkarchiso -w "${work_dir}/${arch}" ...' or similar. Is there a reason for that? To make that path handling unique should simplify implementing my feature. This would break existing configs, though.

"cp .. -l ..." all hardlinks, if my memory does not fail....this is done to make, the build process of dual iso much more easy, I do not remember exactly why in this way. The idea was, build each $arch at time, then merge in last step, also easy to "re-exec build.sh" at intermediate points.

correction: The point is, if you want to re-execute make_prepare(), (deleting the lock file made by run_once()), do it on the same "state" of untouched workdir, since _cleanup removes files and maybe you want to re-exec pacman, was good for testing purposes... can be removed, indeed # rm ... /airootfs can be uncommented....

I am currently working on this idea of single sfs ;)