[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Linux-cluster] Issue with KDE with kernel later than



Corey Kovacs wrote:
My mistake, I'd assumed (yes I know the implications of that word)
that this was on an NFS mount point. the rsize attribute only pertains
to NFS mounted filesystems

-C

2009/2/4 Randy Brown <randy brown noaa gov>:
I'm having trouble getting the file system to mount after adding the rsize
parameter.  Here is my fstab entry:

/dev/vgdevl/shared /fs/shared                    gfs     defaults        0 0

I changed it to:

/dev/vgdevl/shared /fs/shared                    gfs     defaults,rsize=8192
   0 0

and when I try to mount the file system I get:

[root nfs2-cluster etc]# mount /fs/shared
/sbin/mount.gfs: error mounting /dev/mapper/vgdevl-shared on /fs/shared:
Invalid argument

Looking though the man pages, it appears that the rsize switch should work.
 Any thoughts?

Thanks,

Randy

Randy Brown wrote:
Great.  Thanks.  I'll give that a shot.  I just need to find umount and
mount that file system to see if it worked.

Randy

Corey Kovacs wrote:
I had a similar problem. Reducing my rsize back to 8k from 32k fixed it.
Problem root was the lock files in the .qt directory.


Regards,

Corey

On Feb 4, 2009, at 16:00, Randy Brown <randy brown noaa gov> wrote:

We are seeing a very strange issue with KDE with all kernels later than
2.6.18-53.1.21 on our cluster nodes.  When users attempt to log into the
machine using KDE, it never makes it to the KDE splash screen.  The machine
just hangs on a solid blue screen.  I can then restart the Xserver and login
using Gnome, and it logs in without any issues.  Unfortunately, for us, KDE
is the standard desktop environment used by our development group.  I can
reboot the the cluster to the 2.6.18-53.1.21 kernel and both KDE and Gnome
work as expected.  Obviously, I'd prefer to be running the latest kernel.  I
will gladly provide more info if needed.  Any help or suggestions would be
greatly appreciated.

Randy

Info about our cluster:
It is a 2 node cluster running Centos 5 with up to date patches.  I am
using the cluster as a NAS head to serve NFS mounts out to our network from
an iscsi SAN.

Current running kernel:
2.6.18-53.1.21.el5  (Running this kernel so KDE logins work)

Most current installed kernel:
2.6.18-92.1.22.el5

Cluster packages:
lvm2-cluster-2.02.32-4.el5
cman-2.0.84-2.el5_2.3
gfs2-utils-0.1.44-1.el5_2.1
rgmanager-2.0.38-2.el5_2.1
<randy_brown.vcf>
--
Linux-cluster mailing list
Linux-cluster redhat com
https://www.redhat.com/mailman/listinfo/linux-cluster
--
Linux-cluster mailing list
Linux-cluster redhat com
https://www.redhat.com/mailman/listinfo/linux-cluster

--
Linux-cluster mailing list
Linux-cluster redhat com
https://www.redhat.com/mailman/listinfo/linux-cluster
--
Linux-cluster mailing list
Linux-cluster redhat com
https://www.redhat.com/mailman/listinfo/linux-cluster


--
Linux-cluster mailing list
Linux-cluster redhat com
https://www.redhat.com/mailman/listinfo/linux-cluster
Although your probably on the right track to the problem.

KDE has known problems with NFS, because NFS cannot guarantee that a lock is granted. KDE requires that locks will to be granted on a user's /home directory otherwise you will get exactly what you are experiencing (KDE only get's through 3 of the 5 steps during logon, then hangs at a blue screen).

Do a google search for "KDE on NFS" or something like that, and you'll see that it's a fairly common problem.

The KDE developers themselves state that you should never use KDE when your home directories are on NFS, but there are ways around it. Home directories on NFS is fairly common in large linux/unix deployments.

If your experiencing this problem when your user home directories sit on GFS I would investigate GFS locking first up. There's probably something there that KDE disagrees with.

Regards,

Stewart


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]