Custom Runlevels and Console Login

[GOfree]

Runlevel Customization – Adding a Console Login

I often read fellow newbies wondering about stopping the desktop manager and getting a console login. Maybe, like me, you have tried another distribution that does not come prepackaged with GNOME or KDE, and you think that booting to a text-based console login is pretty cool—old-school. You probably have found that login screens for these desktop suites, GDM and KDM, have a way of automatically starting whether you want them to or not. I have read comments by people saying that if you have GNOME installed, there is nothing you can do about GDM starting automatically, short of deinstallation. Not so! There is a way to get around this. It comes down to the structures known as “runlevels”.

Here is an introductory tutorial for newbies on managing runlevels and setting up a console login.

Read Available Documentation:

- If you don't know what runlevels are, you should read up on them (http://www.debianhelp.co.uk/runlevels.htm).
- Briefly, in Debian, there are seven standard runlevels (0-6), plus a transitional runlevel (S). At each runlevel, particular programs will be either started or stopped automatically. When you boot into Debian, your computer goes to the default runlevel 2, where all your normal start-up programs, like GDM, are started. When you shutdown your computer, it shifts through the transitional runlevel, to runlevel 0, where all applications and programs are stopped. Runlevel 6 is almost the same as Runlevel 0 (stopping all programs), except it finishes with a command to reboot. Runlevel 1 is the single-user trouble-shooting mode (which probably appears in your bootloader (“grub”) menu), where only a few basic programs are started. This leaves runlevels 3, 4, and 5 which are duplications of the default multi-user runlevel 2 and can safely be experimented on and customized to your taste.
- Here we will be using the utility program “update-rc.d”, so you should have a look at the manual page (“man update-rc.d”).
- When you edit a runlevel, you will be editting the names of symbolic links which control whether a program is started or stopped, and in which order. It is entirely possible to edit each link by hand. The update utility program makes it easier and helps ensure that all the runlevels are covered consistently.
- It also helps to have a good book on GNU/Linux. The one that I used was “Linux Cookbook” by Carla Schroder (http://oreilly.com/catalog/9780596006402/). This tutorial is largely adapted from Chapter 7 of “Linux Cookbook”.

Familiarize Yourself With Critical System Files:

- Take a look at the directory /etc. There you should find eight subdirectories that look like this “rc_.d”, so that you have rc0.d, rc1.d, rc2.d, rc3.d, rc4.d, rc5.d, rc6.d, and rcS.d. These are essentially the files that compise each of the seven standard runlevels (0-6), plus a transitional runlevel (S).
- Open one of these directories, and you will find a series of files with the names of programs (like “gdm”) prefixed by a letter (either “K” or “S”) and a two-digit number (“01” to “99”). For each of the programs, the prefixes tell the computer to either start (“S”) or kill (“K”) the program, and the number indicates the priority sequence of programs to be started or stopped. Programs of the same priority are started and stopped in alphabetical order.
- These files are not actually programs themselves. They are symbolic links to the programs that actually do the starting and stopping.
- Take a look at the directory “/etc/init.d”. There you will find the actual start/stop scripts for each to the programs in a runlevel. Try displaying one of these with a text editor, and you will see the actual code that controls whether a program is started or stopped.
- Finally, take a look at the file, “/etc/inittab”. This is the configuration file that specifies certain parameters about the runlevels themselves. Here we are interested in lines 4 and 5 that specify which runlevel will be the default runlevel—which runlevel will be automatically engaged when you start your computer. When we create a runlevel without a graphical display manager, we can make that runlevel the default and boot to a console login.

Get a Setup Baseline:

- First, before we go further, you may want to check what your computer's current runlevel is. If you type that command “runlevel” at the root console or as superuser (“sudo”), you should get output like this: “N 2”. There are two elements here. The second element, “2”, indicates the current runlevel (in this case, the default runlevel 2). The first element, “N”, indicates the previous runlevel (in this case, “N”, for no previous runlevel, because the computer booted directly to runlevel 2.)
- Before we edit a runlevel for text-based console login, it would be good to get a “before” snapshot of the runlevels as they are currently laid-out. Before we start editting the symbolic links that make up an “rc_.d” directory, let's first take note of all the links as they are.
- An easy way to get a picture of the runlevels is with the command, “ls /etc/rc0.d /etc/rc1.d /etc/rc2.d /etc/rc3.d /etc/rc4.d /etc/rc5.d /etc/rc6.d /etc/rcS.d > /home/<user>/orig-runlevels.txt”. This command instructs the computer to list all the files in the directories for all the runlevels (0, 1, 2, 3, 4, 5, 6, and S) and output them to a text file in the user's home directory called “orig-runlevels.txt”.
- Runlevels 0, 1, 6, and S should not be altered, so we want to make sure that they are not inadvertantly changed as we go along. Runlevel 3 will be the one we set up for console login, and should be exactly the same as runlevel 2 before we start. We will not touch runlevels 4 and 5, and they should remain the same as runlevel 2.
- If you have standard Debian runlevels, the output for runlevel 3 will look something like this:

/etc/rc3.d:
README
S05loadcpufreq
S05vbesave
S10rsyslog
S12acpid
S12dbus
S14avahi-daemon
S19cpufrequtils
S20apmd
S20cups
S20exim4
S20kerneloops
S20nfs-common
S20openbsd-inetd
S24dhcdbd
S24hal
S25bluetooth
S25pulseaudio
S26network-manager
S26network-manager-dispatcher
S30gdm
S30system-tools-backends
S89anacron
S89atd
S89cron
S90binfmt-support
S99acpi-support
S99rc.local
S99rmnologin
S99stop-bootlogd

- At this point, take a couple of minutes, scan over the runlevel lists, and note the similarities and differences between them—that is, note the different prefixes for the same program names at the various runlevels. In particular, look at the links to the gdm start/stop script. At the default multi-user runlevel (runlevel 2), “gdm” should have a prefix like “S30”, so that the gnome display manager is roughly the twentieth program started out of a list of some thirty programs. At runlevel 1, however, “gdm” has a prefix, “K01”, and is the first program to be stopped. In single-user mode, the display manager is not started in order to minimize system resources for trouble-shooting--a situation that is similar to what we want to configure for a runlevel 3 console login.

Editting Runlevels with the “update-rc.d” Utility:

- Here is what Carla Schroder wrote about using “update-rc.d” in “Linux Cookbook”: “Changing the runlevels for an existing service is a two-step process: first remove it, then add it back to the levels in which you want it to run. Be sure to make an entry for every service on every runlevel, either stop or start.” You may edit runlevel links by hand. Using the runlevel utility program helps ensure that there are entries for each program at every runlevel.
- In the two-step process of editting runlevels, first we will remove symbolic links for a display manager from all runlevels with the command, “update-rc.d -f gdm remove”. Next we need to replace the program at all the runlevels with the prefixes we want at each runlevel. Here the command will be, “update-rc.d gdm start 30 2 4 5 . stop 01 0 1 3 6 .”. This will tell the computer to start “gdm” with priority 30 at runlevels 2, 4, and 5, and to stop “gdm” first at runlevels 0, 1, 3, and 6. This should make all the runlevels the same they were when we started, except for two changes to runlevel 3: “gdm” should no longer start with priority 30 (as in runlevel 2), and should be stopped with priority 1 (as in runlevels 0, 1, and 6). (Note that there is a trailing period at the end of the command. The period has to be there for the command to work.)
- Before editting your runlevel configurations, you might want to see the “update-rc.d” utility in action without making any actual changes. If you previously read the manual page for “update-rc.d” (“man update-rc.d”) you may have noticed in the “Options” section, the option “-n” with the description, “Don’t do anything, just show what we would do.” Try running the removal command with the “-n” option (“update-rc.d -f -n gdm remove”), to see what the utility will do without making any actual changes. When you know what to expect, run the removal command for real, then go to the next step of adding “gdm” back to the runlevels.
- Once you have removed “gdm” links and returned them to the runlevels with the new prefix at runlevel 3, run the command to list your runlevels again (with a new output filename “new-runlevels”): “ ls /etc/rc0.d /etc/rc1.d /etc/rc2.d /etc/rc3.d /etc/rc4.d /etc/rc5.d /etc/rc6.d /etc/rcS.d > /home/<user>/new-runlevels.txt”.
- Look at the list of links at runlevel 3 and check to see that the link to the “gdm” start/stop script is there and has the right prefix, “K01”.
- Make sure that no other changes were made inadvertantly. Run the “diff” command on your two output files “orig-runlevels.txt” and “new-runlevels.txt” (from within your home directory, “diff orig-runlevels.txt new-runlevels.txt”) to see what changes have been made. The output should look something like this:

93a94
> K01gdm
114d114
< S30gdm

- This output indicates two changes made to runlevel 3: 1) an item was added at line 94, “K01gdm”--the symbolic link telling the computer to stop the display manager service, and 2) the symbolic link for starting “gdm” at line 114 was deleted. Use a text editor like the one that comes with gnome, “gedit”, to verify the line numbers and the changes that were made. If these are the only two changes that were made, then you have a runlevel configuration that is the same as when you started except that the GNOME display manager will not start at runlevel 3—giving you a console login instead.

