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.
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.
No, the ipmidetectd process attempted and failed - so it's not the one holding up the boot process. It's probably the sendmail initialisation.
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.
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
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.
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.
In article 374968789.4117139.1499169677110@mail.yahoo.com, Chris Olson chris_e_olson@yahoo.com wrote:
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.
As another respondent said, the problem won't be ipmidetectd, as that has successfully reported [FAILED].
So the problem is sendmail hanging during start-up.
I have in the past seen sendmail take an inordinately long time to start up if it is unable to resolve or discover its hostname in DNS.
You would probably find that if you waited a couple of minutes, sendmail would eventually either start or fail, and the boot continue.
But in the meantime, check your network configuration and the contents of /etc/resolv.conf. Make sure all nameservers listed in that file do actually respond, and are able to resolve queries for the machine's full hostname and IP address.
Cheers Tony
On Jul 4, 2017, at 8:01 AM, Chris Olson chris_e_olson@yahoo.com wrote:
Starting ipmidetectd: ipmidetectd: No nodes configured [FAILED] Starting sendmail:
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 billings@negate.org
Once again, my thanks to all that responded to my posting about our virtual machine CentOS 6 system start-up issue. Addressing sendmail was the key to the start-up issue.
While operating at Run Level 1, chkconfig sendmail off was commanded followed by the reboot command. This brought up the system with the complete and operational GUI interface.
The maillog had several entries from the past few days. Possibly the most telling of these messages are included below:
computer sendmail[nnnn]: unable to qualify my own domain name (computer)
computer sendmail[mmmm]: My unqualified host name (computer) unknown; sleeping for retry
During the days that we were attempting to troubleshoot the problem, the boot-up process was left on one occasion for about one hour. It appears that the sleeping for retry may have been inspired by that famous gentleman R.V. Winkle.
Since we do not need sendmail on this system, we will just leave it turned off along with IPMI features.
It remains a mystery what could have happened during a standard yum update of the system to cause this domain and/or host related sendmail issue.
On Tuesday, July 4, 2017 7:14 AM, Jonathan Billings billings@negate.org wrote:
On Jul 4, 2017, at 8:01 AM, Chris Olson chris_e_olson@yahoo.com wrote:
Starting ipmidetectd: ipmidetectd: No nodes configured [FAILED] Starting sendmail:
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 billings@negate.org
_______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 07/04/2017 09:21 AM, Chris Olson wrote:
It remains a mystery what could have happened during a standard yum update of the system to cause this domain and/or host related sendmail issue.
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:
On 07/04/2017 09:21 AM, Chris Olson wrote:
It remains a mystery what could have happened during a standard yum update of the system to cause this domain and/or host related sendmail issue.
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.
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.
On Tuesday, July 4, 2017 1:42 PM, Alexander Dalloz ad+lists@uni-x.org wrote:
Am 04.07.2017 um 19:13 schrieb Gordon Messmer:
On 07/04/2017 09:21 AM, Chris Olson wrote:
It remains a mystery what could have happened during a standard yum update of the system to cause this domain and/or host related sendmail issue.
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.
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
_______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 07/04/2017 02:17 PM, Chris Olson wrote:
The actual system has totally legitimate names for domain and host.
What actually happened during the system update is still being investigated.
Your investigation should include:
hostname dig +short $(hostname) host $(dig +short $(hostname))
Does the hostname of this system resolve?
-
Alexander Dalloz -
Chris Olson -
Gordon Messmer -
Jonathan Billings -
Pete Biggs -
tony＠softins.co.uk