suse/manager-build-profiles

Example profiles for building images and systems with SUSE Manager and Uyuni

SUSE Manager building profiles

This repository contains sources that can be used with SUSE Manager to build various types of images.

Repository is organized by build types and then individual image names.

manager-build-profiles's Issues

Is PXE the only option ?

Hi I am trying to get a sle-pos 15 image for the company to test our pos application. From what I can see this is not something you can download from suse you have to build an image for it.
I have a standard susemanager server (not the retail version) that I have used to build an image of
POS_Image-Graphical7
From what I have been able to see in the config and from a few days of trying options this will only build a pxe image, this isn't really any use for us as we do not use pxe for our pos devices they all have everything locally installed.
Is there any way to get this to be created as an iso that we can then install to a device or is that not a possibility ?

Add OS Images templates for vmx

SUSE publishes them at:
https://download.suse.com/protected/Summary.jsp?buildid=7y5voB_aYwk~

It may be worth to add them to our templates (as mirror).

add sle12 sp5 image

12sp3 is obsolete, we should be using 12sp5

Ignition Firstboot issue

\$ignition_firstboot

There are several entries like this in OSImage/SLE-Micro54/SLE-Micro.kiwi.

We're a bit confused by these, if that's just a typo or something. I'm not sure what the \$ is for. It seems like it should be ignition.firstboot

Let me know what you think, thanks.

How to register SLES Systems using Autoyast XML

in https://github.com/SUSE/manager-build-profiles/blob/master/AutoYaST/SLES-15-SP2-installation/README.md it says "For using an activation key, specify the following valiable: registration_key=...."

I can't find any reference to "registration_key" in both .xml files within https://github.com/SUSE/manager-build-profiles/tree/master/AutoYaST/SLES-15-SP2-installation. Is that a bug / missing implementation? Or any kind of integrated default behavior?
How can i register newly installed systems using autoyast?

cracklib-dict-small and cracklib-dict-full zypper package conflict when building sle-micro4.4 image

Perhaps the sle-micro5.4 profile should be adjusted, or maybe this will be helpful if anyone else runs into this issue. I still cannot explain the root cause of the problems mentioned in detail below.

First I'll explain the workaround, and then get into the lengthy explanation of the issue.

Workaround 1

I added the following code to the OSImage/SLE-Micro54/SLE-Micro.kiwi file.

    <packages type="bootstrap" profiles="full">
        <package name="cracklib-dict-small"/>
    </packages>

This ensures that the cracklib and cracklib-dict-small packages are installed, during the bootstrap phase, instead of cracklib-dict-full. This satisfies the later requirements, and avoids any potential conflict.

Workaround 2

In SUMA, I created a CLM filter, and filtered out the cracklib-dict-full package, and built this to a CLM project environment. Then I used the corresponding env's channels/activation key in the kiwi image profile. This alone without changing the kiwi file at all, made sure that the cracklib-dict-small package was installed instead during the bootstrap package install phase.

Full Issue Explanation

Me and another user (kevin) both did exactly the following, with the result of his working, and mine failing:

• Used SUSE Manager 4.3 for image profile/kiwi buildhost management
• Registered a plain SLES 15 SP4 machine to SUMA as an OS build host
• Copied the contents of the directory manager-build-profiles/OSImage/SLE-Micro54 in this repo to the buildhost
• Created a kiwi profile in SUMA pointed at this directory
• Ran the build with the options: --profile x86 --profile full

We ran diffs against our kiwi files, and made sure the channels/packages in suma were the exact same, and several other things. We could not determine any differences.

Bootstrap Package Install Phase

At the "bootstrap" phase, both of ours runs this, further showing that kiwi up to this point is running the same:

zypper --non-interactive --gpg-auto-import-keys ... install --download in-advance --auto-agree-with-licenses --no-recommends -- filesystem findutils rhn-org-trusted-ssl-cert-osimage zypper

This is where things differ... For some reason kevins zypper runs the dependency checks and installs 95 packages, whereas mine gets 110 packages.

Kevins Package List

bash bash-sh boost-license1_66_0 ca-certificates coreutils crypto-policies diffutils file-magic filesystem fillup findutils glibc gpg2 grep info krb5 libacl1 libassuan0 libattr1 libaugeas0 libboost_system1_66_0 libboost_thread1_66_0 libbrotlicommon1 libbrotlidec1 libbz2-1 libcap2 libcom_err2 libcrypt1 libcurl4 libdw1 libelf1 libffi7 libgcc_s1 libgcrypt20 libglib-2_0-0 libgmp10 libgpg-error0 libgpgme11 libidn2-0 libjitterentropy3 libkeyutils1 libksba8 libldap-2_4-2 libldap-data liblua5_3-5 liblz4-1 liblzma5 libmagic1 libncurses6 libnghttp2-14 libnpth0 libopenssl1_1 libp11-kit0 libpcre1 libpcre2-8-0 libpopt0 libprocps7 libprotobuf-lite20 libproxy1 libpsl5 libreadline7 libsasl2-3 libselinux1 libsigc-2_0-0 libsolv-tools libsqlite3-0 libssh-config libssh4 libstdc++6 libsystemd0 libtasn1 libtasn1-6 libudev1 libunistring2 libusb-1_0-0 libverto1 libxml2-2 libyaml-cpp0_6 libz1 libzck1 libzio1 libzstd1 libzypp openssl-1_1 p11-kit p11-kit-tools perl-base pinentry procps rhn-org-trusted-ssl-cert-osimage rpm rpm-config-SUSE system-user-root terminfo-base zypper