Editing the Runlevel Configuration File:

- Soon you will be able to test the changes you have made. It is possible to manually shift between runlevels (as root, run “init x”, with x being the runlevel to which you want to shift (see the manual page, “man init”)), but it is apparently not a good idea to end a graphical “X” session in this way. Instead, let us edit the runlevel configuration file and reboot to the runlevel we want.
- As root or superuser (“sudo”), open the file “/etc/inittab” with a text editor (“gedit”, “nano”, “vi”, etc.) . Go to the line, “id:2:initdefault:” under the heading “# The default runlevel.”. If you edit this line to read “id:3:initdefault:” and reboot, you will enter Debian at the runlevel we just customized—the new console login. Even better, if you edit the default runlevel line to read “id:X:initdefault:”, when your computer boots up, it will ask you to select the runlevel where it will start.

Test the New Configuration and Finish-Up:

- With the default runlevel specified in “/etc/inittab” as either “3” or “X”, reboot your computer. If you specified “X”, wait for the prompt for selecting a runlevel and enter “3”. When the computer finishes booting up, you should be presented with the text-based console login. If so, then the customization was successful.
- To finish up, decide which runlevel you want to have as a default. Edit “/etc/inittab” and set the default runlevel to 2, 3, or “X” as you like.

Future Experiments:

