Re: [sysvinit-devel] Sysvinit-devel Digest, Vol 55, Issue 3

[Matias Fonzo]

Hello Jesse,

I wonder why this code is needed in the init side.  I've tried to find
some more info on the documentation, but this seems undocumented.

On Tue, 18 Sep 2018 13:38:39 -0300
Jesse Smith <address@hidden> wrote:

> 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
> >  
> 
>