Kernel 2.6.37 is working very well, upgraded my 4 slackware machines with it and so far so good. I sustpect you might have rushed the process and skip/forgot some uimportant details.

Look at Eric's (AlienBob) page on how to install/upgrade a kernel in Slack.

http://alien.slackbook.org/dokuwiki/...kernelbuilding

This guide got me through several kernel rebuild/upgrades/troubleshooting...

very important, especially if you upgrade from an old kernel to a much newer version. On my 2.6.33.4 machines, there were about 40 to 50 new options I had to oversee. This got me through solving my sound over hdmi problem...

post back with comments on the procedure Eric documented.

I think I must be doing something wrong here. Last week I started working my way through this guide on a laptop running 13.1. When I logged back in this morning, X wouldn't start. Remembering the steps I took last week to get root to be able to run X commands from a 'su'-d terminal, I found that I had changed the owner/group on my .Xauthority file:

root@cli_box:~# xauth merge ~chexmix/.Xauthority
root@cli_box:~# export DISPLAY=:0.0
root@cli_box:~# ls -l ~chexmix/.Xauthority
-rw------- 1 root root 101 2011-04-11 10:28 /home/chexmix/.Xauthority

I couldn't get X to start until I changed the owner/group on the file back to chexmix:users

Thought this was kinda weird ...

The ownership of that file must have been changed before - it is not what happens on my Slackware 13.1 computer:

Eric

Hi Eric -

This is so weird. Ownership changes for me. I wonder what could be causing it:

I feel as though I am very close to learning something new, something along the lines of "I've been doing something stupid for years."*

Thanks,

Glenn

* This happens to me all too often. :S

Check out the settings for your root partition in /boot/initrd-tree/rootdev.
It should contain your root partition (/dev/hdc2).

My guess is that your $XAUTHORITY is still pointing at the users ~/.Xauthority file so that when you run xauth merge as root it is updating the users .Xauthority file rather than root's own ~/.Xauthority file.

If you have set root's $XAUTHORITY to point to the non root user's .Xauthority file you don't want to be running "xauth merge". It shouldn't be necessary as root can read the users file directly and as you are seeing, it will change ownership causing problems later.

Probably a stupid question from my part, but did you run depmod before mkinitrd:

# depmod 2.6.37.6

Not sure if I am answering the original poster, but if you have kde installed, a lot of the .Xauthority issues can be simply bypassed with the kdesu command.

When I upgrade my custom kernels, I usually copy .config from existing source tree to the new decompressed kernel. cd into the new kernel source, then run make 'old config', accepting defaults, but looking for anything interesting.

then I (as user, (not root) in runlevel 4) run 'kdesu make xconfig'. This way you get a nice graphical kernel config screen, where you make any changes you desire, (paying attention to those interesting bits)

Save, and then log out of X, (ie goto runlevel 3 - kernels build quicker here) and run the commands as per "Building your kernel" in Alien's guide.

If you are running 64bit, then you will need the kde3-compat packages from /extra installed.

The stuff relating to libata and lilo have already been covered.

tobyl

I tried the commands on another laptop running 13.1 & had the same thing happen ... don't know if it matters, but I am doing this in XFCE's Terminal.

Interestingly, I can run 'make xconfig' fine from such a terminal without doing 'xauth merge' or any of the other prep. So in a way it is moot, I guess, though I'm still not crystal clear on what is happening. Or not happening.

Thanks,

Glenn

Are you building as root? If so, I would caution you not to do so... and to build the custom kernel in your home directory. From Linux Kernel in a Nutshell, Ch. 1 (free book):