- If modifying runlevels is interesting to you, there is more that you could do to customize your computer. Remember to leave runlevels 0, 1, 6, and S alone (“/etc/rc0.d”, “/etc/rc1.d”, “/etc/rc6.d”, and “/etc/rcS.d”). You will probably want to leave the default runlevel alone too, as well as runlevel 3 as you have now customized it. This leaves runlevels 4 and 5 to play with. (It is also theoretically possible (as opposed to practically useful) to have more than the eight standard Debian runlevels.)
- One thing you might want to do next is start adding personalized start-up scripts to a runlevel. There is a “skeleton” file for creating new start/stop programs in “/etc/init.d” called “/etc/init.d/skeleton”.
- Also, editting the system's bootloader (e.g. “grub”) to select the desired runlevel at boot-up might be possible and something worth investigating.
- If anyone knows more about adding personalized start-up programs and setting up “grub” to select runlevels, I hope they will have more to say about these points.

Final Note:

- As I hinted at the beginning of this tutorial, I am a newbie writing for other newbies. I hope that fellow newbies will understand what I have written, but take my instructions which the grain of salt they deserve. I hope that more experienced Debian administrators will look at what I have written and point out any mistakes, as well as make suggestions for better ways of customizing runlevels.

[Lavene]

Nice write-up
I just want to add that using update-rc.d to edit runlevels is actually not recommended. Even the man page discourage this.

