44 General Troubleshooting Principles #
Before diving into component-specific issues, consider these general principles:
Check logs: Logs are the primary source of information. Most of the times the errors are self explanatory and contain hints on what failed.
Check clocks: Having clock differences between systems can lead to all kinds of different errors. Ensure clocks are in sync. EIB can be instructed to force clock sync at boot time, see Configuring OS Time (Chapter 3, Standalone clusters with Edge Image Builder).
Boot Issues: If the system is stuck during boot, note down the last messages displayed. Access the console (physical or via BMC) to observe boot messages.
Network Issues: Verify network interface configuration (
ip a
), routing table (ip route
), test connectivity from/to other nodes and external services (ping
,nc
). Ensure firewall rules are not blocking necessary ports.Verify component status: Use
kubectl get
andkubectl describe
for Kubernetes resources. Usekubectl get events --sort-by='.lastTimestamp' -n <namespace>
to see the events on a particular Kubernetes namespace.Verify services status: Use
systemctl status <service>
for systemd services.Check syntax: Software expects certain structure and syntax on configuration files. For yaml files, for example, use
yamllint
or similar tools to verify the proper syntax.Isolate the problem: Try to narrow down the issue to a specific component or layer (for example, network, storage, OS, Kubernetes, Metal3, Ironic,…).
Documentation: Always refer to the official SUSE Edge documentation and also upstream documentation for detailed information.
Versions: SUSE Edge is an opinionated and thorough tested version of different SUSE components. he versions of each component per SUSE Edge release can be observed in the SUSE Edge support matrix.
Known issues: For each SUSE Edge release there is a “Known issues” section on the release notes that contains information of issues that will be fixed on future releases but can affect the current one.