As the subject indicates, KDE is suddenly segfaulting when I run startx. Fluxbox will start. I'm using it now, but some programs won't run. xterm and aterm for example. I have root and two normal users and, oddly, the only user with this problem is mine, whose $HOME is a USB disk. The disk is formatted as ext2 so that permissions and links work properly. It's worked fine until now. I just installed kernel to 2.6.21.2 and, since I recently upgraded to 1GB RAM, I set highmem to 4GB in the new kernel. That's the only change from the previous kernel's config, so is that the cause? Or could the nVidia driver be incompatible with the new kernel? And if so why does it only affect the user who's $HOME is on USB?
I still have a 2.6.20.6 kernel I can boot into where everything's fine.

These are the error lines after the failed start.

startkde: Starting up...
/usr/bin/startkde: line xxx: xxxx Segmentation fault ksplash
/usr/bin/startkde: line xxx: xxxx Segmentation fault LD_BIND_NOW=true kdeinit+kcminit+knotify
startkde: Could not start kdeinit. Check your installation.
Warning: connect() failed: : No such file or directory
/usr/bin/startkde: line xxx: xxxx Segmentation fault kwraper kmserver $KDEWM

i would try changing the location of /home and see if that fixes it...

Since the 2.6.20 kernel is still working fine, and the 2.6.21 is the problem one (for the user on USB stick), I'd suggest that you run diff on the .config files for the two kernels. Look for the differences in config options, especially in the USB portion.

Then perhaps recompile the 2.6.21 to match 2.6.20?

Thanks for the suggestions, but it turns out to be a different issue than originally suspected. Moving $HOME didn't help and booting into another kernel produced the same problem. The user that does work has more administrative priveleges and is a member of the root group. I login to this user very rarely and only for administrative tasks. I'll probably remove it one day or restrict it to a normal user.

Iv'e found it to be a permissions problem. Somehow udev is assigning incorrect, and very restrictive, permissions. I have to chmod 666 /dev/null and /dev/nvidia0 just to get into X because they, and all tty and pty are receiving root:root ownership with 0660 permission. I can get into Fluxbox where I'm typing this but I can't open xterm because it can't get a pty. My udev rules files show correct rules and I haven't changed anything that would affect hardware detection. I tried shutting the computer completely off for a few minutes to clear the memory but it's still the same when it started.

EDIT: bigrigdriver, I always use the option for load alternate config in menuconfig. That way I know I'm starting with my current working config and this time the only thing I changed is highmem. My 2.6.20.6 had it off because I built it before upgrading to 1GB.

take a look at /etc/group you will see users assigned to certain groups...

the kdeadmin package has a good GUI frontend for adding users to certain groups...

I have looked at that file - closely. And I agree, KDE's user management app is easy to use. But I don't see any way that can help unless I add my user to the root group. That's why one user works and one doesn't. The mystery is why hardware permissions suddenly changed allowing only a root user to access ttys and such.

I think I got it fixed. I tried manually chmodding and chowning the /dev/null, /dev/nvidia* and /dev/pty. After that I still couldn't get into KDE or open an xterm from Fluxbox. I then upgraded udev to 111 from -current and rebooted and now it's behaving. I think the rules format may have changed because I saw some errors during startup, but my USB storage and wireless devices are working and everything in /dev has proper permissions. It'll have to stay working after another reboot or shutdown before I'm convinced, though.

Upgrading udev is the solution. I started my computer this morning and everything was still as it should be. I just finished applying the same fix on my laptop. Gee, when you know the fix you can actually do the whole thing without rebooting using '/etc/rc.d/rc.udev stop' and then 'etc/rc.d/rc.udev start'. The errors are nothing serious - pilotlink-0.2.12 installed a rules file that uses a group that I don't have called dialout. That's easy enough to change.