Bug 1369930

It seems like, at present, when we build Cloud images, if there is an error during post-install setup, the thread in which it's running crashes, but the main anaconda process does not. The main anaconda process seems to complete 'successfully', so the image compose process continues. This could hide major problems - in fact, it already has.

Here's an example log:

https://kojipkgs.fedoraproject.org//work/tasks/5670/15365670/oz-x86_64.log

Note that the kickstart:

https://kojipkgs.fedoraproject.org//work/tasks/5670/15365670/koji-f25-build-15365670-base.ks

has "%post --erroronfail". In the oz log, we can see that there is an error in that section:

18:10:15,462 INFO program: error reading information on service rsyslog: No such file or directory
18:10:15,463 DEBUG program: Return code: 1
18:10:15,463 ERR anaconda: Error code 1 running the kickstart script at line 37
18:10:16,173 ERR anaconda: There was an error running the kickstart script at line 37.  This is a fatal error and installation will be aborted.  The details of this error are: <snip>

then it posts a bunch of info ending in a traceback. But it seems like control reverts to the main thread, and the main thread doesn't actually crash (this isn't *entirely* clear, but the fact that program.log logs a call to systemctl reboot suggests it carried on with the kickstart's instruction to reboot the system on completion, instead of just dying):

18:10:17,176 DEBUG anaconda: Gtk cannot be initialized
18:10:17,177 DEBUG anaconda: In the main thread, running exception handler
Waiting for factory-build-fff41a09-fc9e-4909-9706-f38178d3aad1 to finish installing, 6860/7200
18:10:27,207 DEBUG packaging: getting release version from tree at None (25)
18:10:27,207 DEBUG packaging: using default release version of 25
18:10:27,209 INFO program: Running... systemctl --no-wall reboot
18:10:27,357 DEBUG program: Return code: 0

subsequent messages show imagefactory deciding the install has completed successfully and going on to produce the final image file.

The same behaviour is observed if the kickstart `services` line tries to enable a non-existent service. This causes the anaconda thread handling post-install setup to crash, and all subsequent actions it would have taken (including the whole of %post) just do not happen, but the main thread seems to go ahead and reboot the system, and imagefactory goes ahead and produces an image.

This is why we were getting 'successful' composes but entirely broken images for Cloud lately.

I think it would be better if, somehow or other, the image compose failed in these cases.