For basic enabling/ disabling of stuff and customizing the runlevels it's safer and easier to use a tool like 'sysv-rc-conf'.

[Bro.Tiag]

- Also, editting the system's bootloader (e.g. “grub”) to select the desired runlevel at boot-up might be possible and something worth investigating.
- If anyone knows more about adding personalized start-up programs and setting up “grub” to select runlevels, I hope they will have more to say about these points.

Getting grub to boot to another runlevel is pretty simple. All that is needed is to pass the number of the runlevel desired to the kernel. Say you want to boot to runlevel 3, simply add a 3 at the end of the "kernel" line for the grub entry you are booting.

Cheers

[bugsbunny]

- Also, editting the system's bootloader (e.g. “grub”) to select the desired runlevel at boot-up might be possible and something worth investigating.
- If anyone knows more about adding personalized start-up programs and setting up “grub” to select runlevels, I hope they will have more to say about these points.

Getting grub to boot to another runlevel is pretty simple. All that is needed is to pass the number of the runlevel desired to the kernel. Say you want to boot to runlevel 3, simply add a 3 at the end of the "kernel" line for the grub entry you are booting.

Cheers

Taking this a step further - you can actually add another line to grub that will boot to the console (or any other desired runlevel). I used to do this, but when I want to boot into runlevel 3 (which I have defined as a console boot) I just edit the grub line from the boot menu and add the 3 to the end of the existing kernel line (opted for a less cluttered menu since I have multiple kernels listed).

But if you'd rather add it to the menu simply:
1) Find this part of menu.lst

Code: Select all

## altoption boot targets option
## multiple altoptions lines are allowed
## e.g. altoptions=(extra menu suffix) extra boot options
##      altoptions=(single-user) single
# altoptions=(single-user) single

(I may have modified that slightly from the original. So if it's not an exact match don't worry)

Now simply add an additional altoptions line as follows:

Code: Select all

## multiple altoptions lines are allowed
## e.g. altoptions=(extra menu suffix) extra boot options
##      altoptions=(single-user) single
# altoptions=(single-user) single
# altoptions=(Console) 3

(I use 3 - make sure you use the appropriate runlevel for what you want).

Save, then run:

Code: Select all

# update-grub

Next time you boot you should see an additional menu item.

[GOfree]

I just want to add that using update-rc.d to edit runlevels is actually not recommended. Even the man page discourages this.

For basic enabling/disabling of stuff and customizing the runlevels it's safer and easier to use a tool like 'sysv-rc-conf'.

Thanks, Lavene!

You're right. The manual does discourage using 'update-rc.d' in favour of 'sysv-rc-conf'.

I don't have 'sysv-rc-conf' installed and it is not on the Lenny DVD set. It is something that I will definitely have to look into and will try to update this thread when I do.

[GOfree]

Thanks, Bro.Tiag!
Thanks, bugsbunny!

That's excellent--exactly what I was hoping for.

Your instructions worked perfectly for me.

If you don't mind, I would like to write up your instructions again as part of what I posted above. Okay?

[bugsbunny]

Be my guest.

[bugsbunny]

I just want to add that using update-rc.d to edit runlevels is actually not recommended. Even the man page discourages this.

For basic enabling/disabling of stuff and customizing the runlevels it's safer and easier to use a tool like 'sysv-rc-conf'.

Thanks, Lavene!

You're right. The manual does discourage using 'update-rc.d' in favour of 'sysv-rc-conf'.

I don't have 'sysv-rc-conf' installed and it is not on the Lenny DVD set. It is something that I will definitely have to look into and will try to update this thread when I do.

It should be on the first DVD. What happens with

Code: Select all

