Anaconda is writing an /etc/resolv.conf from the install environment.
The system should start out with an empty file, otherwise cloud-init
will try to use this information and may error:
https://bugs.launchpad.net/cloud-init/+bug/1670052
(cherry picked from commit fc0a635bc4)
1. Make sure that the ref we sit on exists. This will also work around
a subtle issue which would cause static deltas to not be used (though
https://github.com/ostreedev/ostree/pull/710 will fix that).
2. Make sure we delete the old refs so that the commit eventually gets
cleaned up.
We need to use the kojipkgs url on the builders because they don't
have access to dl.fp.o. After some discussion we have just decided
to use the kojipkgs url everywhere as the dl.fp.o url is just a
redirect anyway.
We want to build images from ostree ref that gets updated "nightly"
but we want consumers of the image to track the two week releases.
This is part of work for ticket: https://pagure.io/releng/issue/6545
The issue has been fixed upstream with improvements to ext4 support in u-boot 2016.11,
in Fedora I backported these fixes to uboot-tools-2016.09.01-2.fc25 and they've now
been verified and that release is now stable so we should be good to revert the ext3
partition workaround for F-25 GA.
The old means of enabling the graphical service is obsolete so remove it.
It's now detected by explicitly enabling graphical.target so do this by default
for all graphical UXes
* removes the extra ens3 ifcfg that seems to be added
by dracut at some point (cloud base did this in their
ks a year ago in c509863)
* adds net.ifnames=0 to the bootloader line, because
that seems to be necessary to actually disable consistent
device naming
* enables the network service
see https://pagure.io/atomic-wg/issue/174
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>
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/
