[SOLVED] XORG Problem After Compiling Linux 2.6.35

CincinnatiKid · 08-04-2010, 10:11 PM

I am on my Debian system right now because of issues after compiling Linux 2.6.35, I followed Alien Bob's tutotorial, but obviously I missed something. I added 2.6.35 to my lilo.conf file, I tried to boot to it, but dhcp wasn't working, then I tried a startx and KDE would not load. No problem right, I will just boot my original Slackware Linux kernel.

I booted to the original, DHCP worked great but when I do a startx, I just get a black screen. Here is some of the terminal output.

Code:

No protocol specified

waiting for X server to begin accepting connections.

No protocol specified
..
No progocol specified
..

It's hard to get some of the output because I am looking at the other screen and typing this. Let me know what else you need to know to help me fix this and I will get it.

D1ver · 08-05-2010, 12:10 AM

Hello,
I don't know if this is related or not, but I'm a couple hours behind you in the same process.

Kernel 2.6.35 is compiling as per AlienBobs how-to, and i'm finding im unable to open any new processes. If I run okular from a terminal I had open before I started this process i get the message:

Quote:

No protocol specified
okular: cannot connect to X server :0.0

which resembles the line in AlienBobs how-to:

Quote:

echo $DISPLAY # you'll be needing this value 3 lines below
sudo -i # or "su -" on older Slackwares
xauth merge ~alien/.Xauthority # use your own username here instead of "alien"
export DISPLAY=:0.0 # use the value of DISPLAY you've seen 3 lines before

Maybe that has something to do with it?

EDIT:
Did a quick google and found this..

Quote:

xauth merge ~yourusername/.Xauthority

as root to give root access to the necessary keys. Both are kind of cheating, and you'll probably want to undo them (by using xhost - or removing /root/.Xauthority) when you're finished. Both methods are almost identical in what they let you do.

Again not sure if this is a fix or not, as im still compiling >:c Damn intel atom..

Daedra · 08-05-2010, 01:29 AM

did you use slackware's kernel .config file as a default or did you just start from a fresh kernel source?

D1ver · 08-05-2010, 07:37 AM

Ok my kernel finally finished compiling and I managed to boot again, and the exact same behavior you described began to happen.

Luckily google has all the answers, remove or rename the .Xauthority* files in your home directory and try startx again. It worked for me

CincinnatiKid · 08-05-2010, 08:00 AM

Quote:

did you use slackware's kernel .config file as a default or did you just start from a fresh kernel source?

I grabbed the configuration for my current kernel with

Code:

zcat /proc/config.gz > /usr/src/linux/.config

Quote:

Luckily google has all the answers, remove or rename the .xAuthority* files in your home directory and try startx again. It worked for me

I am at work right now but will try this as soon as I get home and let you know if it worked.

Bruce Hill · 08-05-2010, 09:30 AM

First, you don't compile kernels as root. There is a file called README
that is in the top level directory of all kernel source. Read it please.

Where does Linus Torvalds' README say to install new kernel source?

Code:

INSTALLING the kernel source:

 - If you install the full sources, put the kernel tarball in a
   directory where you have permissions (eg. your home directory) and
   unpack it:

                gzip -cd linux-2.6.XX.tar.gz | tar xvf -

   or
                bzip2 -dc linux-2.6.XX.tar.bz2 | tar xvf -


   Replace "XX" with the version number of the latest kernel.

   Do NOT use the /usr/src/linux area! This area has a (usually
   incomplete) set of kernel headers that are used by the library header
   files.  They should match the library, and not get messed up by
   whatever the kernel-du-jour happens to be.

Where does he say to build the kernel?

Code:

BUILD directory for the kernel:

   When compiling the kernel all output files will per default be
   stored together with the kernel source code.
   Using the option "make O=output/dir" allow you to specify an alternate
   place for the output files (including .config).
   Example:
     kernel source code:        /usr/src/linux-2.6.N
     build directory:           /home/name/build/kernel

   To configure and build the kernel use:
   cd /usr/src/linux-2.6.N
   make O=/home/name/build/kernel menuconfig
   make O=/home/name/build/kernel
   sudo make O=/home/name/build/kernel modules_install install

   Please note: If the 'O=output/dir' option is used then it must be
   used for all invocations of make.

When does he say you need to be root?

