I am running CentOS 6.8
The system went down when we try to reboot it we get the message ST:3P7Y9Y1
Do you know what the problem might be.
I’m guessing you mean the message on the front panel, which is the service tag number.
There should be more helpful information if you attach a monitor to the machine and boot it up.
There is a monitor attached, but the computer does not boot up. It stops before ending the boot. With no message on the monitor.
Yes, you are right the message is on the front panel. I thought the service tag was a different number.
Thanks for responding.
indeed, thats the service tag for a Dell PowerEdge T620, shipped in September 2013, with dual Xeon E5-X2667, 48GB ram, and 10 3TB drives, originally running RHEL 6.5
indeed, you need to connect a monitor to it to determine what stage of the boot is failing and why.
You are right it is a Dell PowerEdge. However as I said it stops in the middle of booting with no message.
I’m sending to you, directly, because manitu is again blocking my ISP….
Rosenthal, Shoshana wrote:
middle of booting with no message.
You say “in the middle of booting” – please define.
1. Did it finish POST?
2. Did you see the kernel it was about to boot, displayed by grub?
If the latter, *sigh*, hit “e” when you see the kernel, then edit the kernel line, and DELETE rhgb quiet, then boot.
> middle of booting with no message. When it behaves weird like that, starting to boot and then quitting and it is a Dell, open the case and look at the motherboard. Look for failed electrolytic capacitors. They usually have scribe marks on the top in the form of an “X” or a “K”. The failed ones will be bulging up or actually split.
If it is a corporate machine under maintenance, make Dell fix it. If it is your machine or not under warrantee and you want to fix it, it is not that hard. Capacitors are available on Amazon. You can read the value off the side of the capacitor.
there may be some status LEDs on the mainboard inside the server that show power on self test results.
But, its a 4-5 year old Dell, most likely its power supply has failed. or the main board. For sure its a hardware problem, as if it was a CentOS specific software problem, you’d see the BIOS self test, setup messages, then grub boot, etcetc.
standard PC server hardware trouble shooting applies… if its on service contract, call your support provider. if not, and your time is worth less than a replacement server, open it up, unplug everything extra, reseat all the remaining connectors, see if it passes power-on-self-test. if not, swap PSU with an identical server, try again. If it DOES pass POST w/ everything unplugged, plug back in a minimum amount of stuff, repeat…. etc etc etc.
I figured out that the system boots OK and it is possible to login remotely. However the monitor does not start up.
Do you know how to fix it?
This is a wild guess since the problem I had occurred on Ubuntu 16.04 LTS but the symptoms are identical. Try ‘systemctl enable console-getty.service’ then ‘systemctl start console-getty.service’ or, if it is headless (serial console only), ‘systemctl enable serial-getty@ttyS0.service‘ then ‘systemctl start serial-getty@ttyS0.service‘ assuming it’s ttyS0). For VMs (specifically kvm/qemu) neither of these “solutions” worked.
—– Original Message —
Try another console like ALT-F2. See if you have a black screen login prompt. I opened a bug with RedHat for a system that when I went from 6.7 to 6.8 booted but would not start the X server. Problem was in the MACH64 driver. It is missing an external symbol that the X server requires.
I did try other console and it did not work. I did go from 6.7 to 6.8 but with CentOS not redhat.
set the system to boot into init state 3 (non-graphical) instead of state 5 (full GUI). to do this, edit /etc/inittab, and change the one non-commented line in that file to read…
(its probably set to id:5:…. now), then reboot, and you should come up with a text console. Virtually ALL my servers run with text consoles as they are headless, but if you really need X support, its easier to debug it starting from text …
Did you try another monitor — one that you know works, and that turns on when plugged into the outlet near the machine in question?
Also, some monitors go to sleep, so even an otherwise working monitor may require a couple of taps on the attached keyboard to wake them up.
I am also using CentOS, but to get a bug fixed, you have to go upstream to RedHat. I think John Pierce is right, I had to change my run level to get the alternate consoles to work. I still have the machine at run level 3 hoping that a bug fix lets me go back to run level 5. Other machines work fine, just the 2 with the MACH64 video on the motherboard will no longer run X.
Yes I did try another working console did not work
Sent from my iPad
In previous versions of CentOS, runlevel 5 put a virtual console on console 7, so ctrl-alt-F7 to switch to that console might work if changing the default runlevel is not feasible. Note that if X is trying to do something and not letting go of the virtual console, then you need ctrl in addition to alt-FN because X will intercept a plain alt-FN. (I
usually set my servers to runlevel 3 by default, so I haven’t tried this on CentOS in a while. My Ubuntu laptop does put a console on F7 even in runlevel 5.)