default getty port

Hi!

Yesterday suddenly discovered the commit 131300e6f1d0 (system: run getty on boot console by default) in the mainline.

I tried to play with the patch a bit and got confused. It would be nice if someone could clarify a situation.

(In our environment we are using something like console=tty1 console=ttyS0,115200n8
as kernel command line with the specific patch to system/skeleton/inittab to always run getty on /dev/tty1.)

First of all, /dev/tty0 (as proposed in the example in the commit message) has special meaning in Linux. You can't just use it as a console since it refers to current foreground console in the kernel. Moreover, it has no record in the /etc/securetty (and of course it shouldn't be there by security reasons!). So, we have to use any virtual console but tty0.

Next thing is /dev/console as parameter to getty. I don't know if it supposed to work on some configurations, but in our case it makes things
weird: when I type 'root' + Enter on the local (tty1) console I got one more 'r' printed and password is asked. Looks like racy input between /dev/console and /dev/tty1 since it is the same at that point.

I also am not sure about validity of B0. I didn't check actual kernel code, though it might go down to the driver level where not all drivers behave the same when got B0.

So, for my opinion the patch brought more problems than tries to solve.

I would be happy to understand the background deeply and correct myself.

Andy Shevchenko <[email protected]>
Intel Finland Oy

Hi Andy,

So let me try to help you here.

Speaking about example in commit message note that it clearly mentions that the last "console" item will be used for instantiation of getty, so in the particular example getty will be run on "ttyS3".

Hm... probably your problem happens because you select that option and also have another entry for getty in inittab.

And to make things a bit more clear I'd like to see your /etc/inittab that is generated with Buildroot (essentially with your customizations).

If I'm not mistaken behavior that you describe (request for password) happens if corresponding tty doesn't exist in /etc/securetty list. Thomas may correct me if I'm wrong here.

Well I cannot answer for all drivers but from what I saw personally it worked nice. Probably there're exceptions in drivers but it has to be confirmed I guess.

Let's try to solve your problems first.
And even this patch doesn't work for you there's a simple work-around with explicit specification of tty device you want to use with getty.

We're talking about default value for getty's tty and I think even if "console" is not the best option for all but equally ttyS0 doesn't work well for many of us - there're lots of boards with non-16550 serial ports.

And if we're talking about regression for devices with ttyS0 and new default ("console") I would rather add "ttyS0" in defconfigs for affected devices in Buildroot.

Not sure if my comments make sense but I really tried to help :)

-Alexey