# aptitude install sysv-rc-conf

If that fails then what's the contents of your /etc/apt/sources.list ?
Also if you have a decent connection why don't you just use an online repository?

[Bro.Tiag]

Be my guest.

Ditto (for my wee contribution)

[Lavene]

I don't have 'sysv-rc-conf' installed and it is not on the Lenny DVD set.

Are you sure? Not on any of them? That's strange. It is in Lenny:
http://packages.debian.org/lenny/sysv-rc-conf

[GOfree]

Modifying Runlevels with sysv-rc-conf

Previously in this thread, I described using update-rc.d to modify runlevels. Now, as Lavene pointed out in a previous post, this method is not recommended. The recommended method for modifying runlevels uses another utility called sysv-rc-conf (or SysV Runlevel Config). I will briefly describe how this works.

As you may have noticed, update-rc.d is not the most user-friendly utility around. In the method I described above, we took precautions to make sure that we only modified the runlevel we were working on and did not alter the runlevels that are critical to the normal functioning of our systems. It is easy to imagine, however, how someone who was not so cautious, using update-rc.d, could inadvertently change a critical runlevel and break their system. The way that update-rc.d accepts parameters for modifying runlevels ("update-rc.d gdm start 30 2 4 5 . stop 01 0 1 3 6 .") is not intuitive and is easy to mess up.

A better way to modify runlevels is to use sysv-rc-conf. (See screenshot below.) This utility is graphical, so one can see the changes that are being made and is therefore far less likely to make a mistake that will break their system. Rather then having to enter a command with a complex set of arguments, as with update-rc.d, one can easily set a program to start or stop at a given runlevel by simply marking a box on or off. Just move the cursor to the box for the service at the desired runlevel (e.g. "gdm" in column "3"), and press the spacebar to place an "X" in the box (to have the program start) or remove the "X" (so that the program will not start). This is indeed a safer and easier way to modify runlevels.

Thanks Lavene for pointing this out!

[GOfree]

I don't have 'sysv-rc-conf' installed and it is not on the Lenny DVD set.

Are you sure? Not on any of them? That's strange. It is in Lenny:
http://packages.debian.org/lenny/sysv-rc-conf

Actually, no... I am not sure.

Anyways, I downloaded it from an online repository.

[GOfree]

Adding a Console Login to the grub Bootloader

As Bro.Tiag and bugsbunny have already described, it is quite simple to configure grub to boot to another runlevel--in our case, to a console login. If you are already familiar with editing the grub menu, then you should have no trouble following their instructions above. I added another line to my grub menu and now have an option of booting to the console login, along with the standard single-user and multi-user runlevels. At the risk of redundancy, for the sake of my fellow newbies, I would like to go over these instructions again.

To recap, you have set up runlevel 3 so that your display manager will not start and you will be presented with console login screen instead. Now, you are ready to try it out. Again, you heed the advice of experienced users and do not stop a running X session by shifting directly to the new custom runlevel. Instead, you want to reboot to the new runlevel.

As is characteristic of GNU/Linux, there are many possible methods of booting to the console runlevel. The first post in this thread looked at two ways, using the /etc/inittab configuration file--either setting the default runlevel to runlevel 3, or setting the default runlevel to "X" and selecting the desired runlevel when prompted during boot-up. Both these methods will work, but seem a little awkward if you are used to making boot decisions through a bootloader like grub.

Selecting the console login through grub is a very logical way to go. You may already have options for booting multiple operating systems. You probably have the option of either booting into the default multi-user runlevel (runlevel 2) or into single-user mode (runlevel 1). Since you already have all these boot options available, why not add your new console login to the list?

Editing the grub Boot Menu

In case you are not familiar with editing the grub menu, here is some background. The menu configuration file is called menu.lst and is located in the path /boot/grub/. Only a system administrator (superuser or root) can edit this file, but anyone should be able to read at it. A standard Debian boot menu configuration will look something like the code given below, with two options (default multi-user and single-user mode).

