[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jesse Smith
Subject: Re: [sysvinit-devel] Sysvinit-devel Digest, Vol 55, Issue 6
Date: Fri, 21 Sep 2018 17:12:55 -0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0

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.


> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]