Creative Commons

2008-12-10 17:51:17

Add TTYs in Fedora 9+, Plus More!

As extra credit in my Intro to Linux class, I gave a problem that used to be simple but is now (since Fedora 9) slightly more difficult. As an in class assignment, one of the parts was to learn how to switch between text consoles. Once that was learned, the students then had to make a new text console, preferably tty8 since that isn't used by default. The book detailed how to do this by simply adding a line in /etc/inittab. That, however, doesn't work anymore because mostly everything has been moved out of /etc/inittab into their own files. So, once the students hit this point, a barrage of questions flew at me.
I walked over to a student's computer to see what error he was receiving and then proceeded back to my computer. I told them to skip taht part and I would quickly figure it out and tell them what file they needed to edit. Fat chance. I spent about 5 minutes trying to figure out how to add another TTY all while talking them through what I was doing: restarting init, checking the log, cross-referencing errors on the Internet, etc. I'm not the type of professor who will waste the students' time (I know I hated that when I took classes), so I gave them some options. Either they could forget about this part of the assignment and not lose any points, or they could figure out how to add tty8 before the final exam and earn extra credit.
No one bit. So now that the final is over, here's the solution. TTYs are no longer configured in /etc/inittab, they each have their own configuration file located in /etc/event.d.
[root@localhost event.d]# ls control-alt-delete rc0 rc3 rc6 serial tty2 tty5 logd rc1 rc4 rcS sulogin tty3 tty6 prefdm rc2 rc5 rcS-sulogin tty1 tty4
So first, let's check out what one of the existing, working TTY files look like:
[root@localhost event.d]# cat tty6 # tty6 - getty # # This service maintains a getty on tty6 from the point the system is # started until it is shut down again. start on stopped rc2 start on stopped rc3 start on stopped rc4 start on started prefdm stop on runlevel 0 stop on runlevel 1 stop on runlevel 6 respawn exec /sbin/mingetty tty6
Simple enough. We want our new TTY to be available at all of the same run levels as tty6, so let's just copy that file and replace all occurrences of 'tty6' with 'tty8'.
[root@localhost event.d]# cat tty8 # tty8 - getty # # This service maintains a getty on tty8 from the point the system is # started until it is shut down again. start on stopped rc2 start on stopped rc3 start on stopped rc4 start on started prefdm stop on runlevel 0 stop on runlevel 1 stop on runlevel 6 respawn exec /sbin/mingetty tty8
Now here's the stumper. Even if we go as far as rebooting, we still won't have our TTY. If you check the log, you'll see a somewhat vague error message:
Nov 5 19:31:53 localhost /sbin/mingetty[3218]: tty8: no controlling tty: Operation not permitted
What does that mean? My first instinct went back to the first thing people learn about *nix and also the hardest thing to understand: everything is a file. TTYs are just files in /dev, I wonder if tty8 actually exists.
[root@localhost dev]# ls | grep tty8 tty8
Crap, it's there. Ok, this may be harder than I originally thought. My next thought was the one that set me on the right path. I figured, if there is something that has to be configured about a TTY, then it must be in some configuration file somewhere. So, tty6 is already working, let's see if it shows up in any configuration files:
[root@localhost etc]# grep -irn tty6 * . . <SNIPPED> . . udev/makedev.d/50-udev.nodes:7:tty6
Among other places that don't seem so useful, it seems that tty6 shows up in /etc/udev/makedev.d/50-udev.nodes, so let's take a look there and see what we find:
[root@localhost makedev.d]# head 50-udev.nodes # These device have to be created manually tty1 tty2 tty3 tty4 tty5 tty6 loop0 loop1 loop2
A ha! Now we're cookin'. It appears that all TTYs that actually work are listed in this file. Apparently having a file in /dev wasn't enough, the udev process also has to create a node for it; and if it isn't listed in this file, it doesn't get created. So let's add 'tty8' to this file and see what happens.
[root@localhost makedev.d]# head 50-udev.nodes # These device have to be created manually tty1 tty2 tty3 tty4 tty5 tty6 tty8 loop0 loop1
I rebooted the machine just to be on the safe side, but you could just also just have init reread it's config. Voila! Upon pressing CTRL+ALT+F8 we can see that our new TTY works.

As promised, here some other tidbits that I came across recently that will hopefully help some people.



2009-01-14 02:05:33

Vance says...
You'd think that synchronous XMLHttpRequests might be useful, but in practice they appear to have serious problems (

Interesting to read about the TTYs - the advent of udev seems to have changed the way a number of things have been traditionally done.

2009-01-14 06:49:50

Mike says...
Ubuntu has also replaced the old /etc/inittab with event.d. Some might consider this progress, but as far as I can see a perfectly functional system has been replaced by a new solution that adds no features I consider worth having, while managing to obsolete a large amount of "in the wild" documentation. Your article is useful, but I'd argue the changes that necessitated it were ill thought out and unhelpful.

2009-01-14 07:58:57

Steve says...
I have to agree with Mike. What problem does all these changes to the init system solve?

2009-01-14 08:21:01

slonkak says...
@Vance Those are valid points about SJAX, however my use had to do it. I had to do an intersection on two sets of data from a database that doesn't have a intersect function. In addition, the two sets of data were created by the user via SELECT box clicks. I needed to use synchronous to make sure that their onclick event from the first dropdown completed and their onclick event from the second dropdown completed before I ran my intersection (in javascript on the client side, of course). So, I completely know your issues with SJAX, and the rest of my project uses AJAX, but in this one case synchronous was necessary.

@Mike Totally agree. I have no idea why these things were changed, and in addition, why there isn't any documentation about it anywhere. /etc/inittab seemed fine to me and I don't see any benefits to the multiple file system they've implemented with udev.

2009-01-14 10:15:54

furicle says...
The move to event.d allows for flexible service start up - things don't have to be started in a rigid order anymore - see

2009-01-14 10:36:55

slonkak says...
@furicle That's a good site. Thanks! I'm still on the fence though about the whole thing. I've used linux since the RedHat 7 days (sure, not that long, but I'm not that old ;) and have never had a problem with the init process. I feel the same way about the addition of LVM. I've never had a problem with normal partitioning and see LVM as a hassle, so much so that I disable it as much as I can.

2009-01-15 19:51:55

Arthur Marsh says...
I thought SVR4's ttymon, pmadm and sacadm took some learning.

2010-04-30 13:19:23

Jim says...
The move to event.d was a side effect of an improvement that Ubuntu created which allows multiple processes to run in parallel during the system initialization. This reduces that time to boot and makes some sense in the multi-core processor environments.

Post a comment!