centos 7 replace systemd with a script

Question

I want to do the following thing: I want to replace the systemd program on my CentOS 7 installation, with a script , that will eventually start a shell where the user can input commands as root on the system console.

For this, I used the init=/sbin/myInit parameter. In this script I do some initialization, and in the end I call bash to enable the user to input commands. The interactive bash always appears on the screen.

Unfortunately, there is a problem with the input, that I haven't been able to solve: the input doesn't work correctly. When I press enter, only the second enter works, but no new line is performed on the screen. And when I type some characters, not all the characters are read. It seems like the console is in some Unicode mode ( stty -a shows iutf8 parameter), and bash cannot correctly read the input. The output is fine, all the echo commands in my script are correctly printed on the screen (I only print ASCII characters).

I've tried all sorts of combinations, with different LC_ALL settings ( LC_ALL=C , LC_ALL=C.utf-8 , no LC_ALL or LANG variables initialization), redirect stdin/stdout/stderr to /dev/console , /dev/tty0 or /dev/tty1 , the TERM variable is initialized to linux value, but nothing works. I tried unicode_start and unicode_stop commands, but unicode_stop doesn't work, and I get the error message "stty: standard input: unable to perform all requested operations". If I run showkey command, and I press the enter key, the correct keycode 28 is detected, same with normal boot.

Even stranger than this is the fact that if I'm using the init=/bin/bash kernel parameter, the input works fine, and if I manually run my script, it also works fine. If I copy the bash executable to something like /bin/mys , and I use init=/bin/mys , than same input problem occurs. It seems like the initrd image treats /bin/bash differently. Maybe it performs some initialization or something, that enables the bash to read correctly from the terminal. Why do we have this difference between init=/bin/bash and init=/bin/mys ? It's the same executable in the end.

What am I doing wrong ?

As a general question about the init program, can somebody explain me what the init program should do to work correctly ? Any particular signals it has to respond to, any console initialization to be performed ?

I'm trying to solve this for days, and I cannot find any solution. On the web I couldn't find any article about this. So any suggestion would be greatly appreciated. Thank you.

Answer 1

I managed to pull a solution out for this one.

Turns out, at boot, the console is not initialized. I looked at the differences between the output of stty -a between the normal boot and the script boot ( init=/sbin/myInit ), and there are some differences between them: the console on normal boot had the following flags active on it: brkint ignpar ixon imaxbell isig icanon iexten echo, while when on script boot, those flags where cleared ( stty reports them with - ). I'm not sure what they mean, except the echo flag, which I quickly noticed, because on each key press, no character ware printed on the screen.

So I decided to set those flags on my init script for /dev/console. After digging the stty manual page, I found the sane option, that sets the most important flags for normal console usage. So I added the line stty -F /dev/console sane in my init script.

But, there is a small problem. It seems that some console options cannot be changed by the stty command if the console is already opened by a process. So the first thing I did in my script is to redirect the stdin/stdout/stderr to /dev/null , via the line 0/dev/null , and then add the stty sane line, then redirect back the stdin/stdout/stderr to /dev/console .

I also noticed a process called plymouth , probably started by the CentOS initrd , so before the root was mounted and init script executed. I'm not sure if that process opened the system console, but I decided to eliminate it, by reconstructing a personalized initrd , by omitting the plymouth module from dracut (option -o plymouth ).

After doing this, the script worked fine, and the bash process started by the script could read correctly the console.

Hope this helps somebody someday. Cheers