Hi Grzegorz,
Thank you for the detailed report. I'm sorry we broke your boot process
with the past version. I agree, there are problems with the console=
feature of init and I'm open to finding a suitable workaround.
I have only glanced at the init code which spawns the console, but it
looks to me like the console only gets created if three conditions are met:
1. /proc has been mounted
2. console= has been specified on the kernel command line
3. There is nothing disabling init's console in the /etc/inittab file
Points #2 and #3 you brought up about hard coding may take some more
thought and effort to deal with, so I want to temporarily put those
aside and focus mostly on Point #1 and fix the issue with having two
agettys sharing ttys0. I think we agree #1 is the worst issue as it can
break things.
My initial reaction is to do one of three things:
1. Remove the patch all together. This might upset people who were using
it, but it avoids breaking the expected boot process.
2. Change the name of the kernel parameter init uses to see if it should
spawn an agetty. We could call it something like "init.console=" instead
of "console=". That should avoid the conflict while allowing people to
use init's new feature.
3. Only try to spawn a console if a special flag is set in /etc/inittab.
This is a bit messy, but makes it easy to toggle the feature on/off from
the admin's point of view.
Personally, I'm leaning toward #2. I think effectively giving init parameters their own namespace on the kernel command line makes more sense than removing the feature entirely. But I'm open to suggestions.
Anyone else want to chime in, or offer an alternative solution? If not,
I'm leaning toward a small patch that makes init look for init.console=
instead of just console= on the kernel command line.
Jesse
> Dear sysvinit Development Team,
>
>
>
> I am an embedded systems programmer, also a sysvinit user and I wish to share with you my concerns about this recently introduced feature:
>
>
http://git.savannah.nongnu.org/cgit/sysvinit.git/commit/?id=6e3e87bf32664aaf996d5b7b1eef3b9441ba19ac
>
>
> There are some problems with it.
>
>
> p1. It breaks compatibility. For example, if kernel params include "console=ttyS0" and file /etc/inittab already cotains an entry like this:
>
>
> s0:12345:respawn:/sbin/agetty ttyS0 115200 linux
>
>
> the sysvinit will not notice that there already is an agetty running on ttyS0 and will launch another one. Two agettys will share ttyS0 and produce bizzare effects - prompts of both shells will randomly alternate on the console, and the characters from input
will go randomly to one shell or another.
>
>
> I encountered an effect like this - an upgrade of sysvinit (without changing configuration) broke my boxes.
>
>
> p2. It ignores the baudrate from kernel params. If kernel params include "console=ttyS0,9600", the baudrate 9600 will be ignored (not passed to agetty).
>
>
> p3. It hardcodes too much. Essentially, it runs:
>
>
> /sbin/agetty -L -s 115200,38400,9600 ${console_id} vt102
>
>
> with ${console_id} as the only softcoded thing. Someone might want to:
>
> - use other program than /sbin/agetty
>
> - use other terminal than vt102
>
> - use other options than -L -s (for example, -l or -n)
>
>
> For example, I use /sbin/agetty, but with non-standard options.
>
>
> p4. In many cases, when the /sbin/init starts, /proc is not mounted yet, therefore /proc/cmdline is not available and the feature does not work anyway.
>
>
> I understand that solving p3 (i.e. softcoding everything) would be complex, and /sbin/init is expected to be simple and stable.
>
>
> However, I strongly believe that at least p1 should be adressed. I believe that this feature should not be enabled by default. It should depend on some kind of switch (in /etc/inittab or in some other file, maybe in kernel params).
>
>
> Sincerely,
>
> Grzegorz Borowiak
>