Project

General

Profile

Bug #34311

AutoYaST SLES template invalid for SLES 15 SP3

Added by Tim Eilers 5 months ago. Updated 4 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Templates
Target version:
-
Difficulty:
Triaged:
Yes
Bugzilla link:
Fixed in Releases:
Found in Releases:

Description

The autoyast installation of SLES 15 SP3 does not like a few XML elements of the AutoYaST SLES template anymore:

"dhcp_resolv" is not supported anymore as it looks ( https://github.com/theforeman/foreman/blob/develop/app/views/unattended/provisioning_templates/provision/autoyast_sles_default.erb#L37).

The whole "runlevel" block is not supported anymore (https://github.com/theforeman/foreman/blob/develop/app/views/unattended/provisioning_templates/provision/autoyast_sles_default.erb#L125).
Instead it needs to look like this:

  <services-manager>
    <default_target>multi-user</default_target>
    <services>
      <enable>
        <service>sshd</service>
      </enable>
    </services>
  </services-manager>

With these two changes the XML gets valid again. (Can not confirm that 100%-ly, since we use our own copied templated with a few custom modifications and made those changes there)

It is worth to mention that SuSE made this changes under the hood between SLES 15 SP2 and SLES 15 SP3 without mentioning those changes in the documentations :-/

Associated revisions

Revision 4a8ed191 (diff)
Added by Marcel K├╝hlhorn 4 months ago

Fixes #34311 - Update AutoYaST SLES default for 15 SP3

History

#1 Updated by Lukas Zapletal 5 months ago

  • Triaged changed from No to Yes

Hello, thanks for the report. Contributions welcomed!

#2 Updated by The Foreman Bot 4 months ago

  • Status changed from New to Ready For Testing
  • Pull request https://github.com/theforeman/foreman/pull/9113 added

#3 Updated by Tim Eilers 4 months ago

Sorry, this issue got out of my view. We had to make a few further changes, until it really worked:

This had to be added into the pre-script section:

      <script>
        <interpreter>shell</interpreter>
        <filename>start.sh</filename>
        <source>
        <![CDATA[
#!/bin/sh
rpmkeys --import https://yum.puppet.com/RPM-GPG-KEY-puppet-20250406
]]>
        </source>
      </script>

Without it, you can tell it to accept the GPG key and signature of the puppet package in any way, it just would not accept it.

Also we had the problem, that a puppet run started already after the first reboot, but failed to run successful, since f.e. package installs where blocked by YaST, which blocked zypper. So we moved the enable of the puppet service to "init-scripts" section and moved it out of the "puppet_setup" snippet in case of SLES >= 15. This way it is first enabled after the first reboot and first starts with the second reboot, which is a normal reboot, where all install actions are done.

We have some further modifications specific to our infrastructure, so i am sorry, that i can not test your PR.

#4 Updated by The Foreman Bot 4 months ago

  • Fixed in Releases 3.3.0 added

#5 Updated by Anonymous 4 months ago

  • Status changed from Ready For Testing to Closed

Also available in: Atom PDF