anaconda apparently fails now if the scriptlet fails which happens
on 32 bit arm:
Error
There was an error running the kickstart script at line 28. This is a fatal
error and installation will be aborted. The details of this error are:
+ LANG=en_US
+ echo '%_install_langs en_US'
+ echo 'Import RPM GPG key'
Import RPM GPG key
++ rpm -q --qf '%{version}\n' fedora-release
+ releasever=27
++ uname -i
+ basearch=armv7l
+ rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-27-armv7l
error: /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-27-armv7l: import read failed(2).
Press ENTER to exit: systemd-localed.service: Got notification message from PID 2286 (STOPPING=1)
as all the rpms in f26 for arches that will have containers ase
signed with the one key lets just import that
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
cmdline makes it so that %post --erroronfail won't actually stop the
installation in a way that imagefactory will detect the problem and
fail the build. See [1] for more details.
[1] https://github.com/rhinstaller/anaconda/issues/931
So is seems that if you remove the machine-id file it won't regenerate the file
but if you touch the file and leave it empty on boot it'll put a new machine-id
in the empty file. So work around this bug ("feature"?) by touching the file
so we don't have other issues in the process.
We're track the outcome of this in RHBZ 1379800
As referenced on the arm list [1] and as already being done on the docker image we
should remove the unique /etc/machine-id file on compose artifacts to ensure it's
regenerated and unique on each deployed host/device. This unifies the process across
all base ks so it's inherited for each artifact.
[1] https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org/message/Q3YZVF5P2OLLPUJQ2LYZSTKWGGDIU6QO/
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
We were getting grub2 in the base image again. Apparently
for a while Anaconda has supported a cleaner syntax for this, and
since it fixes the bug, let's use it.
https://bugzilla.redhat.com/show_bug.cgi?id=1222132
Best practice is to use unprivileged service daemons inside Docker
containers. But with this hardcoded root password, in the case of
remote code execution, an attacker could trivially escalate their
privileges to root/uid 0. And while that's uid 0 inside a container,
that's a much larger attack surface.
Instead, do the same thing we're doing for the Cloud images: lock the
root password, create a user to make Anaconda happy, then delete the
user in %post.
https://bugzilla.redhat.com/show_bug.cgi?id=1175997
Even though it's silly, the ImageFactory-in-Koji use case calls into
libguestfs to introspect the target system, and libguestfs relies on
/etc/fstab to detect installed operating systems.
