Bruce, I appreciate your help but the witch trial is a little much. I am just trying to learn here. I wanted the kernel upgrade to fix my bug like I said. I obviously realize that Linus Torvalds is the man when it comes to the Linux kernel. I will heed his words more carefully next time.

Please don't flame me for this question I am about to ask, I am just trying to learn. I know normally you don't compile things as root, but just out of curiosity, what can it hurt? Installing is the only thing that can hurt anything right, not the building? Is it because compiling can take a long time, and if you leave your computer you will still be logged into root and that is not good because someone can sit at your computer and mess things up, or are there other reasons?

I read you post and I read all the feed back there is a small bit of info you forgot to give us.
the only reasons why you are have this problem is because of run level 4. Ok yell ate me.
I built the kerenl I created the generic kernel it all works great. the xorg could care less what kernel is running I run slackware and it is vanilla . debian has different run levels deal with it. Just tell me your display card name.
That said and done debian has their own scripts why not use them. so after a quick read of http://www.howtoforge.com/kernel_com...on_debian_etch
you realize this. The true out put is not vanilla. the xorg is looking at your scripts what display card.
do you realize debian has there own way of building things.
xorg is looking for the module.I live in root and I back up.
Hard to believe that the simple program after a restart did not delete the /tmp//.Xauthority there is a bunch of reasons.
as long as root is running you will never get root to run.
come on this is what I learned from the people . why is it running the info not given was kill terminal running a Gui did not kill the /.Xauthority only root can do that. delete it in the /tmp it is a sticky situation. you have authority in /tmp
but you cant run X because root is still running and the scripts unable to delete it at boot. remove /tmp/.X0-lock
next time exit a program do not just close the terminal that is running it
the call for run level three is a hint what card are you running.?
if you are runing slackware think vanila and install slackware.
bruce I have read your stuff keep up the good work have more than one system BACK UP

The reason for not running as root is primarily because as root you
have full permissions to all commands and can harm your system. If
you are building a kernel, for instance, you need to be spending a
good bit of time reading, making choices, using Google to find out
what that little bit of <HELP> means, ect. The longer you are logged
in as root, the more chances you have to enter a command wrong and
mess up your system.

Also, yes, someone that gets into your system physically from the
keyboard, or via ssh or another means, can damage your system.

The main advantage that Linux has over Windows is that it is a true
multi-user system, and you don't need to be super user (root) to do
normal, everyday tasks. "Don't take the name of root in vain," as was
quoted from Linus Torvalds, means to respect the powers of root as the
super user and don't "su to root" unless you must have root privileges.
Sort of like driving your car without seat belts. Sure, you can do it,
and maybe if you don't hit something you don't fly out of the car. But
only a dummy drives without seat belts ... even crash test dummies
use them.

You can search LQ alone, much less Google, for posts where some guy
hosed his system because he issued a command while logged in as root,
that would not have hurt anything had he been a normal user at the time.

Wasn't flaming you before, and it's no witch trial. It's just plain wrong to
compile your kernel as root and for years I've held my tongue about it ...

Bruce, thanks for your help. I learned a lot, I have been doing a lot of reading also. I will take a lot of care next time I compile a kernel. It seems that Slackbuilds may have a serious flaw since you have to be root during the compilation process, but maybe sudo is the answer there. Thread solved!

GrapefruiTgirl
i added
/etc/rc.d/rc.httpd restart

for me the startup of my webserver comes right after dhcpcd times out
so I put it in rc.local right after dhcpcd starts

I think we have meet somewhere

thanks
john

Thanks AlleyTrotter for that clarification.

@ LewisForLife -- just for the record, as an example of what Bruce is writing, about how you can bork your system when compiling/building your kernel as root, is because, as mentioned, you have full permissions to run any command on your machine.
Take for example the `rm` command -- "remove files/folders". If you run `rm` recklessly as root, you can 'accidentally' delete root-owned system parts/files and really mess things up. The process of running make-clean, configure, make, make-install for your kernel, does use the `rm` command, and if let's say there was a typo somewhere inside the kernel build scripts, and an `rm` command was used with a wrong path... Oops! Just rm'd a bunch of stuff somewhere that had nothing to do with the kernel! If you had not been root, nothing important to the system would have been harmed.

Some time ago (a few months, a year maybe) there was such a bug in the kernel. I don't remember the details now, but a typo was causing stuff to get frigged up. So, the idea is just to be as safe as possible.

Semi-off-topic: Bruce, any chance that README documentation Linus puts into the kernel, has been updated recently? I haven't read it lately, but some while ago when I did read it, it was quite dated.

Cheers all!

@ GrapefruiTgirl

What you explained makes perfect since. I didn't think about the possibly harmful commands that can be in a Makefile. A malicious user could post a program and put 'rm -rf /' in the Makefile and user's running as root would be in a world of hurt.

So, should I stay away from Slackbuilds or is that just being way too paranoid? Or I guess I can just check them out for intentional or unintentional suspicious looking stuff every time.

It's possible, yes. BUT: it is not likely, if you download from reputable sources (such as SBo), AND you always make use of checksums and GPG signatures when they are available. The kernel archives are always GPG protected against tampering.

Don't trust software you just downloaded from some crazy place on the net, and it has no digital signatures and nobody has ever heard of it, unless you have the abilities to examine and understand exactly what-all the sourcecode does, before choosing to build/use/install it.
SBo is reputable. They do not host the sourcecode for packages anyway -- they only provide the link to where the sourcecode is actually hosted, usually a developer site, or sourceforge etc., and SBo gives md5 checksums for you to verify the packages. The rest of the stuff hosted on SBo is text files, SlackBuild files, etc., so you can easily examine that stuff if you're paranoid about it.

If I write my own SlackBuilds I always build as a regular user first and look for any permission denied or similar errors, and if I see any then I would have to investigate, since it would seem that it is trying to access my root filesystem. For example, if you try to build gtk+2, you will end up missing files when not built as root because of a less than ideal Makefile. I encountered this when trying to upgrade gtk+2 a while ago. In Pat's SlackBuild:
Technically most software can be built as a non-root user, but you would probably have to adjust permissions and certainly ownership as root before packaging it up (or else it will change ownership/permissions of key directories in your root filesystem upon package installation -- usually /usr/bin, /usr/lib, /etc, etc.). And there are some applications that need access to applications that only root would have access to (see the ffmpeg SlackBuild) for proper compilation. I trust the SlackBuilds at slackbuilds.org (and of course Robby's and Eric's SlackBuilds), but apart from that I usually run any SlackBuilds (either self-written or acquired from elsewhere) as a regular user first and then as root after I know it won't pollute my root filesystem.

When I compiled custom kernels it was as a regular user (and only used root for `make modules_install` and for copying the kernel and related files over to /boot). However, following Alien Bob's guide certainly isn't going to bring your computer to a grinding halt, though I myself prefer building as a regular user.

as Usual GrapefruiTgirl you bring a sober thought to this digital kingdom. As Usual I have to be at the core. and that means low low level. that said su enter password make install.
I am on my Knees looking up at the digital god that fights the time vampire.
back up look low and install as root . RM will happen.
Make it work for you.