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
>