Troubleshooting¶

Troubleshooting data processing¶

In this case ironic-inspector logs should give a good idea what went wrong. E.g. for RDO or Fedora the following command will output the full log:

sudo journalctl -u openstack-ironic-inspector

(use openstack-ironic-discoverd for version < 2.0.0).

If ramdisk_error plugin is enabled and ramdisk_logs_dir configuration option is set, ironic-inspector will store logs received from the ramdisk to the ramdisk_logs_dir directory. This depends, however, on the ramdisk implementation.

Troubleshooting PXE boot¶

PXE booting most often becomes a problem for bare metal environments with several physical networks. If the hardware vendor provides a remote console (e.g. iDRAC for DELL), use it to connect to the machine and see what is going on. You may need to restart introspection.

Another source of information is DHCP and TFTP server logs. Their location depends on how the servers were installed and run. For RDO or Fedora use:

$ sudo journalctl -u openstack-ironic-inspector-dnsmasq

(use openstack-ironic-discoverd-dnsmasq for version < 2.0.0).

The last resort is tcpdump utility. Use something like

$ sudo tcpdump -i any port 67 or port 68 or port 69

to watch both DHCP and TFTP traffic going through your machine. Replace any with a specific network interface to check that DHCP and TFTP requests really reach it.

If you see node not attempting PXE boot or attempting PXE boot on the wrong network, reboot the machine into BIOS settings and make sure that only one relevant NIC is allowed to PXE boot.

If you see node attempting PXE boot using the correct NIC but failing, make sure that:

1. network switches configuration does not prevent PXE boot requests from propagating,
2. there is no additional firewall rules preventing access to port 67 on the machine where ironic-inspector and its DHCP server are installed.

If you see node receiving DHCP address and then failing to get kernel and/or ramdisk or to boot them, make sure that:

1. TFTP server is running and accessible (use tftp utility to verify),

2. no firewall rules prevent access to TFTP port,

3. SELinux is configured properly to allow external TFTP access,

   If SELinux is neither permissive nor disabled, you should config tftp_home_dir in SELinux by executing the command

   $ sudo setsebool -P tftp_home_dir 1
   

   See the man page for more details.

4. DHCP server is correctly set to point to the TFTP server,

5. pxelinux.cfg/default within TFTP root contains correct reference to the kernel and ramdisk.

Troubleshooting ramdisk run¶

First, check if the ramdisk logs were stored locally as described in the Troubleshooting data processing section. If not, ensure that the ramdisk actually booted as described in the Troubleshooting PXE boot section.

Finally, you can try connecting to the IPA ramdisk. If you have any remote console access to the machine, you can check the logs as they appear on the screen. Otherwise, you can rebuild the IPA image with your SSH key to be able to log into it. Use the dynamic-login or devuser element for a DIB-based build or put an authorized_keys file in /usr/share/oem/ for a CoreOS-based one.

Troubleshooting DNS issues on Ubuntu¶

Ubuntu uses local DNS caching, so tries localhost for DNS results first before calling out to an external DNS server. When DNSmasq is installed and configured for use with ironic-inspector, it can cause problems by interfering with the local DNS cache. To fix this issue ensure that /etc/resolve.conf points to your external DNS servers and not to 127.0.0.1.

On Ubuntu 14.04 this can be done by editing your /etc/resolvconf/resolv.conf.d/head and adding your nameservers there. This will ensure they will come up first when /etc/resolv.conf is regenerated.