I am renting a dedicated bare metal server running the latest version of CentOS. It's new and I haven't fully configured it.

I updated the existing packages and rebooted the machine remotely using # /sbin/reboot. Now a half an hour later I still can't pull up a login screen with PuTTY. It just waits a few seconds and displays a timeout error.

Does it really take that long to reboot the server? Should I expect to wait longer? Could I have broken something with the updates and now have to contact the hosting company to fix it?

UPDATE: This was solved. The kernel must have been updated and was causing a conflict at boot. I had the data center manager start with a stable kernel and I was able to get in. I am now removing the old kernels to prevent a conflict in the future. Not out of the woods yet.

  • 3
    No, it shouldn't take that long. Get on the remote console and see what's going on. – Michael Hampton Jun 5 '14 at 18:31
  • @MichaelHampton I can try the "Reboot in Rescue Mode" approach... – gillytech Jun 5 '14 at 18:34
  • Wow that downvote makes me feel really welcome. – gillytech Jun 5 '14 at 18:45
  • 3
    I see you are coming over from SO. Our Professional Capacity requirement is very different than SO's scope of " professional and enthusiast programmers". You are likely being downvoted because your question does to appear to met our those requirements. Don't take the downvote personally. – user62491 Jun 5 '14 at 19:55
  • @kce I see, no harm done. I think your explanation gets the point across more clearly. Basically I'm on the "people's server" on SO and Server Fault is more of the "Varsity" team... good to know. I'm building real skills in all of these areas and I have a LOT to thank the SE community for! – gillytech Jun 6 '14 at 1:25

It means your server isn't up. It could have failed at any step in the boot process. On bare-metal hardware, an EL6 server should take between 4 and 10 minutes to boot.

It's possible that updates could have caused this issue. This could also be a hardware error. Ask your hosting company to get an IP KVM on the server and see what's on the screen at the moment.

|improve this answer|||||
  • Turns out at console I had found that this server was trying to boot into a newly installed kernel. This kernel was causing the server to panic and crash. So now I need to remove or reinstall the second kernel – gillytech Jun 5 '14 at 19:33

Did you accidentally lock yourself out with iptables? I've lost count of the times I set the default input policy to DROP without first accepting SSH traffic.

|improve this answer|||||
  • Though this is a very valid point I'm afraid that wasn't the issue this time. – gillytech Jun 5 '14 at 19:31

Not the answer you're looking for? Browse other questions tagged or ask your own question.