linux question

[coolzero]

When I start up my computer and go into linux it starts to boot up but then asks me this

Enter runlevel:


What the heck is that and what am I sposed to enter?

 

[Kai4Linux]

Distro? Run init tells linux to run at this level. 3 is to load into console. 5 is to load into gui. 6 is to shutdown. Its like saying im gonna give you this number, and your gonna do this if the number equals whatever. I forgot what 1, 2, and 4 do but anyway thats the jist of it.

 

[Nothinman]

enter 3 and see if it goes anywhere, but it sounds like your /etc/inittab is foobar'd.

 

[MGMorden]

Kai4Linux: Actually, what each runlevel does can vary from distro to distro. 3 might be console and 4 gui on one, and then it could be like you said on others (I'm pretty sure Redhat and Mandrake use the convention you specified, but it's been quite a while since I've used those).

 

[Kai4Linux]

Really wow? Yea i use Mandrake. Hmm what does debian / slack use?

 

[Nothinman]

The 'standard' is 3 for console, 1 for single user, 5 for X, 6 for reboot and 0 for halt

Debian uses 2 for everything, X is just a normal SysV init symlink in runlevel 2 if you have a display manager installed.
Slack uses BSD init so who knows.

 

[MGMorden]

Nothinman: The BSD init in Slack in no way effects the run level stuff. The difference between BSD init and SysV is different. Basically in BSD-style you have large init scripts that you setup in your rc.d directory (actually, I think real BSD uses a single monolithic startup script, but I know for fact that Slackware splits it up a bit). Some of these scripts are executed always and some are executed at certain runlevels (so like rc6.d would run at level 6 when the computer is shutting down. great place to add lines like a command to save the sound mixer settings. another line to load them from file again in rc.local and you get persistant settings ). SysV instead has a folder with scripts, and then another folder for each runlevel. You create symlinks in the runlevel folders (with special prefixes on the filenames) to the scripts that you want to run at that level. So they both end up using runlevels the same way in the end, just implemented differently (with Slackware/BSD being, IMHO, setup in an immensely superior way ).

That being said I think 3 is console in Slack and 4 GUI (hence why I used the example), but I'm not 100% positive on that. I would check but my Linux machine isn't hooked up right now (still haven't found a HomePNA networking card that works under Linux so I can't get online at home with that machine).

 

[Nothinman]

Nothinman: The BSD init in Slack in no way effects the run level stuff. The difference between BSD init and SysV is different. Basically in BSD-style you have large init scripts that you setup in your rc.d directory (actually, I think real BSD uses a single monolithic startup script, but I know for fact that Slackware splits it up a bit)

The BSDs I've used have had ~5 init scripts, IIRC. Slackware has an rc.d directory because every other Linux distro uses SysV init so they had to be compatible.

(with Slackware/BSD being, IMHO, setup in an immensely superior way

It's a lot easier for an install script/program to create a new script (or copy one from the distribution media) in /etc/init.d then create symlinks in /etc/rc?.d for it to start than it is to edit a text file successfully.

 

[coolzero]

wow ive been using linux for like a year i must still be noob cuz i have no idea wut u guys are talking about. but i tried entering numbers 1-10 and each time it said "No more processes left at this run level" then I have to restart.

Any ideas?

 

[Nothinman]

Try booting with 'init=/bin/sh' and poke around, I'm willing to bet you've got some filesystem fixing that needs to be done.

 

[coolzero]

I decided hell with it and went to reinstall linux all together, this time I'm getting some errors which would would make sense since the OS won't boot up.

When installing it says "Error installing packages....." I went through the entire installation just to see how many errors it would have...I lost count around 50. Does this seem like a cd software problem rather than a hardware problem?

 

[Kai4Linux]

Check ur cds, perhaps scratches? Try cleaning them.

 

[MGMorden]

It's a lot easier for an install script/program to create a new script (or copy one from the distribution media) in /etc/init.d then create symlinks in /etc/rc?.d for it to start than it is to edit a text file successfully.

It's not that hard to edit a text file so long as it follows a standard convention (I've written software that does it). It's especially easy if you just need to tack on extra stuff to the end of a file (which is about all you're going to be doing with the symlinked scripts anyways. the fact that they're independent scripts that execute seperately pretty much keeps them from interacting with each other in any meaningful way).

And the true beauty of BSD-init is that when that install program inevitably messes something up (can happen with either system), it's going to be more understandable and easy to fix with the BSD system .

 

[Nothinman]

It's not that hard to edit a text file so long as it follows a standard convention (I've written software that does it). It's especially easy if you just need to tack on extra stuff to the end of a file

It's not that hard, but string processing in C or C++ is bad, and most things on unix are done in C or C++. It's not impossible, but it's very easy to mess up, must easier to screw up than 'cp file dest; ln whatever wherever'. And you still have to read all the lines in the file and make sure there's not an entry already, otherwise you could end up starting the same daemon multiple times, with SysV you just see if the file exists in init.d, if so ask to overwrite it, check for the symlinks and make them if they're not there.

the fact that they're independent scripts that execute seperately pretty much keeps them from interacting with each other in any meaningful way).

What interaction is needed? This script starts this daemon, this one starts this one, etc. If one is required by another you use the numbers to make them start in order.

