Hi Guys!
Thanks to the whole Centos team for all their hard work. You have no IDEA how much I appreciate it!
I ran "yum upgrade" last night, rebooted this morning and encountered a couple of small problems: 1. "shutdown -h now" goes all the way down but does not power down the box like it always has before. Same when shutting down via the GUI shutdown dialog. I can offer up machine details should anyone want them. 2. Trying to recompile the official Cisco VPN client after the reboot and it fails with this info:
# make make -C /lib/modules/2.6.18-92.1.1.el5/build SUBDIRS=/home/fredex/myfiles/programs/cisco-vpn-client/vpnclient modules make[1]: Entering directory `/usr/src/kernels/2.6.18-92.1.1.el5-i686' CC [M] /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/linuxcniapi.o CC [M] /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/frag.o CC [M] /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/IPSecDrvOS_linux.o CC [M] /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/interceptor.o CC [M] /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/linuxkernelapi.o LD [M] /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/cisco_ipsec.o Building modules, stage 2. MODPOST WARNING: /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/cisco_ipsec.o - Section mismatch: reference to .init.text: from .data between 'interceptor_dev' (at offset 0xb4) and 'interceptor_notifier' WARNING: could not find /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/.libdriver.so.cmd for /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/libdriver.so CC /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/cisco_ipsec.mod.o LD [M] /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/cisco_ipsec.ko make[1]: Leaving directory `/usr/src/kernels/2.6.18-92.1.1.el5-i686'
this ".libdriver.so.cmd" looks like something that should be created on the fly.
I've built this same version for several previous Centos kernels, so this appears to be a new phenomenon.
Clues would be appreciated.
Thanks in advance.
fred smith wrote:
Hello.
- "shutdown -h now" goes all the way down but does not power down the
box like it always has before. Same when shutting down via the GUI shutdown dialog.
I know this from systems with older processors. For me a 'apm=power-off' in the /etc/grub.conf kernel-line does the trick.
regards Olaf
On Wed, Jun 25, 2008 at 03:46:53PM +0200, Olaf Mueller wrote:
fred smith wrote:
Hello.
- "shutdown -h now" goes all the way down but does not power down the
box like it always has before. Same when shutting down via the GUI shutdown dialog.
I know this from systems with older processors. For me a 'apm=power-off' in the /etc/grub.conf kernel-line does the trick.
would your "older" include an Athlon XP 2600+ ?
Thanks, I'll give that a try.
fred smith wrote:
On Wed, Jun 25, 2008 at 03:46:53PM +0200, Olaf Mueller wrote:
fred smith wrote:
- "shutdown -h now" goes all the way down but does not power down
the box like it always has before. Same when shutting down via the GUI shutdown dialog.
I know this from systems with older processors. For me a 'apm=power-off' in the /etc/grub.conf kernel-line does the trick.
would your "older" include an Athlon XP 2600+ ?
No, of course not. My older processors are pII, pIII and athlon, from 266MHz to 800MHz.
regards Olaf
On Wed, Jun 25, 2008 at 07:27:38PM +0200, Olaf Mueller wrote:
fred smith wrote:
On Wed, Jun 25, 2008 at 03:46:53PM +0200, Olaf Mueller wrote:
fred smith wrote:
- "shutdown -h now" goes all the way down but does not power down
the box like it always has before. Same when shutting down via the GUI shutdown dialog.
I know this from systems with older processors. For me a 'apm=power-off' in the /etc/grub.conf kernel-line does the trick.
would your "older" include an Athlon XP 2600+ ?
No, of course not. My older processors are pII, pIII and athlon, from 266MHz to 800MHz.
OK. I didn't really mean "the ones you own", I meant more like "would you consider that Athlon to in the category of"...
Olaf Mueller wrote:
fred smith wrote:
On Wed, Jun 25, 2008 at 03:46:53PM +0200, Olaf Mueller wrote:
fred smith wrote:
- "shutdown -h now" goes all the way down but does not power down
the box like it always has before. Same when shutting down via the GUI shutdown dialog.
I know this from systems with older processors. For me a 'apm=power-off' in the /etc/grub.conf kernel-line does the trick.
would your "older" include an Athlon XP 2600+ ?
No, of course not. My older processors are pII, pIII and athlon, from 266MHz to 800MHz.
regards Olaf
As an added data point, since the OP seems concerned about Athlon XP2600+, I am running that processor in an ASUS A7N8X2.0 Deluxe m/b ACPI BIOS Rev 1008 and it powered down just fine following the CentOS 5.2 upgrade. Here's the first stanza of grub.conf: #boot=/dev/hda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.18-92.1.1.el5) root (hd0,0) kernel /vmlinuz-2.6.18-92.1.1.el5 ro root=LABEL=/ initrd /initrd-2.6.18-92.1.1.el5.img
On Wed, Jun 25, 2008 at 12:47:10PM -0500, Robert wrote:
Olaf Mueller wrote:
fred smith wrote:
On Wed, Jun 25, 2008 at 03:46:53PM +0200, Olaf Mueller wrote:
fred smith wrote:
- "shutdown -h now" goes all the way down but does not power down
the box like it always has before. Same when shutting down via the GUI shutdown dialog.
I know this from systems with older processors. For me a 'apm=power-off' in the /etc/grub.conf kernel-line does the trick.
would your "older" include an Athlon XP 2600+ ?
No, of course not. My older processors are pII, pIII and athlon, from 266MHz to 800MHz.
regards Olaf
As an added data point, since the OP seems concerned about Athlon XP2600+, I am running that processor in an ASUS A7N8X2.0 Deluxe m/b ACPI BIOS Rev 1008 and it powered down just fine following the CentOS 5.2 upgrade. Here's the first stanza of grub.conf: #boot=/dev/hda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.18-92.1.1.el5) root (hd0,0) kernel /vmlinuz-2.6.18-92.1.1.el5 ro root=LABEL=/ initrd /initrd-2.6.18-92.1.1.el5.img
and here's mine (including Olaf's suggested change):
#boot=/dev/hda default=0 timeout=5 splashimage=(hd0,2)/grub/splash.xpm.gz #hiddenmenu title CentOS (2.6.18-92.1.1.el5) root (hd0,2) kernel /vmlinuz-2.6.18-92.1.1.el5 ro root=LABEL=/ quiet apm=power-off initrd /initrd-2.6.18-92.1.1.el5.img
I have to say that adding the apm=power-off didn't change a thing, it still doesn't shut off the power. Now, I can't say with certainty when I last saw it do that, because i rarely shut down the box. It runs my mail server for the household, so it runs for months at a time, but I know that it has in the past always worked whenever I've watched it go down.
I just booted the prevous kernel and noticed that it doesn't power off either. Strange. I know it used to work (I've been using Centos, and formerly Tao Linux on this board since it was new.)
This is a gigabyte GA-7N400 Pro2 board, nvidia chipset, nvidia graphics card (old GeForce 4).
Any other advice you can come up with (while I go do some googling) would be appreciated.
On Wednesday 25 June 2008 19:02:28 fred smith wrote:
On Wed, Jun 25, 2008 at 12:47:10PM -0500, Robert wrote:
Olaf Mueller wrote:
fred smith wrote:
On Wed, Jun 25, 2008 at 03:46:53PM +0200, Olaf Mueller wrote:
fred smith wrote:
- "shutdown -h now" goes all the way down but does not power down
the box like it always has before. Same when shutting down via the GUI shutdown dialog.
I know this from systems with older processors. For me a 'apm=power-off' in the /etc/grub.conf kernel-line does the trick.
would your "older" include an Athlon XP 2600+ ?
No, of course not. My older processors are pII, pIII and athlon, from 266MHz to 800MHz.
regards Olaf
As an added data point, since the OP seems concerned about Athlon XP2600+, I am running that processor in an ASUS A7N8X2.0 Deluxe m/b ACPI BIOS Rev 1008 and it powered down just fine following the CentOS 5.2 upgrade. Here's the first stanza of grub.conf: #boot=/dev/hda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.18-92.1.1.el5) root (hd0,0) kernel /vmlinuz-2.6.18-92.1.1.el5 ro root=LABEL=/ initrd /initrd-2.6.18-92.1.1.el5.img
and here's mine (including Olaf's suggested change):
#boot=/dev/hda default=0 timeout=5 splashimage=(hd0,2)/grub/splash.xpm.gz #hiddenmenu title CentOS (2.6.18-92.1.1.el5) root (hd0,2) kernel /vmlinuz-2.6.18-92.1.1.el5 ro root=LABEL=/ quiet apm=power-off initrd /initrd-2.6.18-92.1.1.el5.img
I have to say that adding the apm=power-off didn't change a thing, it still doesn't shut off the power. Now, I can't say with certainty when I last saw it do that, because i rarely shut down the box. It runs my mail server for the household, so it runs for months at a time, but I know that it has in the past always worked whenever I've watched it go down.
I just booted the prevous kernel and noticed that it doesn't power off either. Strange. I know it used to work (I've been using Centos, and formerly Tao Linux on this board since it was new.)
This is a gigabyte GA-7N400 Pro2 board, nvidia chipset, nvidia graphics card (old GeForce 4).
Any other advice you can come up with (while I go do some googling) would be appreciated.
I have one of those mother boards with an 2.4 Athlon XP CPU, it had 5.1 on it, ( I was experimenting with software / hardware raid). Hope to find the time to put some more hard drives into it this weekend and put 5.2 on it and set it up as my central home file storage server. It never had a problem with shutting down with 5.1, I will report any problems / success after I have installed. It has had a few bios updates since I got it a few years ago. I also have an older AMD K6 550 MHz machine running Mandriva Linux and that had a problem shutting down with the latest version of Mandriva installed. John
On Wed, Jun 25, 2008 at 08:45:06AM -0400, fred smith wrote:
Hi Guys!
Thanks to the whole Centos team for all their hard work. You have no IDEA how much I appreciate it!
I ran "yum upgrade" last night, rebooted this morning and encountered a couple of small problems:
- "shutdown -h now" goes all the way down but does not power down the
box like it always has before. Same when shutting down via the GUI shutdown dialog. I can offer up machine details should anyone want them. 2. Trying to recompile the official Cisco VPN client after the reboot and it fails with this info:
# make make -C /lib/modules/2.6.18-92.1.1.el5/build SUBDIRS=/home/fredex/myfiles/programs/cisco-vpn-client/vpnclient modules make[1]: Entering directory `/usr/src/kernels/2.6.18-92.1.1.el5-i686' CC [M] /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/linuxcniapi.o CC [M] /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/frag.o CC [M] /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/IPSecDrvOS_linux.o CC [M] /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/interceptor.o CC [M] /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/linuxkernelapi.o LD [M] /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/cisco_ipsec.o Building modules, stage 2. MODPOST WARNING: /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/cisco_ipsec.o - Section mismatch: reference to .init.text: from .data between 'interceptor_dev' (at offset 0xb4) and 'interceptor_notifier' WARNING: could not find /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/.libdriver.so.cmd for /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/libdriver.so CC /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/cisco_ipsec.mod.o LD [M] /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/cisco_ipsec.ko make[1]: Leaving directory `/usr/src/kernels/2.6.18-92.1.1.el5-i686'
this ".libdriver.so.cmd" looks like something that should be created on the fly.
I've built this same version for several previous Centos kernels, so this appears to be a new phenomenon.
Clues would be appreciated.
Thanks in advance.
And a third item for the list: After just rebooting a few times trying various tactics for solving the first problem above (without success, BTW) when I booted it last time the GUI desktop comes up with empty panels. The panels are there, there's just nothing visible on them. I can click on the panel in the spot where something ought to be, and it is there--the menus open,or whatever was supposed to happen, and they have visible text--it's just the panels that are blank.
I should note that I'm using "desktop effects" with an old nvidia card, in case that matters.
On Wed, 2008-06-25 at 14:05 -0400, fred smith wrote:
<snip>
And a third item for the list: After just rebooting a few times trying various tactics for solving the first problem above (without success, BTW) when I booted it last time the GUI desktop comes up with empty panels. The panels are there, there's just nothing visible on them. I can click on the panel in the spot where something ought to be, and it is there--the menus open,or whatever was supposed to happen, and they have visible text--it's just the panels that are blank.
I should note that I'm using "desktop effects" with an old nvidia card, in case that matters.
I can't recall the start of this, did you {un,re}install the nvidia driver? I use the one from rpmforge. Other folks reported the need to un/reinstall to get it to work right. I saw these before I upgraded, did it and all is good.
Be aware: the *97*beta driver is for a later model nvidia and won't work on the *96* series. You'll probably want to use the nvidia-x11-drv-96xx-1.0.9631-1.nodist.rf.i386 from rpmforge if your card is fairly old.
<snip sig stuff>
HTH
On Wed, Jun 25, 2008 at 02:05:50PM -0400, fred smith wrote:
On Wed, Jun 25, 2008 at 08:45:06AM -0400, fred smith wrote:
Hi Guys!
Thanks to the whole Centos team for all their hard work. You have no IDEA how much I appreciate it!
I ran "yum upgrade" last night, rebooted this morning and encountered a couple of small problems:
- "shutdown -h now" goes all the way down but does not power down the
box like it always has before. Same when shutting down via the GUI shutdown dialog. I can offer up machine details should anyone want them. 2. Trying to recompile the official Cisco VPN client after the reboot and it fails with this info:
# make make -C /lib/modules/2.6.18-92.1.1.el5/build SUBDIRS=/home/fredex/myfiles/programs/cisco-vpn-client/vpnclient modules make[1]: Entering directory `/usr/src/kernels/2.6.18-92.1.1.el5-i686' CC [M] /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/linuxcniapi.o CC [M] /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/frag.o CC [M] /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/IPSecDrvOS_linux.o CC [M] /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/interceptor.o CC [M] /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/linuxkernelapi.o LD [M] /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/cisco_ipsec.o Building modules, stage 2. MODPOST WARNING: /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/cisco_ipsec.o - Section mismatch: reference to .init.text: from .data between 'interceptor_dev' (at offset 0xb4) and 'interceptor_notifier' WARNING: could not find /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/.libdriver.so.cmd for /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/libdriver.so CC /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/cisco_ipsec.mod.o LD [M] /home/fredex/myfiles/programs/cisco-vpn-client/vpnclient/cisco_ipsec.ko make[1]: Leaving directory `/usr/src/kernels/2.6.18-92.1.1.el5-i686'
this ".libdriver.so.cmd" looks like something that should be created on the fly.
I've built this same version for several previous Centos kernels, so this appears to be a new phenomenon.
Clues would be appreciated.
Thanks in advance.
And a third item for the list: After just rebooting a few times trying various tactics for solving the first problem above (without success, BTW) when I booted it last time the GUI desktop comes up with empty panels. The panels are there, there's just nothing visible on them. I can click on the panel in the spot where something ought to be, and it is there--the menus open,or whatever was supposed to happen, and they have visible text--it's just the panels that are blank.
I should note that I'm using "desktop effects" with an old nvidia card, in case that matters.
Well. actually, #3 was easy to solve: goto the desktop effects menu, click "enable desktop effects" and it DISables them. Strange. the panels now suddenly have text where they should. Click it again and it re-enables desktop effects and voila, the panels still have text where they should.
-
fred smith -
John Bowden -
Olaf Mueller -
Robert -
William L. Maltby