System Start-Up Issue Progress
My thanks to all that responded to my posting about our virtual machine CentOS 6 system start-up issue. I found the alternative boot options to be the most helpful. Interrupting the boot-up process with Alt-d or Escape allowed me to see what appears to be a quite normal string of start, install and mount activity. However, this process ends with the system hanging at the point below:
Starting ipmidetectd: ipmidetectd: No nodes configured [FAILED]
Starting sendmail:
It is not clear to me whether the boot-up process is hanging due to the failed starting of ipmidetectd or sendmail, but I suspect that the ipmidetectd start up failure is the actual cause. It is not clear whether any IPMI related features were ever installed.
Interrupting the boot-up process and selecting Run Level 1 results in a functioning system. Starting with other Run Levels results in the incomplete boot-up process noted previously. Using the
“service network start” command yielded functional network and internet connectivity. This enabled the successful execution of yum update. The update consisted of kernel and other updates with a total download size of 274 MB.
After this update, the boot-up process still hangs at the point indicated above. Why this is happening is still a mystery and if it actually is IPMI related, why would this be appropriate or even needed in a CentOS system that is running on VirualBox. There is no IPMI related hardware accessible to the virtual CentOS system or on the Windows 7 host system. It would be good if the IPMI start-up could be disabled.
7 thoughts on - System Start-Up Issue Progress
No, the ipmidetectd process attempted and failed – so it’s not the one holding up the boot process. It’s probably the sendmail initialisation.
At run level 1 do
chkconfig sendmail off
to stop it starting at boot time. You can then investigate why sendmail is having an issue. Look in /var/log/messages and
/var/log/maillog to see if there are any clues.
If you really suspect that it’s the IPMI subsystem, then also do
chkconfig ipmidetectd off
IPMI isn’t in the standard install for CentOS 6 (and actually, neither is sendmail – postfix is the default), so it must have been actively selected or installed. Nevertheless you can turn off the IPMI detection as above. If you want to remove the IPMI stuff, then search for any installed IPMI rpms and use yum to remove them.
P.
Any chance that this system doesn’t have valid DNS lookups?
What I see above is that ipmidetetd failed (which doesn’t block) and then it is stuck starting sendmail. If memory serves me (I haven’t used sendmail in years) sendmail gets stuck waiting for a response from DNS servers when it’s performing part of its startup.
—
Jonathan Billings
Any chance that this system doesn’t have valid DNS lookups?
What I see above is that ipmidetetd failed (which doesn’t block) and then it is stuck starting sendmail. If memory serves me (I haven’t used sendmail in years) sendmail gets stuck waiting for a response from DNS servers when it’s performing part of its startup.
—
Jonathan Billings
Run “hostname”. Has the hostname changed? Run “ls -l /etc/hosts
/etc/resolv.conf”. Have those files changed recently?
It’s possible that this system was working in the past because its hostname was set up in DNS, and was removed. In that case, the problem wasn’t related to “yum.” sendmail would (IIRC) continue working after the system’s hostname was removed from DNS, until the next time the system rebooted.
Am 04.07.2017 um 19:13 schrieb Gordon Messmer:
Sendmail demands a hostname with at least a single dot in it. “computer”
is in no way a valid FQDN. “computer.localdomain” would be fine and if it has an entry in /etc/hosts.
Alexander
Organization policy dictates that information copied from systems with Internet access be “sanitized”. Thus the FAKE name computer as well as the designations nnnn and mmmm provided in my previous messages and presented again below:
computer sendmail[nnnn]: unable to qualify my own domain name (computer)
computer sendmail[mmmm]: My unqualified host name (computer) unknown;
sleeping for retry
The actual system has totally legitimate names for domain and host.
What actually happened during the system update is still being investigated. In the three years that this virtual CentOS 6
system has been running, updates have taken us from 6.5 to 6.9.
These updates have been executed using yum update and accepting all updates available. This is the very first time anything like this has happened. All updates have been successful. It is very fortunate that we do not need sendmail.
Thanks again for responses to my messages. We are still learning.
Am 04.07.2017 um 19:13 schrieb Gordon Messmer:
Sendmail demands a hostname with at least a single dot in it. “computer”
is in no way a valid FQDN. “computer.localdomain” would be fine and if it has an entry in /etc/hosts.
Alexander
Your investigation should include:
hostname
dig +short $(hostname)
host $(dig +short $(hostname))
Does the hostname of this system resolve?