Don't know if this might be hardware or software related, but it seems that every time I attempt to do a remote reboot of the machine, everything shuts down normally, and it never comes back. Just returned from the co-lo site, and when I plugged the monitor in, it had gone to the point of "rebooting" and hung. This is 4.3 on x-86.
Sam
What commands are you using to reboot the machine and what does the machine show that it was hanging on whenever it was attempting to reboot?
On 6/3/06, Sam Drinkard sam@wa4phy.net wrote:
Don't know if this might be hardware or software related, but it seems that every time I attempt to do a remote reboot of the machine, everything shuts down normally, and it never comes back. Just returned from the co-lo site, and when I plugged the monitor in, it had gone to the point of "rebooting" and hung. This is 4.3 on x-86.
Sam
-- Sam W.Drinkard -- sam@wa4phy.net WEB http://wa4phy.net Augusta Area Mesonet cell 706.825.8513 Home 706.868.7253 MAIL 4428 Branchwood Drive, Martinez Georgia, 30907-1304
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Joshua Gimer wrote:
What commands are you using to reboot the machine and what does the machine show that it was hanging on whenever it was attempting to reboot?
On 6/3/06, *Sam Drinkard * <sam@wa4phy.net mailto:sam@wa4phy.net> wrote:
Don't know if this might be hardware or software related, but it seems that every time I attempt to do a remote reboot of the machine, everything shuts down normally, and it never comes back. Just returned from the co-lo site, and when I plugged the monitor in, it had gone to the point of "rebooting" and hung. This is 4.3 on x-86.
Josh, I use "shutdown -r now". The machine shuts down properly, then at the very end of the things that are shutting down, I see the text "rebooting", but the process never completes. Just sits there hung.
Joshua Gimer wrote:
What commands are you using to reboot the machine and what does the machine show that it was hanging on whenever it was attempting to reboot?
On 6/3/06, *Sam Drinkard * <sam@wa4phy.net mailto:sam@wa4phy.net> wrote:
Don't know if this might be hardware or software related, but it seems that every time I attempt to do a remote reboot of the machine, everything shuts down normally, and it never comes back. Just returned from the co-lo site, and when I plugged the monitor in, it had gone to the point of "rebooting" and hung. This is 4.3 on x-86. Sam --
FYI... I prefer shutdown -r now myself, but I have one machine that doesn't like it. However, for whatever reason, it reboots fine with the reboot command. I haven't bothered to figure out why... just have a mental note about this issue.
Best, John Hinton
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Jun 03, 2006 at 04:46:32PM -0400, Sam Drinkard wrote:
Don't know if this might be hardware or software related, but it seems that every time I attempt to do a remote reboot of the machine, everything shuts down normally, and it never comes back. Just returned from the co-lo site, and when I plugged the monitor in, it had gone to the point of "rebooting" and hung. This is 4.3 on x-86.
Sure smells like ACPI problems.
Try these (in this order) and see if any of them solve the problem: 1) Upgrade your BIOS 2) Try booting with acpi=off
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Jun 03, 2006 at 04:46:32PM -0400, Sam Drinkard wrote:
Don't know if this might be hardware or software related, but it seems that every time I attempt to do a remote reboot of the machine, everything shuts down normally, and it never comes back. Just returned from the co-lo site, and when I plugged the monitor in, it had gone to the point of "rebooting" and hung. This is 4.3 on x-86.
Sure smells like ACPI problems.
Try these (in this order) and see if any of them solve the problem:
- Upgrade your BIOS
- Try booting with acpi=off
I'll give that a try. I incorrectly stated arch type. Is i386, not x86. It's done this same thing each time I've tried to reboot after a kernel update or upgrade.
I'll give that a try. I incorrectly stated arch type. Is i386, not x86.
Same thing in reality. x86 is a generic term that applies to i386, i486, i586, and i686. The default arch extension for most rpms on the x86 version of centos is i386. I'm not sure if there's a reason for this beyond legacy.
Likely yours isn't a true i386, as that was released around 1985, with a clockspeed of something between 16 and 33Mhz. If you have centos running on hardware that slow or that old, I want pictures! They'll make for excellent propaganda.
I had a crappy via motherboard that did this, never managed to solve it.
Sam Drinkard wrote:
Don't know if this might be hardware or software related, but it seems that every time I attempt to do a remote reboot of the machine, everything shuts down normally, and it never comes back. Just returned from the co-lo site, and when I plugged the monitor in, it had gone to the point of "rebooting" and hung. This is 4.3 on x-86.
Sam
----- Original Message ----- From: "Sam Drinkard" sam@wa4phy.net To: "CentOS mailing list" centos@centos.org Sent: Saturday, June 03, 2006 3:46 PM Subject: [CentOS] Remote reboot problem
Don't know if this might be hardware or software related, but it seems that every time I attempt to do a remote reboot of the machine, everything shuts down normally, and it never comes back. Just returned from the co-lo site, and when I plugged the monitor in, it had gone to the point of "rebooting" and hung. This is 4.3 on x-86.
Sam
-- Sam W.Drinkard -- sam@wa4phy.net WEB http://wa4phy.net Augusta Area Mesonet cell 706.825.8513 Home 706.868.7253 MAIL 4428 Branchwood Drive, Martinez Georgia, 30907-1304
Is the machine a dual processor system?
-Marco
Sam Drinkard wrote:
Don't know if this might be hardware or software related, but it seems that every time I attempt to do a remote reboot of the machine, everything shuts down normally, and it never comes back. Just returned from the co-lo site, and when I plugged the monitor in, it had gone to the point of "rebooting" and hung. This is 4.3 on x-86.
I have the same problem with an a few old Intel 815 chipset P3 boxes, but it's never annoyed me enough to fix it. 8-) I agree with Rodrigo that it's likely some sort of acpi issue
Cheers,
Chris Mauritz wrote:
Sam Drinkard wrote:
Don't know if this might be hardware or software related, but it seems that every time I attempt to do a remote reboot of the machine, everything shuts down normally, and it never comes back. Just returned from the co-lo site, and when I plugged the monitor in, it had gone to the point of "rebooting" and hung. This is 4.3 on x-86.
I have the same problem with an a few old Intel 815 chipset P3 boxes, but it's never annoyed me enough to fix it. 8-) I agree with Rodrigo that it's likely some sort of acpi issue
Cheers,
I'll try the acpi route prior to the next reboot. Just looked, and it's an AMD Sempron 3100. The machine runs flawlessly except for this remote reboot problem. I normally don't bother trying to reboot except when there is a kernel update that fixes something. As this is a production machine too, I try to leave it running as much as possible, and it's a PITA to have to get someone from the ISP's staff to meet me at the co-lo site to let me in. As for the arch, I generally use i386 to indicate anything intel or amd that is not a 64-bit processor, which as Jim mentioned is rather old terminology. I came along when 8088's were the mainstay of computers. Gosh, thinking about that, it seems like it was a century ago !
Sam Drinkard wrote:
Chris Mauritz wrote:
Sam Drinkard wrote:
Don't know if this might be hardware or software related, but it seems that every time I attempt to do a remote reboot of the machine, everything shuts down normally, and it never comes back. Just returned from the co-lo site, and when I plugged the monitor in, it had gone to the point of "rebooting" and hung. This is 4.3 on x-86.
I have the same problem with an a few old Intel 815 chipset P3 boxes, but it's never annoyed me enough to fix it. 8-) I agree with Rodrigo that it's likely some sort of acpi issue
Cheers,
I'll try the acpi route prior to the next reboot. Just looked, and it's an AMD Sempron 3100. The machine runs flawlessly except for this remote reboot problem. I normally don't bother trying to reboot except when there is a kernel update that fixes something. As this is a production machine too, I try to leave it running as much as possible, and it's a PITA to have to get someone from the ISP's staff to meet me at the co-lo site to let me in. As for the arch, I generally use i386 to indicate anything intel or amd that is not a 64-bit processor, which as Jim mentioned is rather old terminology. I came along when 8088's were the mainstay of computers. Gosh, thinking about that, it seems like it was a century ago !
While it doesn't address the underlying problem, if it's a PITA to get your datacenter folks to power cycle machines, why don't you get a network-attached power strip? APC used to sell them rather cheaply and you could telnet (or use a web interface) to remotely power cycle individual outlets on the power strip. I used to have these until there was a security exploit and APC was slow about releasing a fix. So I took them all out of service and throw a case of beer at the datacenter staff now and then. They're only too happy to closely monitor things and fluff power as required now. :-)
Cheers,
Chris Mauritz wrote:
Sam Drinkard wrote:
Chris Mauritz wrote:
Sam Drinkard wrote:
Don't know if this might be hardware or software related, but it seems that every time I attempt to do a remote reboot of the machine, everything shuts down normally, and it never comes back. Just returned from the co-lo site, and when I plugged the monitor in, it had gone to the point of "rebooting" and hung. This is 4.3 on x-86.
I have the same problem with an a few old Intel 815 chipset P3 boxes, but it's never annoyed me enough to fix it. 8-) I agree with Rodrigo that it's likely some sort of acpi issue
Cheers,
I'll try the acpi route prior to the next reboot. Just looked, and it's an AMD Sempron 3100. The machine runs flawlessly except for this remote reboot problem. I normally don't bother trying to reboot except when there is a kernel update that fixes something. As this is a production machine too, I try to leave it running as much as possible, and it's a PITA to have to get someone from the ISP's staff to meet me at the co-lo site to let me in. As for the arch, I generally use i386 to indicate anything intel or amd that is not a 64-bit processor, which as Jim mentioned is rather old terminology. I came along when 8088's were the mainstay of computers. Gosh, thinking about that, it seems like it was a century ago !
While it doesn't address the underlying problem, if it's a PITA to get your datacenter folks to power cycle machines, why don't you get a network-attached power strip? APC used to sell them rather cheaply and you could telnet (or use a web interface) to remotely power cycle individual outlets on the power strip. I used to have these until there was a security exploit and APC was slow about releasing a fix. So I took them all out of service and throw a case of beer at the datacenter staff now and then. They're only too happy to closely monitor things and fluff power as required now. :-)
Cheers,
Chris, I didn't realize such an animal existed, but that would definately help the folks save their free time on the weekends, or at times no one is at the pop. I used to have a device for controlling remote stuff that was activated via dtmf tones over an RF link, but that, unfortunately was very unsecure, however it did get used quite often back in the days of NOS and other DL layer type packet systems. I'm going to inquire tomorrow to see if they have any current means of power cycling any of the racks or outlets, but as you say, fixing the underlying problem would be the best to do. The tech support guys don't really complain about having to go down and meet me there, but I'm sure their weekends are as valuable as anyone's, including mine, so anything that would help free time stay that way would be nice.
Hi,
I am new on this forum. I use sme-server based now on centos. Before sme-server was based on redhat 7.3.
With the old version of sme-server, I used mgetty 1.1.33.
With centos, it is mgetty 1.1.31. Fedora has mgetty 1.1.33 The last version is 1.1.35
Would it be possible to include the version of mgetty (1.1.33) in centos . In fact the version that is include for the moment (1.1.31) misses some important options (faxq-helper). Could you tell me who is in charge of such change in the distribution to ask him?
Thank you anne
On Sun, 2006-06-04 at 23:54 +0200, anne linux wrote:
Would it be possible to include the version of mgetty (1.1.33) in centos . In fact the version that is include for the moment (1.1.31) misses some important options (faxq-helper). Could you tell me who is in charge of such change in the distribution to ask him?
CentOS tracks the sources of the upstream vendor, so you may want to read up on the package policy of the upstream vendor for their enterprise products:
http://www.redhat.com/advice/speaks_backport.html
-- Daniel
On Sun, 2006-06-04 at 23:54 +0200, anne linux wrote:
Hi,
I am new on this forum. I use sme-server based now on centos. Before sme-server was based on redhat 7.3.
With the old version of sme-server, I used mgetty 1.1.33.
With centos, it is mgetty 1.1.31. Fedora has mgetty 1.1.33 The last version is 1.1.35
Would it be possible to include the version of mgetty (1.1.33) in centos . In fact the version that is include for the moment (1.1.31) misses some important options (faxq-helper). Could you tell me who is in charge of such change in the distribution to ask him?
First, at pleasantly as possible, review the material on the CentOS site carefully. There you will see the policy is to stay almost 100% consistent with up-stream. You will also see that there are "add on repositories" that allow you to deviate from this policy and still have the benefits of rpm-based package management. I would provide specific help, but it's against my religion. ;-)
With this command
yum --noplugins --enablerepo=* list mgetty
You can see if any of the additional repositories have a later version. None do. After reading the material on the home page, you can determine which place would be best suited for a later version, probably rpmforge. Then a post to the appropriate project (dag, dries, atrpm, rpmforge,... ) will likely get your package or at least a reason why they don't include it.
Thank you anne
<snip sig stuff>
HTH
On Sun, 2006-06-04 at 18:15 -0400, William L. Maltby wrote:
On Sun, 2006-06-04 at 23:54 +0200, anne linux wrote:
Hi,
<snip>
Then a post to the appropriate project (dag, dries, atrpm, rpmforge,... ) will likely get your package or at least a reason why they don't include it.
OOPS! Forgot to say that several folks from those repos monitor these lists and/or work closely with the CentOS folks. So a post here will also often accomplish your goal, But it is best to copy the folks from the other projects too.
<snip>
Thank you for your answers.
I compiled mgetty 1.1.33 (with maj fedora), but I don't know if it is well for security
yum --noplugins --enablerepo=* list mgetty : Installed Packages mgetty.i386 1.1.33-02 installed Available Packages mgetty.i386 1.1.31-2 base
I will ask dag, rpmforge or another.
anne
On Mon, 2006-06-05 at 01:15 +0200, anne linux wrote:
Thank you for your answers.
I compiled mgetty 1.1.33 (with maj fedora), but I don't know if it is well for security
yum --noplugins --enablerepo=* list mgetty : Installed Packages mgetty.i386 1.1.33-02 installed Available Packages mgetty.i386 1.1.31-2 base
Generally, folks will counsel *against* this as it starts down the path of defeating the purpose of enterprise-class CentOS - high stability, reliability, and long life - by increasing difficulty of maintenance by having stuff added out of the package system or from another release upon which CentOS stuff has not been tested. However, the need must come first, IMO, and you are following up to see if it can be supported.
I will ask dag, rpmforge or another.
That should protect you from the slings and arrows of outrageous ... OOPS! Slipped into Shakespearean mode! Should suppress most gripes! :-)
anne
<snip sig stuff>
Good luck and enjoy.
Hi,
I am new on this forum. I use sme-server based now on centos. Before sme-server was based on redhat 7.3.
With the old version of sme-server, I used mgetty 1.1.33.
With centos, it is mgetty 1.1.31. Fedora has mgetty 1.1.33 The last version is 1.1.35
Would it be possible to include the version of mgetty (1.1.33) in centos . In fact the version that is include for the moment (1.1.31) misses some important options (faxq-helper). Could you tell me who is in charge of such change in the distribution to ask him?
Thank you anne
Anne,
Fedora is Redhat's development OS, once the software has been tested on that OS it may appear in RHEL4 and hence Centos . You could try installing the Fedora version, but you risk having problems as it may not have been fully tested in the Redhat/Centos environment.
I used to use Fedora, but moved to Centos as I got fed up with updates breaking my setup.
Rob
centos@bathnetworks.com wrote:
Fedora is Redhat's development OS, once the software has been tested on that OS it may appear in RHEL4 and hence Centos .
No, it won't. At least not in CentOS4. There aren't any version upgrades in CentOS (or RHEL4) for the lifetime of the product (firefox and mozilla might be another thing, as changes in there seem to be hard to backport). you will see backported security fixes, but mgetty will very likely stay at 1.31.
Ralph
On Sun, 2006-06-04 at 12:40 -0400, Sam Drinkard wrote:
Chris Mauritz wrote:
Sam Drinkard wrote:
Chris Mauritz wrote:
Sam Drinkard wrote:
Don't know if this might be hardware or software related, but it seems that every time I attempt to do a remote reboot of the machine, everything shuts down normally, and it never comes back. Just returned from the co-lo site, and when I plugged the monitor in, it had gone to the point of "rebooting" and hung. This is 4.3 on x-86.
I have the same problem with an a few old Intel 815 chipset P3 boxes, but it's never annoyed me enough to fix it. 8-) I agree with Rodrigo that it's likely some sort of acpi issue
Cheers,
I'll try the acpi route prior to the next reboot. Just looked, and it's an AMD Sempron 3100. The machine runs flawlessly except for this remote reboot problem. I normally don't bother trying to reboot except when there is a kernel update that fixes something. As this is a production machine too, I try to leave it running as much as possible, and it's a PITA to have to get someone from the ISP's staff to meet me at the co-lo site to let me in. As for the arch, I generally use i386 to indicate anything intel or amd that is not a 64-bit processor, which as Jim mentioned is rather old terminology. I came along when 8088's were the mainstay of computers. Gosh, thinking about that, it seems like it was a century ago !
While it doesn't address the underlying problem, if it's a PITA to get your datacenter folks to power cycle machines, why don't you get a network-attached power strip? APC used to sell them rather cheaply and you could telnet (or use a web interface) to remotely power cycle individual outlets on the power strip. I used to have these until there was a security exploit and APC was slow about releasing a fix. So I took them all out of service and throw a case of beer at the datacenter staff now and then. They're only too happy to closely monitor things and fluff power as required now. :-)
Cheers,
Chris, I didn't realize such an animal existed, but that would definately help the folks save their free time on the weekends, or at times no one is at the pop. I used to have a device for controlling remote stuff that was activated via dtmf tones over an RF link, but that, unfortunately was very unsecure, however it did get used quite often back in the days of NOS and other DL layer type packet systems. I'm going to inquire tomorrow to see if they have any current means of power cycling any of the racks or outlets, but as you say, fixing the underlying problem would be the best to do. The tech support guys don't really complain about having to go down and meet me there, but I'm sure their weekends are as valuable as anyone's, including mine, so anything that would help free time stay that way would be nice.
Sam,
I use these:
There are more choices with different options here:
Thanks, Johnny Hughes
-
anne linux -
centos＠bathnetworks.com -
Chris Mauritz -
Daniel de Kok -
Jim Perrin -
John Hinton -
Johnny Hughes -
Joshua Gimer -
Marco Garza -
Ralph Angenendt -
Rodrigo Barbosa -
Sam Drinkard -
Tony Wicks -
William L. Maltby