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.
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.
Due to #1369794 , anaconda cannot currently manipulate sysv
services in F25+. So to work around this, take 'network' out of
the services lines in all kickstarts and instead manipulate
it in the %post section, with chkconfig.
Also remove rsyslog from the Atomic image services line because
it doesn't appear to be included in the OStree tree at present
and so attempting to enable the service breaks Atomic image
compose, see e.g.:
https://kojipkgs.fedoraproject.org//work/tasks/9022/15349022/oz-x86_64.log
also correct the name of the ssh service in fedora-arm-base.ks;
it's sshd not ssh.
With e2fsprogs after 1.43 the 64bit and metadata_csum features are
enabled by default. These features are not currently supported in
u-boot and the 64bit feature introduces changes such that it cannot
be read by implementations that do not support it. U-Boot does not
support the functionality and hence now won't mount it just in case
it corrupts the filesystem, which is a reasonable response, this how
ever stops us from booting when we have a ext4 /boot file system
which means basically we end up with a pot plant. Go back to using
ext3 for the time being as the mkfs.ext3 option doesn't enable these
features and we get booting systems!! YAY \o/