Code:

COMPILING the kernel:

 - Make sure you have at least gcc 3.2 available.
   For more information, refer to Documentation/Changes.

   Please note that you can still run a.out user programs with this kernel.

 - Do a "make" to create a compressed kernel image. It is also
   possible to do "make install" if you have lilo installed to suit the
   kernel makefiles, but you may want to check your particular lilo setup first.

   To do the actual install you have to be root, but none of the normal
   build should require that. Don't take the name of root in vain.

You do not need to be root until after you run make. Just for "make modules_install"
and to copy the images to /boot/ and edit /etc/lilo.conf and run "lilo".

There is no good reason to build a kernel as root, nor is there any need
to use /usr/src to build your kernel. You don't need root privileges until it is
time to install the kernel. And even then he suggests sudo ...

You guys are new at trying to build a custom kernel. Are you even building one?
If you just take the distro .config and use it to build a new kernel, that's not
really building a custom kernel. If you use it to start, then go through and take
out all the modules that have nothing to do with your hardware, and leave out the
modules that you will never use. Then you're starting to build a custom one.

Do you have a good reason for using 2.6.35? There are some really nice features
in it, but do you really understand them?

When you first start learning to build a custom kernel, you need to spend a lot
of time reading the HELP for the options that are available. This 2.6.35 kernel
has a LOT of new features. Your time might be better spent reading something like
the release notes from Linus and the article on Kernel Newbies.

If you build the way Linus instructs, then you can spend hours, or even days,
reading and configuring your kernel as a normal user ... not as root; and
most especially not running X as root.

It's not my intention to step on anyone's toes, but you guys would never have
had this problem had you just followed the instructions that come with the
kernel source, and not setup root to run X like that.

CincinnatiKid · 08-05-2010, 11:39 AM

Quote:

Do you have a good reason for using 2.6.35?

The main reason I am installing 2.6.35 is not to take advantage of a lot of the features, but more because of this bug: http://bugs.winehq.org/show_bug.cgi?id=23713.

The reason I am using /usr/src to compile the kernel is because that is what the majority of the Slackware community is telling me to do. I read that Linus says not to do this, but seeing as how I don't have a line of communication with Linus to ask questions, I figured I would follow what most of the Slackware community was telling me.

Quote:

If you build the way Linus instructs, then you can spend hours, or even days,
reading and configuring your kernel as a normal user ... not as root; and
most especially not running X as root.

Also, I never ran X as root, I'm not sure where you got this from? I used

Code:

make menuconfig

to configure my kernel.

GazL · 08-05-2010, 12:14 PM

That icebp/SIGTRAP bugfix also looks to be included in 33.7 and 34.2. No need to go up to .35 unless you want to for other reasons.

AlleyTrotter · 08-05-2010, 12:18 PM

LewisForLife
in your first post your systems boots but no net?

form the command line do
"""
su
password
dhcpcd
/etc/rc.d/rc.httpd restart
exit
"""
i had the same problem its seems the dhcpcd command durring boot is running too early

thanks
john

PS if you are using Nvidia driver it must always be reinstalled after a kernel upgrade

CincinnatiKid · 08-05-2010, 01:31 PM

Quote:

That icebp/SIGTRAP bugfix also looks to be included in 33.7 and 34.2. No need to go up to .35 unless you want to for other reasons.

I will keep this in mind, maybe I will compile one of the kerenels that you mentioned once I get my issue worked out.

Quote:

i had the same problem its seems the dhcpcd command durring boot is running too early

Wow that seems like a really big bug. I will try that.

Quote:

PS if you are using Nvidia driver it must always be reinstalled after a kernel upgrade

I have an Intel integrated video card:

Code:

00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03)

Do you think I will have to reinstall it?

AlleyTrotter · 08-05-2010, 02:38 PM

LewisForLife
I don't think a reinstall is required

So I would not have to do it at every reboot, I just put the commands in my rc.local file and now they run automagically One of the Guru's will figure it out and I will get the elegant fix then
But mine works for now

thanks
john

CincinnatiKid · 08-05-2010, 05:37 PM

Deleting ~/Xauth* fixed my X issues. Granted I don't have any other issues, I will mark this thread as solved, I will give it a little bit though.

D1ver · 08-05-2010, 07:01 PM

