LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 01-23-2011, 07:57 PM   #16
lpallard
Senior Member
 
Registered: Nov 2008
Posts: 1,044

Rep: Reputation: Disabled

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...

Quote:
make oldconfig
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.
 
1 members found this post helpful.
Old 04-11-2011, 09:37 AM   #17
chexmix
Member
 
Registered: Apr 2002
Location: Arlington, MA
Distribution: Slackware, Debian, OpenBSD
Posts: 246
Blog Entries: 16

Rep: Reputation: 25
Quote:
Originally Posted by l
Look at Eric's (AlienBob) page on how to install/upgrade a kernel in Slack.

[url
http://alien.slackbook.org/dokuwiki/doku.php?id=linux:kernelbuilding[/url]
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 ...
 
Old 04-11-2011, 10:00 AM   #18
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 8,559

Rep: Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105
Quote:
Originally Posted by chexmix View Post
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:

Code:
alien@big:~$ ls -l .Xauthority 
-rw------- 1 alien users 795 2011-03-27 13:52 .Xauthority

....

root@big:~# xauth merge ~alien/.Xauthority 
root@big:~# ls -l ~alien/.Xauthority 
-rw------- 1 alien users 795 2011-03-27 13:52 /home/alien/.Xauthority
Eric
 
Old 04-11-2011, 11:24 AM   #19
chexmix
Member
 
Registered: Apr 2002
Location: Arlington, MA
Distribution: Slackware, Debian, OpenBSD
Posts: 246
Blog Entries: 16

Rep: Reputation: 25
Quote:
Originally Posted by Alien Bob View Post
The ownership of that file must have been changed before - it is not what happens on my Slackware 13.1 computer:

Code:
alien@big:~$ ls -l .Xauthority 
-rw------- 1 alien users 795 2011-03-27 13:52 .Xauthority

....

root@big:~# xauth merge ~alien/.Xauthority 
root@big:~# ls -l ~alien/.Xauthority 
-rw------- 1 alien users 795 2011-03-27 13:52 /home/alien/.Xauthority
Eric
Hi Eric -

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

Code:
root@cli_box:~# ls -l ~chexmix/.Xauthority 
-rw------- 1 chexmix users 101 2011-04-11 12:14 /home/chexmix/.Xauthority
root@cli_box:~# xauth merge ~chexmix/.Xauthority 
root@cli_box:~# ls -l !$
ls -l ~chexmix/.Xauthority
-rw------- 1 root root 101 2011-04-11 12:17 /home/chexmix/.Xauthority
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
 
Old 04-11-2011, 11:33 AM   #20
hua
Member
 
Registered: Oct 2006
Location: Slovak Republic
Distribution: Slackware 14.2, current
Posts: 461

Rep: Reputation: 78
Quote:
Originally Posted by SilverBack View Post
Well, gotten somewhere now. I am able to boot using the default kernel. However with 2.6.37 I still am stuck at not able to find the root file system. For the default kernel the root is at '/dev/hdc2'.
The strange thing here is when the kernel 2.6.37 boots up it tells me that it is not able to mount the root and the partition it shows me is hdc1 (swap) and hdc2 (/). As someone mentioned that the naming in the kernel 2.6.37 is different can someone give me hints to understand what is the partition that the kernel sees as the root if not hdc2?
Thanks a lot for helping me out here.
Check out the settings for your root partition in /boot/initrd-tree/rootdev.
It should contain your root partition (/dev/hdc2).

Last edited by hua; 04-11-2011 at 11:35 AM.
 
Old 04-11-2011, 11:36 AM   #21
GazL
LQ Veteran
 
Registered: May 2008
Posts: 6,882

Rep: Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988Reputation: 4988
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.

Last edited by GazL; 04-11-2011 at 11:38 AM.
 
Old 04-11-2011, 01:29 PM   #22
ChrisAbela
Member
 
Registered: Mar 2008
Location: Malta
Distribution: Slackware
Posts: 572

Rep: Reputation: 154Reputation: 154
Quote:
Am I missing something here?
Probably a stupid question from my part, but did you run depmod before mkinitrd:

# depmod 2.6.37.6
 
Old 04-11-2011, 05:14 PM   #23
tobyl
Member
 
Registered: Apr 2003
Location: uk
Distribution: slackware current
Posts: 768

Rep: Reputation: 64
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
 
Old 04-11-2011, 07:03 PM   #24
chexmix
Member
 
Registered: Apr 2002
Location: Arlington, MA
Distribution: Slackware, Debian, OpenBSD
Posts: 246
Blog Entries: 16

Rep: Reputation: 25
Quote:
Originally Posted by GazL View Post
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.
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
 
Old 04-11-2011, 09:00 PM   #25
hf2046
Member
 
Registered: Mar 2011
Distribution: Slack64
Posts: 111

Rep: Reputation: 20
Quote:
Originally Posted by chexmix View Post
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):
Quote:
This warning is the most important thing to remember while working through the
steps in this book. Everything in this book—downloading the kernel source code,
uncompressing it, configuring the kernel, and building it—should be done as a
normal user on the machine. Only the two or three commands it takes to install a
new kernel should be done as the superuser (root).

There have been bugs in the kernel build process in the past, causing some special
files in the /dev directory to be deleted if the user had superuser permissions while
building the Linux kernel.* There are also issues that can easily arise when uncom-
pressing the Linux kernel with superuser rights, as some of the files in the kernel
source package will not end up with the proper permissions and will cause build
errors later.

The kernel source code should also never be placed in the /usr/src/linux/ direc-
tory, as that is the location of the kernel that the system libraries were built
against, not your new custom kernel. Do not do any kernel development under
the /usr/src/ directory tree at all, but only in a local user directory where nothing
bad can happen to the system.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
A Long Day - Slackware-Current & 2.6.4 Installation Disaster SML Slackware 1 03-21-2004 05:23 AM
kernel disaster... teona Linux - Newbie 2 12-25-2003 07:31 PM
AHHH!!! kernel upgrade disaster! axion0917 Linux - General 35 12-11-2003 06:45 AM
Newbie Kernel re-compile disaster Neorio Linux - General 7 10-23-2003 02:52 AM
kERNEL DISASTER nelsonnery Linux - Newbie 1 10-09-2003 04:46 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 10:57 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration