Things are going to be very close with removing just neverball. So it
looks like we need another removal and it is stellarium.
This is for bug 1168983.
Pungi and lorax pull in the complete repository set and then try
to load all possible fedora-productimg-* packages. We need to
explicitly exclude the ones for the different products.
We were doing gyrations here between the "installmedia" remote and the
intended "fedora-atomic" remote. Thinking about this, it's *far*
simpler if we pretend installmedia is the target remote.
We still need to delete the remote configuration Anaconda added and
re-add it with the real target URL.
The system loops with:
mkdir: cannot create directory '/oldsys': Read-only filesystem
mkdir: cannot create directory '/oldsys/sys': Read-only filesystem
mount: mount point /oldsys/sys does not exist
...
drauct Warning: Killing all remaining processes
...
--- begin loop ---
Unable to unlink device node for atomicos-root
Unable to unlink device node for live-base
rm: cannot remove /lib/drauct/hooks/shutdown/30-dm-shutdown.sh: Read-only filesystem
rm: cannot remove /lib/drauct/hooks/shutdown/30-md-shutdown.sh: Read-only filesystem
--- end loop ---
Not entirely sure what's at fault here, but this is a quick hack to
get an image building.
mattdm changed these previously because we hit an ENOSPC error during
qcow2 image creation, but that *really* happened because the Fedora
rel-eng create-cloud-images script hardcoded 3GB.
Now that we've shrunk the content down to ~850MB, drop the defaults:
- rootfs down to 2GB. This is enough space for a replacement of
all content, plus a bit of spare room for logging
- /boot to 200MB. At present, kernel+initramfs is just 30MB,
so this is still very conservative.
Basically Anaconda-in-ImageFactory is set up to pull from the
builder, so that's what ends up in the origin file. But that's
obviously not what we want to ship to users.
ostree/rpm-ostree do not yet have a convenient command to change this,
so brute force it with sed.
Implements https://lists.fedoraproject.org/pipermail/cloud/2014-November/004570.html
While it makes sense to import the GPG key, it has to be done
as part of the treecompose, because it'll drop out of the rpmdb
on the next upgrade.
For yum, it was run as part of the treecompose, not Anaconda, so
there's already no history.
