We should have updated rpms in the -test tree shortly, and then if no problems
are reported they'll be moved to the standard tree.
Thanks,
Chris
Thomas Kofler wrote:
Hi,
we noticed, that after running "yum update" yesterday on our system, that cman
didn't start up any longer.
We investigated the problem and it depends on the kernel version, if we boot
with the old 1447 - kernel, cman and the related services startup fine.
The newest GFS-kernel places the modules under /lib/modules/2.6.12-1.1447_FC4
But the kernel itself kernel-2.6.13-1.1526_FC4 has of
course /lib/modules/2.6.13-1.1526_FC4 as its module path.
Is it a bug or is there to do something by hand? If not, I would open a bug on
bugzilla, but under which section: kernel or GFS-kernel - which package team
forget the dependency ?
Thanks for feedback,
Thomas
kernel-2.6.13-1.1526_FC4
modules: /lib/modules/2.6.13-1.1526_FC4
GFS-kernel-2.6.11.8-20050601.152643.FC4.14
/lib/modules/2.6.12-1.1447_FC4/kernel/fs/gfs
/lib/modules/2.6.12-1.1447_FC4/kernel/fs/gfs/gfs.ko
/lib/modules/2.6.12-1.1447_FC4/kernel/fs/gfs_locking
/lib/modules/2.6.12-1.1447_FC4/kernel/fs/gfs_locking/lock_dlm
/lib/modules/2.6.12-1.1447_FC4/kernel/fs/gfs_locking/lock_dlm/lock_dlm.ko
/lib/modules/2.6.12-1.1447_FC4/kernel/fs/gfs_locking/lock_gulm
/lib/modules/2.6.12-1.1447_FC4/kernel/fs/gfs_locking/lock_gulm/lock_gulm.ko
/lib/modules/2.6.12-1.1447_FC4/kernel/fs/gfs_locking/lock_harness
/lib/modules/2.6.12-
1.1447_FC4/kernel/fs/gfs_locking/lock_harness/lock_harness.ko
/lib/modules/2.6.12-1.1447_FC4/kernel/fs/gfs_locking/lock_nolock
/lib/modules/2.6.12-1.1447_FC4/kernel/fs/gfs_locking/lock_nolock/lock_nolock.ko
--
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
--
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