@Bruce Hill-
Thank you for your advice. It was my first time through compiling a kernel and I think i managed to learn a fair bit. Myself and lewis were following a guide from AlienBob found here AlienBob-wiki. The reasons for compiling as root and in /usr/src are outlined there.

I agree with you that we haven't really made a 'custom' kernel, but the main reasons for me undertaking this was probably 50% boredom and 50% curiosity, so using the config options from the current kernel which I know to work seemed like a good idea. Next time through I'll have a go at customising the options alot more.

Regards

GrapefruiTgirl · 08-05-2010, 07:41 PM

Quote:

Originally Posted by AlleyTrotter

LewisForLife
in your first post your systems boots but no net?

form the command line do
"""
su
password
dhcpcd
/etc/rc.d/rc.httpd restart
exit
"""

Maybe it doesn't matter now to the OP (OP's problem solved, yes?), but for the benefit of others who might come across this thread, please clarify: what in the world does rc.httpd have to do with "no net" or with anything written in the first post?

OP had no video (no X). But even if he'd had "no net", restarting rc.httpd would not have helped -- that's for the Apache web server

Cheers

Bruce Hill · 08-05-2010, 09:20 PM

Quote:

Originally Posted by lewisforlife

The reason I am using /usr/src to compile the kernel is because that is what the majority of the Slackware community is telling me to do. I read that Linus says not to do this, but seeing as how I don't have a line of communication with Linus to ask questions, I figured I would follow what most of the Slackware community was telling me.

Where you build your kernel would not be an issue if you understood what
you were doing. Since you don't yet, building where your normal user has
permissions would be much better, and safer, for you.

How many members of "the Slackware community" told you this? It was more
than likely not a majority. Since when did "the Slackware community"
come to know more about the Linux kernel than Linus Torvalds?

You did have "a line of communication with Linus" -- you got the source
that he posted to the internet, with his instructions inside. It was not
provided by "the Slackware community".

If "most of the Slackware community" tells you to jump in a fire are you
going to do it? (flashbacks from Dad when I was a boy)

Quote:

Originally Posted by lewisforlife

Also, I never ran X as root, I'm not sure where you got this from? I used

Code:

make menuconfig

to configure my kernel.

I got this from reading your posts in the thread, from understanding what
happens when you get the errors you posted, and from referencing the guide
you said you followed:

Quote:

Alien Bob's tutotorial

which states:

Quote:

to let root use my X display

Maybe he neglected to say in his guide:

Quote:

you'll probably want to undo them (by using xhost - or removing /root/.Xauthority) when you're finished.

as D1ver found using Google.

When you give root permissions to use your X display, and you're logged in
to that terminal as root, what's the difference? You might as well login to
Linux as root and you would not have had the problems with /root/.Xauthority
that brought you here for help.

The choice you use to configure your kernel has nothing to do with whether
or not you are running X as root. As stated before, you do not need to be
root to build the kernel ... nor to run "make menuconfig"

Look at this output:

Code:

mingdao@silas64:~$ sudo -i
root@silas64:~# cd ~mingdao/kernel/linux-2.6.34.1/
root@silas64:/home/mingdao/kernel/linux-2.6.34.1# make menuconfig
scripts/kconfig/mconf arch/x86/Kconfig


*** End of Linux kernel configuration.
*** Execute 'make' to build the kernel or try 'make help'.

root@silas64:/home/mingdao/kernel/linux-2.6.34.1# make xconfig
scripts/kconfig/qconf arch/x86/Kconfig
qconf: cannot connect to X server 
make[1]: *** [xconfig] Error 1
make: *** [xconfig] Error 2
root@silas64:/home/mingdao/kernel/linux-2.6.34.1#

The purpose of giving root permission to use the X display was
to run "xconfig" ... not "menuconfig" ... so you didn't need to do
this in the first place.

The internet is a big place. Anyone who wants to can build a web page,
and/or post a kernel build guide (or anything else). They're a dime a
dozen, but the instructions are included with the kernel source. Using
your logic: "I figured I would follow what most of the Slackware community
was telling me" ... you might as well ask the Debian or Ubuntu community how
to configure Slackware.

We're trying to help you, since it's obvious you still don't understand what
you did that caused your problem. Basically, you changed the cookies for root
associated with the X server to the normal user's cookie.