Is it possible that the kernel in the centosplus repo is not up to date ?
The centosplus kernel I have is kernel-PAE-2.6.18-238.5.1.el5 and the regular one is 2.6.18-238.9.1.el5...
I need the plus because of the firewire drivers.
Regards,
On Sat, Apr 16, 2011 at 10:50 AM, Nicolas Ross rossnick-lists@cybercat.ca wrote:
Is it possible that the kernel in the centosplus repo is not up to date ?
The centosplus kernel I have is kernel-PAE-2.6.18-238.5.1.el5 and the regular one is 2.6.18-238.9.1.el5...
I need the plus because of the firewire drivers.
I *believe* it's been already built. But it needs to be released. Karanbir is away this weekend. Can other dev push it? Johnny? Tru?
Akemi
I *believe* it's been already built. But it needs to be released. Karanbir is away this weekend. Can other dev push it? Johnny? Tru?
Akemi
It's not that urgent, it's just that yum sees that the update from the regular repository, and I ended up with no external drive to my backup storage server and it took a while to figure it out...
Nicolas Ross wrote on 04/16/2011 02:25 PM:
It's not that urgent, it's just that yum sees that the update from the regular repository, and I ended up with no external drive to my backup storage server and it took a while to figure it out...
You might want to add an "exclude=kernel*" in [updates] to keep yum from sneaking up on you like that.
Phil
On 4/16/11 12:50 PM, Nicolas Ross wrote:
Is it possible that the kernel in the centosplus repo is not up to date ?
The centosplus kernel I have is kernel-PAE-2.6.18-238.5.1.el5 and the regular one is 2.6.18-238.9.1.el5...
I need the plus because of the firewire drivers.
I thought that firewire was finally backed into the stock RHEL kernel a few revs ago at least as a 'technology preview'. Maybe you have to do something to enable it. I used to use the centosplus kernel for that and reiserfs but haven't used those drives for a while.
On Sat, Apr 16, 2011 at 11:46 AM, Les Mikesell lesmikesell@gmail.com wrote:
On 4/16/11 12:50 PM, Nicolas Ross wrote:
Is it possible that the kernel in the centosplus repo is not up to date ?
The centosplus kernel I have is kernel-PAE-2.6.18-238.5.1.el5 and the regular one is 2.6.18-238.9.1.el5...
I need the plus because of the firewire drivers.
I thought that firewire was finally backed into the stock RHEL kernel a few revs ago at least as a 'technology preview'. Maybe you have to do something to enable it. I used to use the centosplus kernel for that and reiserfs but haven't used those drives for a while.
If it is the classic stack of firewire drivers that are required, and there is nothing else needed from the centosplus kernel, a good solution is to get the kABI-tracking firewire modules from ELRepo:
http://elrepo.org/tiki/tiki-index.php?page=kmod-ieee1394
It provides:
dv1394.ko eth1394.ko ieee1394.ko ohci1394.ko pcilynx.ko raw1394.ko sbp2.ko video1394.ko
Because they survive kernel updates transparently and you can run the distro kernel, there will be no "waiting" for each kernel update.
Akemi
If it is the classic stack of firewire drivers that are required, and there is nothing else needed from the centosplus kernel, a good solution is to get the kABI-tracking firewire modules from ELRepo:
http://elrepo.org/tiki/tiki-index.php?page=kmod-ieee1394
It provides:
dv1394.ko eth1394.ko ieee1394.ko ohci1394.ko pcilynx.ko raw1394.ko sbp2.ko video1394.ko
Because they survive kernel updates transparently and you can run the distro kernel, there will be no "waiting" for each kernel update.
That is indeed what I need, I use ieee1394, raw1394 and sbp2 to access my 2tb firewire external drive that is used for backup rotation.
I will try that on monday.
On 4/16/11 2:25 PM, Nicolas Ross wrote:
If it is the classic stack of firewire drivers that are required, and there is nothing else needed from the centosplus kernel, a good solution is to get the kABI-tracking firewire modules from ELRepo:
http://elrepo.org/tiki/tiki-index.php?page=kmod-ieee1394
It provides:
dv1394.ko eth1394.ko ieee1394.ko ohci1394.ko pcilynx.ko raw1394.ko sbp2.ko video1394.ko
Because they survive kernel updates transparently and you can run the distro kernel, there will be no "waiting" for each kernel update.
That is indeed what I need, I use ieee1394, raw1394 and sbp2 to access my 2tb firewire external drive that is used for backup rotation.
I will try that on monday.
Yum shouldn't have deleted your running kernel in the update. It should just be a matter of changing the default to boot in the grub config if you want to run the old one a while longer.
Because they survive kernel updates transparently and you can run the distro kernel, there will be no "waiting" for each kernel update.
That is indeed what I need, I use ieee1394, raw1394 and sbp2 to access my 2tb firewire external drive that is used for backup rotation.
I will try that on monday.
Yum shouldn't have deleted your running kernel in the update. It should just be a matter of changing the default to boot in the grub config if you want to run the old one a while longer.
No, it didn't, but on reboot, it booted the non-centosplus kernel, the one that was more upto date...
Regards,
On 4/16/11 6:37 PM, Nicolas Ross wrote:
Because they survive kernel updates transparently and you can run the distro kernel, there will be no "waiting" for each kernel update.
That is indeed what I need, I use ieee1394, raw1394 and sbp2 to access my 2tb firewire external drive that is used for backup rotation.
I will try that on monday.
Yum shouldn't have deleted your running kernel in the update. It should just be a matter of changing the default to boot in the grub config if you want to run the old one a while longer.
No, it didn't, but on reboot, it booted the non-centosplus kernel, the one that was more upto date...
It's not exactly because it is more up to date - the install process edits the new one in as the default in grub.conf. You can still interrupt the boot screen and pick the one you want, or edit grub.conf to make the older one the default.
At Sat, 16 Apr 2011 19:37:24 -0400 CentOS mailing list centos@centos.org wrote:
Because they survive kernel updates transparently and you can run the distro kernel, there will be no "waiting" for each kernel update.
That is indeed what I need, I use ieee1394, raw1394 and sbp2 to access my 2tb firewire external drive that is used for backup rotation.
I will try that on monday.
Yum shouldn't have deleted your running kernel in the update. It should just be a matter of changing the default to boot in the grub config if you want to run the old one a while longer.
No, it didn't, but on reboot, it booted the non-centosplus kernel, the one that was more upto date...
If you enable the kernel from the CentOSPlus repo, you should *disable* kernel updates from the standard repo, otherwise yum will get updates from *both* places. By disabling the kernel packages from being updated from the standard repos (os and updates), yum won't update to a non CentOSPlus kernel -- if the CentOSPlus has not been pushed to the CentOSPlus repo, you just won't get a new kernel at all. (Eventually when the CentOSPlus does get pushed, yum will pick it up.)
Regards,
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sat, Apr 16, 2011 at 6:08 PM, Robert Heller heller@deepsoft.com wrote:
If you enable the kernel from the CentOSPlus repo, you should *disable* kernel updates from the standard repo, otherwise yum will get updates from *both* places. By disabling the kernel packages from being updated from the standard repos (os and updates), yum won't update to a non CentOSPlus kernel -- if the CentOSPlus has not been pushed to the CentOSPlus repo, you just won't get a new kernel at all. (Eventually when the CentOSPlus does get pushed, yum will pick it up.)
This is best done by using the exclude= option as detailed in:
http://wiki.centos.org/AdditionalResources/Repositories/CentOSPlus
See Example 2.
Akemi
Dear All !
I am trying to figure out, why I get blank screen with a dead system after resume from suspend or hibernation. It seems, that on the way to suspend or hibernation now works fine in most cases, but when it awakes , everything freezes , no picture , dead-boy , both with kde and gnome too !
The system is running CentOS-5.6 Gnome/kde env on an IBM z61m laptop. Env: kernel:2.6.18-238.9.1.el5 kernel parameters: kernel /vmlinuz-2.6.18-238.9.1.el5 ro root=/dev/system/root rhgb quiet vga=0 nomodeset fglrx-2d: 8.5.x xorg.conf:
# Xorg configuration created by system-config-display
Section "ServerLayout" Identifier "single head configuration" Screen 0 "aticonfig-Screen[0]-0" 1024 0 Screen "amdcccle-Screen[1]-1" 0 0 InputDevice "Keyboard0" "CoreKeyboard" InputDevice "Synaptics" "CorePointer" EndSection
Section "Files" EndSection
Section "Module" EndSection
Section "ServerFlags" Option "Xinerama" "off" Option "Clone" "off" Option "DontZap" "true" Option "DontVTSwitch" "true" Option "AIGLX" "off" EndSection
Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "pc101" Option "XkbLayout" "hu" EndSection
Section "InputDevice" Identifier "Synaptics" Driver "synaptics" Option "Device" "/dev/input/mice" Option "Protocol" "auto-dev" Option "Emulate3Buttons" "yes" EndSection
Section "Monitor" Identifier "aticonfig-Monitor[0]-0" Option "VendorName" "ATI Proprietary Driver" Option "ModelName" "Generic Autodetecting Monitor" Option "DPMS" "true" EndSection
Section "Monitor" Identifier "amdcccle-Monitor[1]-1" Option "VendorName" "ATI Proprietary Driver" Option "ModelName" "Generic Autodetecting Monitor" Option "DPMS" "true" EndSection
Section "Device" Identifier "aticonfig-Device[0]-0" Driver "fglrx" Option "VBERestore" "true" Option "HWCursor" "on" Option "VideoOverlay" "on" Option "XAANoOffscreenPixmaps" "true" Option "UseInternalAGPGART" "no" BusID "PCI:1:0:0" EndSection
Section "Device" Identifier "amdcccle-Device[1]-1" Driver "fglrx" Option "VBERestore" "true" Option "HWCursor" "on" Option "VideoOverlay" "on" Option "XAANoOffscreenPixmaps" "true" Option "UseInternalAGPGART" "no" BusID "PCI:1:0:0" Screen 1appriciated EndSection
Section "Screen" Identifier "aticonfig-Screen[0]-0" Device "aticonfig-Device[0]-0" Monitor "aticonfig-Monitor[0]-0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection
Section "Screen" Identifier "amdcccle-Screen[1]-1" Device "amdcccle-Device[1]-1" Monitor "amdcccle-Monitor[1]-1" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection
Section "Extensions" Option "Composite" "on" EndSection
Section "ServerFlags" Option "DontZap" "true" Option "DontVTSwitch" "true"
Any help is appreciated! Thank you for your kind help in advance !
Kindest Regards Tamas Besenyei Hungary, Pilisborosjeno
On Sat, Apr 16, 2011 at 12:25 PM, Nicolas Ross rossnick-lists@cybercat.ca wrote:
http://elrepo.org/tiki/tiki-index.php?page=kmod-ieee1394
It provides:
dv1394.ko eth1394.ko ieee1394.ko ohci1394.ko pcilynx.ko raw1394.ko sbp2.ko video1394.ko
Because they survive kernel updates transparently and you can run the distro kernel, there will be no "waiting" for each kernel update.
That is indeed what I need, I use ieee1394, raw1394 and sbp2 to access my 2tb firewire external drive that is used for backup rotation.
I will try that on monday.
If you find issues or need further assistance with the kmod package, please try using the ELRepo mailing list ( http://lists.elrepo.org/mailman/listinfo/elrepo ).
Akemi
-
Akemi Yagi -
Besenyei Tamas -
Les Mikesell -
Nicolas Ross -
Phil Schaffner -
Robert Heller