Code: Select all

title		 Debian GNU/Linux, kernel 2.6.26-2-amd64
root		  (hd0,2)
kernel		/boot/vmlinuz-2.6.26-2-amd64 root=/dev/hda3 ro quiet
initrd		/boot/initrd.img-2.6.26-2-amd64

title		 Debian GNU/Linux, kernel 2.6.26-2-amd64 (single-user mode)
root		  (hd0,2)
kernel		/boot/vmlinuz-2.6.26-2-amd64 root=/dev/hda3 ro single
initrd		/boot/initrd.img-2.6.26-2-amd64

Most of the details of these lines will vary from one system to another. What we are interested in here are the lines starting with the word "kernel". More specifically we are interested in the last terms in these lines. In the first option, the line ends with "quiet" which has nothing to do with the runlevel, and since no runlevel is specified this option will boot to the default runlevel given in /etc/inittab. In the second option, "single" instructs the computer to go into runlevel 1. If you were to edit the line to end with "1", instead of "single", this option would boot to runlevel 1 in (exactly?) the same way. Booting to runlevel 3, then, is as simple as creating a grub menu option with a "kernel" line that ends in "3".

To have the computer boot to runlevel three, we could easily modify one of the existing options (either before rebooting or from the grub menu itself (which would take me too far off course here)). If you want to experiment, try adding a "3" at the end of the first "kernel" line, or change "single" in the second option to "3", so we have something like this:

Code: Select all

kernel		/boot/vmlinuz-2.6.26-2-amd64 root=/dev/hda3 ro 3

Now, if you reboot and select the option you modified, you will go to a runlevel 3 console login.

Assuming that we want to have a persistent option of booting to the console runlevel, while keeping the two other standard options, what we need to do is create a new option. Based on the first two options, it is easy to imagine what the new option will look like. Follow the example of the other options, change the title, and put a "3" at the end of the kernel line and you get something like this:

Code: Select all

title		 Debian GNU/Linux, kernel 2.6.26-2-amd64 (console)
root		  (hd0,2)
kernel		/boot/vmlinuz-2.6.26-2-amd64 root=/dev/hda3 ro 3
initrd		/boot/initrd.img-2.6.26-2-amd64

Finally, while you could easily add this entry by hand, grub is very nice about all this and will actually write this entry for you automatically. Go to this section of menu.lst:

Code: Select all

## altoption boot targets option
## multiple altoptions lines are allowed
## e.g. altoptions=(extra menu suffix) extra boot options
##      altoptions=(single-user) single
# altoptions=(single-user mode) single

Add this line:

Code: Select all

# altoptions=(console) 3

Now run update-grub as the system administrator (superuser, root). The grub software will create the new menu option automatically.

That's it! Now, you should have three options in the grub menu list, including one for a console login, and you can boot to runlevel 3 whenever you want.

Again, thanks to Bro.Tiag and bugsbunny for showing me how to do this. I hope that this post actually adds something to what has already been written.

[GOfree]

Okay, I think we are done with this.

We have created a runlevel for a console login and set up our bootloader to be able to boot to this runlevel whenever we want.

Hopefully, we have a decent understanding of runlevels and how to modify them.

For me, the next step would be to experiment with the two remaining unmodified runlevels (runlevel 4 and runlevel 5). Apparently, one can tweak runlevels for better performance, by preventing unneeded services from starting automatically. Although I have not experienced any performance reduction due to unnecessary background services in Debian, this is something that I have experienced acutely with another popular GNU/Linux distribution. In any case, being able to tweak runlevels seems like a good skill to have.

Anyway, this is enough for now.

Are there any more comments or questions?

[GOfree]

Hi Guys,

About sysv-rc-conf and the Lenny DVD set...

It is on a DVD after all--DVD-4, as they are organized alphabetically.

I don't know why I could not find it before, but anyway...

...my bad.

Free

