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 <jsm...@resonatingmedia.com> 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 > > > >
