Can't Kickstart CentOS 8

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.

@Justin_Sherrill

This looks like a releng bug in CentOS 8, file report for them and link it here please. This is treeinfo from RHEL 8.0 (gold version):

[checksums]
images/boot.iso = sha256:f6be6ec48a4a610e25d591dcf98e1777c4274ed58c583fa64d0aea5b3ecffb18
images/efiboot.img = sha256:94d5500c4ba266ce77b06aa955d9041eea22129737badc6af56c283dcaec1c29
images/install.img = sha256:46171146377610cfa0deae157bbcc4ea146b3995c9b0c58d9f261ce404468abe
images/pxeboot/initrd.img = sha256:e0cd3966097c175d3aaf406a7f8c094374c69504c7be8f08d8084ab9a8812796
images/pxeboot/vmlinuz = sha256:370db9a3943d4f46dc079dbaeb7e0cc3910dca069f7eede66d3d7d0d5177f684

[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 = Red Hat Enterprise Linux
name = Red Hat Enterprise Linux 8.0.0
packagedir = Packages
platforms = x86_64,xen
repository = .
timestamp = 1554367044
variant = BaseOS
variants = BaseOS
version = 8.0.0

[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 = Red Hat Enterprise Linux
short = RHEL
version = 8.0.0

[stage2]
mainimage = images/install.img

[tree]
arch = x86_64
build_timestamp = 1554367044
platforms = x86_64,xen
variants = BaseOS

[variant-BaseOS]
id = BaseOS
name = BaseOS
packages = Packages
repository = .
type = variant
uid = BaseOS

I see a difference here:

platforms = x86_64,xen

Probably some switch or something when metadata was generated. Dunno.

Thanks Lukas,

Bug filed here

i was able to install centos 8 successfully fully automated from foreman on vmware via this as installation mirror with kickstart and pxeboot

http://mirror.centos.org/centos/8/BaseOS/x86_64/kickstart/

1 Like

https://lists.centos.org/pipermail/centos-devel/2019-September/017796.html states that this kickstart is only the GA content where /os gets updates.

http://mirror.centos.org/centos/8/BaseOS/x86_64/os failed with some wierd iscsi dracut init fails
http://mirror.centos.org/centos/8/BaseOS/x86_64/kickstart worked out of the box

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.

If CentOS is like RHEL, there are two repos needed for kickstarting… BaseOS and Appstream.

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.

It’s probably better to ask Anaconda folks. I have no idea.

I eventually figured this out…

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.

Looks bad, we need someone from @katello team to take a look and analyze what we can do with this.

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.

2 Likes

just to note, now i’m able to kickstart with http://mirror.centos.org/centos/8/BaseOS/x86_64/os out of the box

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.

as said http://mirror.centos.org/centos/8/BaseOS/x86_64/os gets updates, thats why its now working out of the box and was not working when i posted where i used http://mirror.centos.org/centos/8/BaseOS/x86_64/kickstart ^^

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.