My Package List

bash bash-sh boost-license1_66_0 ca-certificates coreutils cracklib cracklib-dict-full crypto-policies diffutils file-magic filesystem fillup findutils glibc gpg2 grep info krb5 libacl1 libassuan0 libattr1 libaudit1 libaugeas0 libboost_system1_66_0 libboost_thread1_66_0 libbrotlicommon1 libbrotlidec1 libbz2-1 libcap2 libcom_err2 libcrack2 libcrypt1 libcurl4 libdw1 libeconf0 libelf1 libffi7 libgcc_s1 libgcrypt20 libglib-2_0-0 libgmp10 libgpg-error0 libgpgme11 libidn2-0 libjitterentropy3 libkeyutils1 libksba8 libldap-2_4-2 libldap-data liblua5_3-5 liblz4-1 liblzma5 libmagic1 libncurses6 libnghttp2-14 libnpth0 libnsl2 libopenssl1_1 libp11-kit0 libpcre1 libpcre2-8-0 libpopt0 libprocps7 libprotobuf-lite20 libproxy1 libpsl5 libreadline7 libsasl2-3 libselinux1 libsemanage-conf libsemanage2 libsepol2 libsigc-2_0-0 libsolv-tools libsqlite3-0 libssh-config libssh4 libstdc++6 libsystemd0 libtasn1 libtasn1-6 libtirpc-netconfig libtirpc3 libudev1 libunistring2 libusb-1_0-0 libverto1 libxml2-2 libyaml-cpp0_6 libz1 libzck1 libzio1 libzstd1 libzypp login_defs openssl-1_1 p11-kit p11-kit-tools pam perl-base permissions pinentry procps rhn-org-trusted-ssl-cert-osimage rpm rpm-config-SUSE shadow system-user-root terminfo-base zypper

Difference

cracklib
cracklib-dict-full
libaudit1
libcrack2
libeconf0
libnsl2
libsemanage-conf
libsemanage2
libsepol2
libtirpc-netconfig
libtirpc3
login_defs
pam
permissions
shadow

I have no clue on mine what is triggering these additional packages in the dependency handling on mine. We used the exact same SUMA repos, with the same number of packages, etc.

Image Package Install Phase

In the next step, during the "image" phase his completely builds, but mine will fail. Mine is trying to add the cracklib-dict-small as a requirement of "microos-base", and runs into a conflict with cracklib-dict-full.

DEBUG: 16:26:53 | system: Problem: the to be installed patterns-microos-basesystem-5.4.0-150400.1.1.x86_64 requires 'pattern() = microos-base', but this requirement cannot be provided
DEBUG: 16:26:53 | system:   not installable providers: patterns-microos-base-5.4.0-150400.1.1.x86_64[key_repo3]
DEBUG: 16:26:53 | system:  Solution 1: Following actions will be done:
DEBUG: 16:26:53 | system:   do not install patterns-microos-basesystem-5.4.0-150400.1.1.x86_64
DEBUG: 16:26:53 | system:   do not install patterns-microos-defaults-5.4.0-150400.1.1.x86_64
DEBUG: 16:26:53 | system:   do not install patterns-microos-container_runtime-5.4.0-150400.1.1.x86_64
DEBUG: 16:26:53 | system:   do not install pattern:basesystem-5.4.0-150400.1.1.x86_64
DEBUG: 16:26:53 | system:   do not install pattern:microos-defaults-5.4.0-150400.1.1.x86_64
DEBUG: 16:26:53 | system:   do not install pattern:microos-container_runtime-5.4.0-150400.1.1.x86_64
DEBUG: 16:26:53 | system:  Solution 2: deinstallation of cracklib-dict-full-2.8.12-1.22.x86_64
DEBUG: 16:26:53 | system:  Solution 3: break patterns-microos-basesystem-5.4.0-150400.1.1.x86_64 by ignoring some of its dependencies
DEBUG: 16:26:53 | system: Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): c

Problem 1 - Which Package Requirement is adding cracklib?

I tried to chroot into the build's chroot filter on the failing build and run some rpm commands on the installed packages to try to identify which of the packages (filesystem findutils rhn-org-trusted-ssl-cert-osimage zypper) are chain leading to the cracklib packages . I wasn't able to identify any requirements that are making that happen during the bootstrap phase, and it doesn't make sense why this happens for me and not for Kevin.

Problem 2 - cracklib-dict-full or cracklib-dict-small

I can't identify why cracklib is choosing "cracklib-dict-full", I don't see anywhere where this is being specified. I'm assuming I'm somehow missing some requirement somewhere. For SLE-Micro, do we always want small anyway? Should the packages have some type of logic built in to make sure we don't get full?

I'm wondering if there is even something weirder going on, like a SUMA package with the same version/release but with different requirements then it should have (since SUMA will share packages if they are already synched from different channels).

invalid XML error from SUMA 4.3

I'm trying to use https://github.com/SUSE/manager-build-profiles/tree/master/AutoYaST/SLES-12-SPn-to-SLES-15-SP2)/autoyast.xml and when the server attempts autoinstallation I'm getting the error 'Invalid XML' from the server when it boots and attempts to start the autoinstallation. This is on SUMA 4.3 using a Autoinstallation profile and this XML example