And the true beauty of BSD-init is that when that install program inevitably messes something up (can happen with either system), it's going to be more understandable and easy to fix with the BSD system

No, the beauty of the SysV init is that when the installer f's up the init scripts, I don't have to worry about it touching any of the other daemon's scripts. SysV init is extremely simple, I don't know why you think BSD is simpler...

 

[Sunner]

Originally posted by: Nothinman

It's not that hard to edit a text file so long as it follows a standard convention (I've written software that does it). It's especially easy if you just need to tack on extra stuff to the end of a file

It's not that hard, but string processing in C or C++ is bad, and most things on unix are done in C or C++. It's not impossible, but it's very easy to mess up, must easier to screw up than 'cp file dest; ln whatever wherever'. And you still have to read all the lines in the file and make sure there's not an entry already, otherwise you could end up starting the same daemon multiple times, with SysV you just see if the file exists in init.d, if so ask to overwrite it, check for the symlinks and make them if they're not there.

the fact that they're independent scripts that execute seperately pretty much keeps them from interacting with each other in any meaningful way).

What interaction is needed? This script starts this daemon, this one starts this one, etc. If one is required by another you use the numbers to make them start in order.

And the true beauty of BSD-init is that when that install program inevitably messes something up (can happen with either system), it's going to be more understandable and easy to fix with the BSD system

No, the beauty of the SysV init is that when the installer f's up the init scripts, I don't have to worry about it touching any of the other daemon's scripts. SysV init is extremely simple, I don't know why you think BSD is simpler...

I have to agree that SysV is far easier to deal with than BSD.
Another nice thing with having a bunch of scripts in /etc/init.d is that you can just restart a daemon by typing "foobar restart", or if it doesn't understand a restart arg, you can at least "foobar stop && foobar start".

Much nicer than having to HUP a process, since some programs don't always like getting HUP'ed.

 

[MGMorden]

What interaction is needed? This script starts this daemon, this one starts this one, etc. If one is required by another you use the numbers to make them start in order.

I didn't suggest that any interaction is needed. I merely stated that it's not there in either system. The lack of interaction (or the need of it) means that you don't exactly have to do brain surgery on the init file you're changing. Make sure your line isn't there and if it isn't add it. That's about as complicated as the modification needs to be (and if the installation program/script can't do that I'd doubt the quality of the software it's installing as well).

No, the beauty of the SysV init is that when the installer f's up the init scripts, I don't have to worry about it touching any of the other daemon's scripts. SysV init is extremely simple, I don't know why you think BSD is simpler...

I explained why I think BSD is simpler. If you don't agree then that's your choice. But the simple fact of the matter is that I can go in and fix a problem with Slackware's script system several orders of magnitiude faster than any of the SysV distros. Everything falls directly into place. Even if you don't agree, to me BSD works much, much better. I started with SysV. I used it for a long time. After using Slackware I've never found any of the SysV based distros (including but not limited to Debian) worth using.

 

[earthman]

What kind of Linux is this? Are you installing clean or over the old installation?

 

[Nothinman]

But the simple fact of the matter is that I can go in and fix a problem with Slackware's script system several orders of magnitiude faster than any of the SysV distros.

That's what I don't get. If say Samba isn't starting properly, you go and edit /etc/rc.inet (or whatever) and I go edit /etc/init.d/samba, where's the added simplicity? And on top of that, like Sunner pointed out, I can type '/etc/init.d/samba stop | start' to restart Samba if it doesn't restart on a SIGHUP.

After using Slackware I've never found any of the SysV based distros (including but not limited to Debian) worth using.

I'm sorry to hear that.

 

[MGMorden]

That's what I don't get. If say Samba isn't starting properly, you go and edit /etc/rc.inet (or whatever) and I go edit /etc/init.d/samba, where's the added simplicity? And on top of that, like Sunner pointed out, I can type '/etc/init.d/samba stop | start' to restart Samba if it doesn't restart on a SIGHUP.

But the difference is in what each of us sees when we open up those script files. SysV scripts take arguments (start/stop) and have all sorts of unnecessary scripting code strewn here and there (code that's not always documented well or sometimes even at all). Not all of them use the same interpreter either which adds to the complexity if you know some shell scripting languages but not others. In the Slackware/BSD-style scripts everything is more neatly laid out and organized. If something added after the fact is supposed to start at run time, it's virtually always started from rc.local (no digging for which script to edit. is it /etc/init.d/samba on this machine? or maybe /etc/init.d/samba-init? or /etc/init.d/smd-start?). Once you open up rc.local there's virtually always just a line starting up your program. if you can start it from the command line then you can fix it in a BSD script. And if I need to restart any daemon I just kill the process and restart from the command line (which is going to be the same way I load it in the rc.local file). If you like SysV that's great, but I like BSD and find it much simpler and easier to use (again, this is coming from someone who started using SysV first).

 

[Nothinman]

But the difference is in what each of us sees when we open up those script files. SysV scripts take arguments (start/stop) and have all sorts of unnecessary scripting code strewn here and there (code that's not always documented well or sometimes even at all). Not all of them use the same interpreter either which adds to the complexity if you know some shell scripting languages but not others.

Maybe it's Debian spoiling me but all of mine are simple (a few are complex, but not many) and easy to read and understand.