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

[Jesse Smith]

If I understand correctly, what you are suggesting is we leave the
console= flag in place, as it is now. But whether init acts on it or not
will be controlled by a second parameter called init.autocon. If
init.autocon is not set to 1, then init will ignore the console= kernel
parameter. Is that correct?

The only potential problem I see with this approach would be if someone
wanted the kernel to set up a console on one device and init to set up a
console on another device. This seems unlikely, but I wonder if it's
possible someone would want to do that? I wouldn't want to introduce a
fix that prevents people from having both options if they want it.

Jesse



> Hi, thank you for your answer.
>
>
> I managed the situation by reverting to version 2.88 and temporarily 
> disabling automatic upgrades of sysvinit.
>
>
> While all your ideas 1, 2, 3 are viable, I have fourth idea: add kernel 
> parameter, for example, init.autocon=1, which will enable automatic console 
> creation. This would have two advantages over idea 2:
>
> - shorter cmdline
>
> - no necessity of repeating (DRY principle)
>
> For example, instead of cmdline:
>
>
> console=tty0 console=ttyS0,15200 console=ttyS1,9600 init.console=tty0 
> init.console=ttyS0,15200 init.console=ttyS1,9600
>
>
> it would be:
>
>
> console=tty0 console=ttyS0,15200 console=ttyS1,9600 init.autocon=1
>
> and if this cmdline is going to be generated (for example, by sophiscated 
> bootloader or by installer) or changed manually, it would be far easier to 
> maintain console names and baudrates if these do not need to be repeated 
> twice.
>
> Sincerely,
> Grzegorz Borowiak
>