Vineet, All,
On 2021-01-06 15:36 -0800, Vineet Gupta spake thusly:
> On 11/11/20 5:54 AM, Petr Mladek wrote:
[--SNIP--]
> >Make sure that stdin, stdout, stderr, and /dev/console are always
> >available by a fallback to the existing ttynull driver. It has
> >been implemented for exactly this purpose but it was used only
> >when explicitly configured.
> >
> >Signed-off-by: Petr Mladek <pmladek@xxxxxxxx>
>
> >--- a/init/main.c
> >+++ b/init/main.c
> >@@ -1470,8 +1470,14 @@ void __init console_on_rootfs(void)
> > struct file *file = filp_open("/dev/console", O_RDWR, 0);
> > if (IS_ERR(file)) {
> >- pr_err("Warning: unable to open an initial console.\n");
> >- return;
> >+ pr_err("Warning: unable to open an initial console. Fallback to ttynull.\n");
> >+ register_ttynull_console();
> >+
> >+ file = filp_open("/dev/console", O_RDWR, 0);
> >+ if (IS_ERR(file)) {
> >+ pr_err("Warning: Failed to add ttynull console. No stdin, stdout, and stderr for the init process!\n");
> >+ return;
> >+ }
>
> This breaks ARC booting (no output on console).
>
> Our Buildroot based setup has dynamic /dev where /dev/console doesn't exist
> statically and there's a primoridla /init shell script which does following
>
> /bin/mount -t devtmpfs devtmpfs /dev
> exec 0</dev/console
> exec 1>/dev/console
> exec 2>/dev/console
> exec /sbin/init "$@"
I guess you are speaking about the initramfs (cpio) case, right?
We've changed that code last August:
https://git.buildroot.org/buildroot/commit/fs/cpio/init?id=b9026e83f
I.e. if we can't do the redirection, then we don't redirect anything.
The change was done for people who explicitly pass an empty console= on
their kernel command line.
Now, I haven't looked at nulltty yet, and I have (so far) no idea on how
it works. Thanks for the hint, I'll have a look.
> Buildroot has had this way of handling missing /dev/console since 2011 [1]
> and [2].
See also more archaelogy on that topic, referenced in that commit:
https://git.buildroot.org/buildroot/commit/fs/cpio/?id=98a6f1fc02e41
> Please advise what needs to be done to unbork boot.
This has been present since the 2020.08 release, and has been backported
to the maintenance branches:
2020.02.x (LTS) -> f1a83afe2df2a
2020.05.x -> 797f9e40224c9
> Otherwise this seems
> like a kernel change which breaks user-space and needs to be backed-out (or
> perhaps conditionalize on CONFIG_NULL_TTY. I'm surprised it hasn't been
> reported by any other embedded folks
I won't speak about whether this is a kernel regression or not, not my
call.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
