FAI for ARM image building

[Riku Voipio]

On 10 October 2017 at 14:48, Thomas Lange <lange at informatik.uni-koeln.de> wrote:
>>>>>> On Tue, 10 Oct 2017 10:09:24 +0300, Riku Voipio <riku.voipio at linaro.org> said:
>
>     > I've been exploring fai-diskimage for building fastbootable
>     > filesystems and disk images for 96boards form factor devices.
> Hi Riku,
>
> great to see that you looked at fai-diskimage.
> I never heared the term "fastbootable". Is this something special?

fastboot is the protocol used on android and android-derived
bootloaders to flash an eMMC device. A fastbootable image is rootfs
converted to "fastboot sparse" image format, with img2simg or ext2simg
tools (android-tools-fsutils in debian).

>     > outdated. FAI appears a good fit so far. Our current configs are at:
> I've already clone this repo and will have a closer look at it later.
>
>     > we can now make images but there are some bumps.
>     > - fai-diskimage doesn't error out on failures. In our case, it is
>     > imperative that the image build fails if packages are missing or
>     > scripts fail.
> I guess this is #866331 "fai-server: fai-diskimage exits with 0 even when a script does not"
> which is fixed in FAI 5.4. In FAI we have internal error codes which
> are stored in the variable $task_error. There's also the variable
> $STOP_ON_ERROR which is default to 700. That means if $task_error is
> below $STOP_ON_ERROR the fai process will not stop. But the new
> version will exit with 1 if some error occurs.

Is there a error code when there is unknown packages in package_lists?

>     > - No apparent access from scripts or hooks to the output file
>     > location. This would be useful for extracting artifacts (kernel etc)
>     > from the disk image to the same directory where disk image is going.
> In FAI 5.4 we use this in scripts/LAST/50-misc:
>
> # for ARM architecture, we may need the kernel and initrd to boot or flash the device
> if ifclass ARM64; then
>     cp -pv $target/boot/vmlinuz* $target/boot/initrd* $LOGDIR
> fi
>
> Then you have the kernel and initrd inside the log directory. I hope
> this helps. Or do you need a better way to acces it?

Pretty much how we ended up doing it.

>     > - lack of tasks to hook into after the filesystems have been
>     > unmounted. faiend task seems to run before it. The key use here is to
>     > run img2simg or ext2simg to convert the rootfs image into fastbootable
>     > android sparse image. We can make a wrapper script for it of course.
> I'm not sure if you like to do this inside fai (the config space), or inside
> fai-diskimage. But you can also execute a hook after a task. From the FAI
> FAQ inside the wiki (which is down atm.)
>
> Can I write a hook that is executed after a certain task?
> (freely) quoting #fai:
> <sanso> is there a way to define post-hooks other than defining a (pre-)hook for the following task?
> <Mrfai> sanso: yes post hooks are possible. Define a pre hook, and inside this hook, you
> first call the default task using task_taskname, then add your code for the post hook.
> And don't forget to call skiptask.
>
>
> So write a hook/faiend.CLASSNAME:
>
> #! /bin/bash
>
> task_faiend
> skiptask faiend
> <you code here>

Good to know, but I now realize why this didn't work. the hooks apply
to fai, while the disk image is managed by fai-diskimage. So i guess
the best way to manage conversion to fastboot sparse image is to send
a patch for fai-diskimage.

>     > - The rather manual steps of copying files/. Having to DYI template
>     > expansion and explicitly fcopy every single file is really annoying.
>     > Right now users are tempted to just use herefile from the scripts
>     > directly.
> Holger already mentioned fcopy -r and a template system is on the
> roadmap since a long time and also reported as #874188
> "fai-client: Integrate some form of file templating system"
> I would be happy if you could join the discussion which type of
> functionality is needed.

ok.

>     > We haven't used the new cross-arch support in FAI 5.4 yet. I think it
>     > has potential to be really useful for our endusers
> That was my intention and I hope to get my own Hikey960 installed via
> FAI soon ;-)

even better, the next generation of rootfs for hikey960 should be
built with FAI :)

Riku