[mojoman]

Thanks for this howto. I set up a console login by altering runlevel 3 using sysv-rc-conf and editing grub. Quite useful and very easy.
/mojoman

[Polaris96]

This is an old time UNIX trick for adjusting runlevels:

The basic idea is that you don't want to alter rc*.d any more than you absolutely have to. You do this by never erasing anything from rc*.d. Instead, you prepend a neutral character to the link name. Using underscore "_" for this purpose is the usual etiquette. Here's how it works:
~/#mv S99sshd _S99sshd
The preceeding command changes the title of the symlink "Start Process number 99 as secure shell server (sshd)" to "ignore this link"
This is because when init runs through rc*.d it only cares about starting processes prepended with an 'S' and shutting down processes prepended with a 'K'.
By using this technique you never have to remember what you started with and it gives you a neat "toggling ability" to tweak out your runlevel.

I don't know if it's widely used in debian, or in LINUX, generally. But it works just fine and it's a very sane way to work. I also like it very much, even now, because your only using mv, ls, su, and cd to do all your work. If you like KISS, I really don't know of a better way.

And thanx very much to GOfree for digging into the grub menu.lst options - I didn't know you could hang a run level at the end of the boot list. It's a very elegant way to do it.

[GOfree]

--> Polaris96:

Hey, that makes sense. Sounds easy.

I think I will try that on one of the spare runlevels, and see how it goes.

It's great that there are always so many different ways to do things. Your way seems pretty safe.

Thanks for the suggestion!

G

[Polaris96]

Glad to contribute.

[Polaris96]

This is a fun "alternative use" for runlevels. You can set up a basic terminal as your primary runlevel (RL 3 say). Then bump your x11-common and your GUI login links into an empty adjacent runlevel:

Code: Select all

su
cd /etc/rc4.d
rm *
cp -P /rcS.d/S[whatever it is]x11-common /etc/rc4.d/S20x11-common
mv /rcS.d/S[whatever it is]x11-common /etc/rcS.d/_S[whatever]x11-common
cp -P /rc2.d/S[whatever it is]kdm /etc/rc4.d/S30kdm

There's a bit of nuance, here. First, notice the -P flag in the cp calls. That preserves the symlinks. Everything in your rcN.d directories should be links not files. If you don't use cp -P the shell will follow the links into init.d and copy the shell scripts instead of the symlinks. It wil still work but it's WRONG and you shouldn't do it.

Notice I "toggled off" the x11-common link in rcS.d. This is to keep the terminal slick. You don't need anything X in a pure terminal so why load it? Remember you're loading rcS.d no matter what runlevel you use. If you had previously removed it from rcS.d when you built your custom rl, you just need to copy the link from an rc directory that has it.

Alternatively, you could use the ln -s command to create a link to the script in init.d. This is the "proper" way, but either will work and I'm trying to keep the directions simple.

Notice, finally, that I'm calling kdm(KDE) as my GUI. yours may be different (gnome will be gdm).

Also, I named the first link S20 not S10. This isn't standard UNIX practice, but I've found it's a good thing to leave lots of margin for sticking in extra links when you're building your own runlevels. I could add 20 elements to the top of the list before I need to rename all my links. That's convenient.

To launch the GUI from runlevel 3 is easy:

Code: Select all

su
telinit 4

one interesting use for this is switching between WMs. If you're unning gnome and want to play around with, say enlightenment, you can hang gdm on rl4 and e16 on rl5. Remeber you can add more runlevels than the standard 6 if you want. I wouldn't, though. It's best to keep your system relatively standard in the broad strokes.

If you like playing with scripts. This would be the perfect place for a BASH menu to select which (if any) WM the user would like to launch. Just leave all the WM links in rc4.d but "toggled off" and gen up a script to "toggle on" the selected item and then telinit 4. THAT would be both useful and very sane to another admin's eye.

This is intended more as an exercise than a final topology. But it's fun to play with. cheers