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 >
