If a bare metal system on the network is not automatically added to the
Systems list, check these things first:
You must have the
File paths and parameters must be configured correctly. Check that the
initrd0.imgfiles, which are provided by
pxe-default-image, are in the locations specified in the
Ensure the networking equipment connecting the bare metal system to the SUSE Manager server is working correctly, and that you can reach the SUSE Manager server IP address from the server.
The bare metal system to be provisioned must have PXE booting enabled in the boot sequence, and must not be attempting to boot an operating system.
The DHCP server must be responding to DHCP requests during boot. Check the PXE boot messages to ensure that:
the DHCP server is assigning the expected IP address
the DHCP server is assigning the the SUSE Manager server IP address as
Ensure Cobbler is running, and that the Discovery feature is enabled.
If you see a blue Cobbler menu shortly after booting, discovery has started. If it does not complete successfully, temporarily disable automatic shutdown in order to help diagnose the problem. To disable automatic shutdown:
pxe-default-profilein the Cobbler menu with the arrow keys, and press the Tab key before the timer expires.
Add the kernel boot parameter
spacewalk-finally=runningusing the integrated editor, and press Enter to continue booting.
Enter a shell with the username
linuxto continue debugging.
Due to a technical limitation, it is not possible to reliably distinguish a new bare metal system from a system that has previously been discovered. Therefore, we recommended that you do not power on bare metal systems multiple times, as this will result in duplicate profiles.
When supported products are synchronized, bootstrap repositories are automatically created and regenerated on the SUSE Manager Server. When a product reaches end-of-life and becomes unsupported, bootstrap repositories must be created manually if you want to continue using the product.
For more information about bootstrap repositories, see client-configuration:registration-bootstrap.adoc.
At the command prompt on the SUSE Manager Server, as root, list the available unsupported bootstrap repositories with the
--forceoption, for example:
mgr-create-bootstrap-repo --list --force 1. SLE-11-SP4-x86_64 2. SLE-12-SP2-x86_64 3. SLE-12-SP3-x86_64
Create the bootstrap repository, using the appropriate repository name as the product label:
mgr-create-bootstrap-repo --create SLE-12-SP2-x86_64 --force
If you do not want to create bootstrap repositories manually, you can check whether LTSS is available for the product and bootstrap repository you need.
If you have used your hypervisor clone utility, and attempted to register the cloned Salt client, you might get this error:
We're sorry, but the system could not be found.
This is caused by the new, cloned, system having the same machine ID as an existing, registered, system. You can adjust this manually to correct the error and register the cloned system successfully.
For more information and instructions, see administration:tshoot-registerclones.adoc.
Salt runs remote commands from
/tmp on the client’s filesystem.
Therefore you must not mount
/tmp with the
On SLES 11 systems, clients can sometimes have SSL errors which make some operations unusable, including package management and bootstrapping. In this case, you will see an error like this:
Repository 'SLES11-SP4-SUSE-Manager-Tools x86_64' is invalid. [|] Valid metadata not found at specified URL(s) Please check if the URIs defined for this repository are pointing to a valid repository. Skipping repository 'SLES11-SP4-SUSE-Manager-Tools x86_64' because of the above error. Download (curl) error for 'www.example.com': Error code: Unrecognized error Error message: error:1409442E:SSL routines:SSL3_READ_BYTES:tlsv1 alert protocol version
This occurs because Apache requires TLS v1.2, but older versions of SLES do not support this version of the TLS protocol.
To fix this error, you need to force Apache to accept a greater range of protocol versions.
/etc/apache2/ssl-global.conf configuration file, locate the
SSLProtocol line, and update it to read:
SSLProtocol all -SSLv2 -SSLv3
This will need to be done manually on the server, and with a Salt state on the Proxy.
apache service on each system after making the changes.
You have clients connecting through a SUSE Manager proxy. Although these clients may appear in the Web UI you are unable to see that they are connected through a proxy. If this is the case you could be using a FQDN to connect to the proxy that is unknown to SUSE Manager. To correct this behaviour, specify any additional FQDNS in your minion config on the proxy as grains.
grains: susemanager: custom_fqdns: - name.one - name.two