Help with decyphering inittab on a Debian system

I'm working on system running a somewhat customized distro based on Debian.

The system is an arcade video game running on a Pentium 4 PC housed inside a big wood cabinet. When you turn it on it boots up, loads various joystick/keyboard hardware, and then runs the video game. As soon as the video game crashes or is terminated the OS restarts the video game again immediately.

I'm trying to reverse-engineer how the boot-up process works on this machine sufficiently than I can gain access to the terminal while it is running. This will allow me to do development and testing on the machine much easier.

But... there's no easy way to get access to the console. CTRL+ALT+F1 does not work, and I can't seem to interrupt the boot process or drop to a console any other way, and if I terminate the video game process it just respawns.

So far the only way I seem to get access to this system is to pull the hard drive and put it into a separate PC and edit the files.

So far I've figured out this much about the boot-up process:

- The System turns on and POSTs (it uses AMIBIOS. Yay!)
- LILO is invoked, which kicks off the operating system
- Debian starts to boot, loads modules etc.
- At some point early in the boot phase, a script called "" is run
- does a bit of setup and sanity checks, kicks off to a few other scripts, and eventually this is called:

exec xinit $PROG $ARG -- /usr/bin/X11/X -dpi 100 -nolisten tcp -xf86config $TOP/$CONF

The variable $PROG is the path to the video game program, and the other parameters point to various files around the filesystem that configure the X environment. At this point the X-windowing system comes up, and a video game starts playing on the machine.

So that's how the X-window environment is getting run!

But... at this point if you ALT+F4 and quit game, it *immediately* starts back up again. There's no easy way to drop to a terminal, and CTRL+ALT+F1 doesn't seem to work.

So I examined /etc/inittab and this is what it shows near the bottom:

======= /etc/inittab ========


# What to do when the power fails/returns.
pf::powerwait:/etc/init.d/powerfail start
pn::powerfailnow:/etc/init.d/powerfail now
po::powerokwait:/etc/init.d/powerfail stop

# /sbin/getty invocations for the runlevels.
# The "id" field MUST be the same as the last
# characters of the device (after "tty").
# Format:
#  <id>:<runlevels>:<action>:<process>
# Note that on most Debian systems tty7 is used by the X Window System,
# so if you want to add more getty's go ahead but skip tty7 if you run X.
1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
#3:23:respawn:/sbin/getty 38400 tty3
#4:23:respawn:/sbin/getty 38400 tty4
#5:23:respawn:/sbin/getty 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6

# Example how to put a getty on a serial line (for a terminal)
#T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
#T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100

# Example how to put a getty on a modem line.
#T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS3

# Start ITG

Open in new window

Ahah! So it looks like that "" script gets invoked directly by inittab, and it is set to "respawn" if it ever dies. Makes sense!

I'd like to figure out WHAT to change in inittab so that I can get that "drop to a console" behavior, perhaps some way to re-enable the CTRL+ALT+F1 behavior or something like that.

But now I'm just guessing.... I've never played in inittab before.

Any ideas? I can post the contents of any file you want if it helps.
LVL 31
Who is Participating?
Frosty555Connect With a Mentor Author Commented:
Hi jools,

I figured it out, the problem ended up being unrelated to inittab entirely...

There was a line in xorg.conf that reads:

Option "DontVTSwitch" "true"

That prevents the ctrl+alt+f1 functionality. Once I commented out that line, the ctrl+alt+fX keys work properly.

As far as the respawning of the process (alt+f4 causes the app to close, then immediate re-open), that was caused by the "respawn" flag in the inittab, which can't really be avoided. But it doesn't matter because I can ctrl+alt+f1 to a console window without having to close the program at all.
have you just tried commenting the line out so it doesnt run then run something like telinit q or init c or reboot...
Frosty555Author Commented:
I'm really trying to understand more what this inittab is doing - why I can't ctrl+alt+f1 to a separate console like I normally can on other linux machines...

I suppose I could comment out that line and I'm sure that would disable the video game from running on boot-up and drop me to a console... I'll test that next I get a chance. But the system would be unusable until I put the inittab back.

I trying to find a way to modify the system so I can perform maintenance on it without having to open it up and remove the hard drive every time.

Do you think that if I removed the script from inittab I could maybe have it launch on boot-up automatically through some other means that would give me more control over the console windows?
joolsConnect With a Mentor Commented:
It sounds like a customized system so what you want or expect may not be available.

You missed out initdefault but I guess it may work if you change tty2 to run at levels 2345 rather than just 23. I expect the default is runlevel 5.

If the system is networked you might see if ssh is available.
Frosty555Author Commented:
found the problem myself
All Courses

From novice to tech pro — start learning today.