I am trying to Deploy CentOS 8, and I was able to get the templates working to some degree, however when Anaconda goes to actually do the install, I get the error:
Platform has images but is not referenced in platform list: xen, {‘x86_64’}
Looking at my repo, it created a treeinfo file containing
<snip>
[general]
; WARNING.0 = This section provides compatibility with pre-productmd treeinfos.
; WARNING.1 = Read productmd documentation for details about new format.
arch = x86_64
family = CentOS Linux
name = CentOS Linux 8
packagedir = Packages
platforms = x86_64
repository = .
timestamp = 1566316643
variant = BaseOS
variants = BaseOS
version = 8
[header]
type = productmd.treeinfo
version = 1.2
[images-x86_64]
boot.iso = images/boot.iso
efiboot.img = images/efiboot.img
initrd = images/pxeboot/initrd.img
kernel = images/pxeboot/vmlinuz
[images-xen]
initrd = images/pxeboot/initrd.img
kernel = images/pxeboot/vmlinuz
[release]
name = CentOS Linux
short = CentOS
version = 8
[tree]
arch = x86_64
build_timestamp = 1566316643
platforms = x86_64
variants = BaseOS,AppStream
<snip>
Taking a look at the source sode, I see that in treeinfo.py_validate_platforms is throwing the error. There is also a deserialization happening and I suspect a fixup in there for the images- sections may be causing this. That’s the only way I could see _validate platforms trying to check xen against a list - if it had been added during the deserialization.
How can I remove support for xen images? Is this something done in the upstream repo? Or can I override this in pulp? Or is this an anaconda/productmd bug?
I can provide the machine templates I am using if that is helpful.
While using the /kickstart/ folder works, it sounds like it is not a good long term solution. I’ve been playing around with Apache rewrites to work around the issue, but the next thing anaconda does is tries to go to pulp/repos/ORG/ENV/CONTENTVIEW/AppStream/x86_64/os/repodata/repomd.xml
Does anyone know where this path/URL might be coming from? It’s not a redirect and it tries to pull that path immediately after grabbing the appstream repo.
I do have url and repo directives set properly in my kickstart file, but it seems like anaconda is ignoring this and getting the repo paths from somewhere else or constructing it with its’ own logic.
Yep - I have them both pulled down to my foreman instance and I’ve fed them both to anaconda via kickcstart (repo is the AppStream repo and url is the BaseOS). It appears that Anaconda is looking for BaseOS packages in some sort of mangled path that it pulled and constructed from… somewhere. So my question is where is Anaconda getting that URL. If it’s constructing it based off of bum data, I’ll need to file a bug report.
As noted in this bug notes, the CentOS 8 BaseOS repository references AppStream repo in a way which is incompatible with Foreman. Specifically, it uses a relative path that goes above the product name. A packet captures shows that dnf is actually resolving that path before* it goes to pull the repo, so even if you add a 302 redirect to catch /…/…/…/, this will not work properly.
We installed the CentOS 8 ISO as a stopgap measure and were able to create systems. There are still too many other problems for production. Maybe all will be resolved by the time Foreman/Katello is fixed. For now, we’ll stick with 7.
This issue can be fixed by syncing the AppStream repo, which Katello will detect and send over to Anaconda. I’m updating the Katello provisioning documentation, but I’ve put the instructions in the bug here too.
Yeah - we saw - but that doesn’t include the updates since the release of CentOS 8.0 and isn’t guaranteed to be stable. It’s far better to use the template in note #9 here.
if you setup a correct installation media // os + pxe + provision template in foreman its working out of the box (now also with /os instead of /kickstart)
just to note that the problems you are seeing are coming from using katello instead of plain yum // dnf / deb mirrors, simply katello is still not compatible out of the box with centos 8.
