The new DNF based appliance build is stricter about additions and exclusions
in the %packages section, so things that expressly conflict will fail the
build.
The DNF-based appliance-tools build of the ARM image complains
that it is short by 54MB, so we're increasing by a bit more than that
to give some wiggle room for the future.
I'm trying to keep things in sync - this mostly ensures the root
password is unlocked, and drops the `services` line that is useless
because that's not how kickstart inheritance works.
for rhbz#1392468 I was told that what we had should never have worked.
A bug in anaconda was fixed causing the need for the user or root
spokes to have to be dealt with. locking the root account should
satisfy everything.
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
This prevents systemd to update it during boot if DHCP supplies a
hostname, which causes sddm to not start. See
https://bugzilla.redhat.com/show_bug.cgi?id=1370222
Signed-off-by: Kamil Páral <kparal@redhat.com>
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
images without any change to the process (except they have a small 30Mb
partition at the begining of the image) but all exisiting documented
processe work for image writing. The RPi is auto configured and a pure
dd to the card, plug and boot.
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>
it's no longer pulled in by cloud-init (since 2014...). None
of these kickstarts has it in %packages, and it's not in any
of the cloud environment or package groups in comps either. So
it seems like no-one particularly wants rsyslog in the cloud
images.
From compose logs, it looks like trying to enable a non-existent
service in anaconda in Fedora 24 and earlier wasn't a fatal
error (anaconda more or less logged a warning and continued),
but in Fedora 25 and later it does seem to be fatal. It at least
causes one anaconda thread to crash, though the image compose
completes. I think possibly at least the way anaconda's run
in the Cloud compose process, the main thread manages to exit,
but it seems pretty likely the thread crash will result in
problems in the produced image.
Needed on master and f25.
