Fedora 34 kickstart fails to make it to installer (semi-resolved)

Support
,
1

Most of this is an “ah ha! I think I figured it out and want to share. Maybe it can help someone else.”

Problem:

Fedora 34 iPXE provisioning does not make it to Anaconda to start the install when using default templates

Expected outcome:

“Kickstart default iPXE” template should bring the system to a functioning install process.

Foreman and Proxy versions:

new install of

  • Foreman 2.4.0
  • katello 4.0.0

Distribution and version:

  • RHEL 7.9

Other relevant data:

rdsoreport.txt lines 984-988

[    4.532391] fedora dracut-cmdline[266]: Loading Fedora 34 x86_64 installer...
[    4.547417] fedora dracut-cmdline[266]: Warning: 'ks' is deprecated and has been removed.
[    4.547417] fedora dracut-cmdline[266]: Warning: All usage of Anaconda boot arguments without 'inst.' prefix was removed. Please use inst.ks instead.
[    4.549058] fedora dracut-cmdline[266]: Warning: 'kssendmac' is deprecated and has been removed.
[    4.549327] fedora dracut-cmdline[266]: Warning: All usage of Anaconda boot arguments without 'inst.' prefix was removed. Please use inst.ks.sendmac instead.

Some narative:

So I am trying to whip together a Fedora 34 desktop with RedHat Satellite 6.8.2 and bumped into Fedora not making it into Anaconda. The PXE boot would make it to “Reached target Basic System”, scroll some dracut-initqueue errors, and then ultimately timeout to the Dracut Emergency Shell. To try to report the problem here, and to see if the problem was already fixed on the cutting edge, I setup a new Katello 4.0 server. I was able to replicate the issue, and dug in a bit. Found in the rdsosreport.txt that dracut-cmdline logged some deprecated kickstart syntax that is no longer handled.

Searching a bit, I found some bug discussion in the Beaker project that indicated that some kickstart variables were deprecated and would be removed in Fedora 34 & RHEL 9.

So with that, I checked the rendered iPXE boot and saw the kickstart file being referenced by ‘ks’

kernel http://dl.fedoraproject.org/pub/fedora/linux/releases/34/Server/x86_64/os//images/pxeboot/vmlinuz initrd=initrd.img ks=http://katello.fqdn/unattended/provision?token=537251a7-4aff-49c4-80c9-a62672caa112  BOOTIF=AA-BB-CC-DD-EE-FF-AA kssendmac ks.sendmac inst.ks.sendmac

The Resolution?

I cloned the “Kickstart default iPXE” template and modified line 30 from ks=<%= ks %> to inst.ks=<%= ks %> and then set this as the template pxe template for the test box to use.

And it worked. The system made it into Anaconda where I can now slog through the provisioning template. :smiley:

This feels like a bug, or at least something that should be anticipated with Fedoar 34+, CentOS9, RHEL9. I plan on trying to work up some smarts into the template to not send the deprecated options and find where to submit a pull request.

My questions

I didn’t find much searching Foreman/Katello content, but

  • A. is this known issue and/or something on the roadmap? and
  • B. I’m not overlooking something easy like using a different existing template that just wasn’t obvious to me, am I?
1 Like
2

A side musing, but I was running into a similar boot behavior when installing RHEL 8.3. Setting up the hosts to provision as 8.2 and then updating themselves to 8.3 in the provisioning process has been my way to work around it, but now I’m curious if it’s the same issue I found above.

3

This is also mentioned in Releases/34/ChangeSet - Fedora Project Wiki, more precisely Changes/Ignore Anaconda kernel boot parameters without inst prefix - Fedora Project Wiki

Yes, this is a bug. Please file one and submit a PR. You will find the sources here:

Probably just missed.

No you didn’t overlook anything, it’s present in the current development branch.

2 Likes
4

Thank you for the feedback! I’ve worked up a PR. Hopefully, even correctly! :smiley:

I also found that the upstream kickstart_kernel_options.erb file contained a fix that got my RHEL 8.3 issue resolved on Satellite, so that’s a bonus.

I’ll mark this as solved.

5

Thanks for an excellent analysis and a solution. For the record, the PR is here:

Can you confirm you saw something else than this one:

https://bugzilla.redhat.com/show_bug.cgi?id=1904099

This should be fixed in recent Foreman releases and Satellite as well. If you saw something different let us know please, this must be fixed.

The change we are talking in this thread should not be in 8.3 at all, that is something that should land in 9.0, at least this is what I’d expect.

Oh was that the BOOTIF issue? We are sending this into Satellite as well, probably it is delayed in the QA department but I am sure I was backporting this the other day :slight_smile:

Cheers!

6

That was indeed the issue. On the console output it looked like the same type of failure, but after digging into the rdsoreport.txt for the 8.3 install, it turned out to be the BOOTIF issue.

IIRC (since the log is now gone), I found the an error for the BOOTIF parameter stating that the MAC address wasn’t valid, and observed an extra ‘00-’ prepended to the front of the MAC. Which, that seemed wrong if it were wanting a MAC address. I found that it would continue to Anaconda if I removed the ‘00-’ string concatenation on line 26 of the kickstart_kernel_options and was thinking I found another reportable error, even if a solution wasn’t thought out.

kickstart_kernel_options - Satellite 6.8.2

25 if mac
26   bootif = '00-' + mac.gsub(':', '-')
27   options.push("BOOTIF=#{bootif}")
28 end

kickstart_kernel_options - Foreman develop branch

25 if mac
26  # hardware type is always 01 (ethernet) unless specified otherwise
27  options.push("BOOTIF=#{host_param("hardware_type", "01")}-#{mac.gsub(':', '-')}")
29  end

Then I checked the template in the source tree I pulled down to work the Fedora 34 issue and found the template had a different solution on that line already to change the hardware id to 01 rather than 00. I copied it into a new template on Satellite and it seems to have done the trick. I’ll make a note to undo my change and revert to the default kickstart_kernel_options when it lands in Satellite.

1 Like
7

Thank you, yeah what a nasty bug. We would not expect this from Anaconda team in the y-release but they told us it was actually a bug (accepting 00-). You can’t say anything against that… :slight_smile: