We must configure a valid hostname in the target before 10adduser, or sudo
fails with "unable to resolve host (none)" - before 18hostname is called
/root/etc/hostname is empty.
This was resulting in the "su as sudo" modifications not being applied in
the target which was causing X configuration applications to show different
behaviours when attempting elevating their priviledges.
Reordering the hostname configuration seems somewhat preferable to
applying a hack inside 10adduser to use 'su' or similar, as other
pre-XXhostname calls may incorporate calls to sudo in the future.