VM images on POWER require a PReP partition to be able to boot.
Since we don't have a way to define this archfully for now,
let's just always create it. Losing 4MB isn't that bad, anyway...
Signed-off-by: Neal Gompa <ngompa@fedoraproject.org>
This actually led to the filesystems being bigger.
The most recent Fedora Rawhide images were ~900MB instead of ~300MB.
Clearly, we need this to make it smaller.
This reverts commit d4d8bffb2c.
Signed-off-by: Neal Gompa <ngompa@fedoraproject.org>
Without this, there is no guarantee that BIOS would
be correctly set up if the install environment is UEFI.
Fixes: 611edda149
Signed-off-by: Neal Gompa <ngompa13@gmail.com>
Fedora Cloud is now set up so that it builds the disk with
GPT partitioning and has a specific partitioning layout so
that the resulting images are equipped to boot either with
legacy BIOS or UEFI.
Reference: https://fedoraproject.org/wiki/Changes/FedoraCloudHybridBoot
Signed-off-by: Neal Gompa <ngompa13@gmail.com>
This reworks the package list to add comments and remove some things
that didn't need to be explicitly removed.
- remove +systemd-udev -> already included by default
- remove -biosdevname -> not included by default
- remove -iprutils -> not included by default
- remove -uboot-tools -> not included by default
There are no packages added or removed from the built cloud image as
part of this change. Just updating the input package list to be more
meaningful.
We're no longer using legacy network scripts to bring up networking.
We're using NetworkManager and now in F33+ networkmanager will even
default to writing out new configuration as NM keyfiles in
/etc/NetworkManager/system-connections/. We don't need to lay down
a networking config for eth0. Either cloud-init will do that for us
or NetworkManager will default to DHCP anyway.
We also don't need to populate /etc/hosts as that will get done on
boot too with the same content we were writing there already.
This is done so that it's easy spot large packages that are not
necessary and identify packages that have grown in size too much
by diffing the image compose logs.
sed "s/rpm -qa/rpm -qa --qf '%{size}\\\\t%{name}-%{version}-%{release}.%{arch}\\\\n' |sort -rn/" -i *.ks
The "auth --useshadow --passalgo=sha512" is long default and auth option
itself has moved to authselect and is obsolete so this actually pulls
in extra dependencies. Drop it as the shadaow and sha512 are defaults.
Signed-off-by: Peter Robinson <pbrobinson@fedoraproject.org>
in turn makes a ifcfg-en<something> file with this config. We don't
want to use this, we want to always use ifcfg-eth0 so it's the same
on all images. So, we remove ifcfg-en* (They are different on each
arch we make cloud images for, but en* gets them all).
Additionally we were using some old udev tricks to get eth0, but this
is error prone and already incorrect as systemd-udev has moved files
around, so instead we just switch to net.ifnames=0 on the boot line,
which should continue working.
a59dfe5 caused us a few problems:
- sed was breaking the symlink on atomic systems
- /boot/grub2/grub.cfg is not the right file on a UEFI system
- etc..
We'll solve this problem a different way by just not installing
plymouth in our systems, which is another way [1] to make sure
rhgb/quiet don't appear on your kernel command line.
[1] ee91db6fa3/pyanaconda/payload/__init__.py (L722-L726)
We are seeing an error on aarch64 cloud image creation because
of the vfat filesystem and the fixfiles command failing:
+ /usr/sbin/fixfiles -R -a restore
/sbin/restorecon: Could not set context for /boot/efi/EFI/fedora/fonts/unicode.pf2: Operation not supported
/sbin/restorecon: Could not set context for /boot/efi/EFI/fedora/gcdaa64.efi: Operation not supported
/sbin/restorecon: Could not set context for /boot/efi/EFI/fedora/grub.cfg: Operation not supported
/sbin/restorecon: Could not set context for /boot/efi/EFI/fedora/grubaa64.efi: Operation not supported
/sbin/restorecon: Could not set context for /boot/efi/EFI/fedora/grubenv: Operation not supported
/sbin/restorecon: Could not set context for /boot/efi/EFI/BOOT/BOOTAA64.EFI: Operation not supported
/sbin/restorecon: Could not set context for /boot/efi/EFI/BOOT/fallback.efi: Operation not supported
/sbin/restorecon: Could not set context for /boot/efi/EFI/fedora/BOOT.CSV: Operation not supported
/sbin/restorecon: Could not set context for /boot/efi/EFI/fedora/MokManager.efi: Operation not supported
/sbin/restorecon: Could not set context for /boot/efi/EFI/fedora/shim-fedora.efi: Operation not supported
/sbin/restorecon: Could not set context for /boot/efi/EFI/fedora/shim.efi: Operation not supported
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
With moving to grub2 we now need to remove the extlinux bits from the
other cloud images. They were missed in the move
Signed-off-by: Peter Robinson <pbrobinson@fedoraproject.org>
We drop the explicit grub2 as aarch64 only has grub2-efi but anaconda will
sort that out and ensure all the right bits are installed during the install
so we should get the right grub2 bootloader options for each arch OOTB.
Signed-off-by: Peter Robinson <pbrobinson@fedoraproject.org>
The main reason for cloud to use extlinux is the size of deps being
pulled in by grub2-tools. This will be fixed in F-26 with the ability
to use grub2/grub2-efi without the tools package and it's deps fixing
this issue for good. There will no doubt need to be be some tweaking
required here.
We need grub2 in cloud images for non x86 as well as for the increasing
x86 cloud platforms that require the support of uEFI which extlinux
doesn't support.
Signed-off-by: Peter Robinson <pbrobinson@fedoraproject.org>
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>
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.
