[Buildroot] [PATCH 1/1] fs/cpio: make initramfs init script survive 'console=' kernel argument

[Buildroot] [PATCH 1/1] fs/cpio: make initramfs init script survive 'console=' kernel argument

[Timo Ketola]

When booting with 'console=<empty>' in the kernel command line (as e.g.
U-Boot does with silent flags in effect), opening /dev/console fails.
That is fatal in the /init script and kernel will panic. It is also
needless, because the kernel tries to open it anyway (well, as long as
we have console node in initramfs /dev; cpio.mk creates that alright).

Signed-off-by: Timo Ketola <timo.ketola@exertus.fi>
---
 fs/cpio/init | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/fs/cpio/init b/fs/cpio/init
index dbe09ac..72b2401 100755
--- a/fs/cpio/init
+++ b/fs/cpio/init
@@ -1,7 +1,5 @@
 #!/bin/sh
 # devtmpfs does not get automounted for initramfs
 /bin/mount -t devtmpfs devtmpfs /dev
-exec 0</dev/console
-exec 1>/dev/console
-exec 2>/dev/console
+
 exec /sbin/init "$@"
-- 
2.7.4

[Buildroot] [PATCH 1/1] fs/cpio: make initramfs init script survive 'console=' kernel argument

[Peter Korsgaard]

>>>>> "Timo" == Timo Ketola <Timo.Ketola@exertus.fi> writes:

 > When booting with 'console=<empty>' in the kernel command line (as e.g.
 > U-Boot does with silent flags in effect), opening /dev/console fails.
 > That is fatal in the /init script and kernel will panic. It is also
 > needless, because the kernel tries to open it anyway (well, as long as
 > we have console node in initramfs /dev; cpio.mk creates that alright).

Also when devtmpfs is used? We manually mount devtmpfs in the initramfs,
so the kernel presumably cannot have opened /dev/console before
executing /init, and we do not add a static device node for
/dev/console.


 > Signed-off-by: Timo Ketola <timo.ketola@exertus.fi>
 > ---
 >  fs/cpio/init | 4 +---
 >  1 file changed, 1 insertion(+), 3 deletions(-)

 > diff --git a/fs/cpio/init b/fs/cpio/init
 > index dbe09ac..72b2401 100755
 > --- a/fs/cpio/init
 > +++ b/fs/cpio/init
 > @@ -1,7 +1,5 @@
 >  #!/bin/sh
 >  # devtmpfs does not get automounted for initramfs
 >  /bin/mount -t devtmpfs devtmpfs /dev
 > -exec 0</dev/console
 > -exec 1>/dev/console
 > -exec 2>/dev/console
 > +
 >  exec /sbin/init "$@"
 > -- 
 > 2.7.4
 > _______________________________________________
 > buildroot mailing list
 > buildroot at busybox.net
 > http://lists.busybox.net/mailman/listinfo/buildroot

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 1/1] fs/cpio: make initramfs init script survive 'console=' kernel argument

[Timo Ketola]

On 23.9.2019 16.10, Peter Korsgaard wrote:
>>>>>> "Timo" == Timo Ketola <Timo.Ketola@exertus.fi> writes:
> 
>  > When booting with 'console=<empty>' in the kernel command line (as e.g.
>  > U-Boot does with silent flags in effect), opening /dev/console fails.
>  > That is fatal in the /init script and kernel will panic. It is also
>  > needless, because the kernel tries to open it anyway (well, as long as
>  > we have console node in initramfs /dev; cpio.mk creates that alright).
> 
> Also when devtmpfs is used? We manually mount devtmpfs in the initramfs,
> so the kernel presumably cannot have opened /dev/console before
> executing /init, and we do not add a static device node for
> /dev/console.

But I thought BR does just that here:

https://git.busybox.net/buildroot/tree/fs/cpio/cpio.mk

line 24, 25

-- 

Timo

[Buildroot] [PATCH 1/1] fs/cpio: make initramfs init script survive 'console=' kernel argument

[Peter Korsgaard]

>>>>> "Timo" == Timo Ketola <timo@exertus.fi> writes:

 > On 23.9.2019 16.10, Peter Korsgaard wrote:
 >>>>>>> "Timo" == Timo Ketola <Timo.Ketola@exertus.fi> writes:
 >> 
 >> > When booting with 'console=<empty>' in the kernel command line (as e.g.
 >> > U-Boot does with silent flags in effect), opening /dev/console fails.
 >> > That is fatal in the /init script and kernel will panic. It is also
 >> > needless, because the kernel tries to open it anyway (well, as long as
 >> > we have console node in initramfs /dev; cpio.mk creates that alright).
 >> 
 >> Also when devtmpfs is used? We manually mount devtmpfs in the initramfs,
 >> so the kernel presumably cannot have opened /dev/console before
 >> executing /init, and we do not add a static device node for
 >> /dev/console.

 > But I thought BR does just that here:

 > https://git.busybox.net/buildroot/tree/fs/cpio/cpio.mk

 > line 24, 25

Heh, indeed - I forgot about that logic. Then I guess it is good, unless
something else in the boot sequence doesn't like a missing
stdin/stdout/stderr.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 1/1] fs/cpio: make initramfs init script survive 'console=' kernel argument

[Timo Ketola]

Peter,

On 23.9.2019 20.07, Peter Korsgaard wrote:
>>>>>> "Timo" == Timo Ketola <timo@exertus.fi> writes:
>  > But I thought BR does just that here:
> 
>  > https://git.busybox.net/buildroot/tree/fs/cpio/cpio.mk
> 
>  > line 24, 25
> 
> Heh, indeed - I forgot about that logic. Then I guess it is good, unless
> something else in the boot sequence doesn't like a missing
> stdin/stdout/stderr.

I think BusyBox's init takes care about that. See my conversation with
Arnout:

http://lists.busybox.net/pipermail/buildroot/2019-September/259889.html

And thanks for looking at this.

--

Timo

[Buildroot] [PATCH 1/1] fs/cpio: make initramfs init script survive 'console=' kernel argument

[Timo Ketola]

Hi there,

I tested this as per Arnout's suggestion by booting with 'console=' /
'console=ttymxc0,115200' and with / without initramfs. The result
depends only on console setting:

# cat /proc/cmdline; ls -l /proc/1/fd
console=
total 0
lrwx------    1 root     root            64 Sep 24 05:01 0 -> /dev/null
lrwx------    1 root     root            64 Sep 24 05:01 1 -> /dev/null
lrwx------    1 root     root            64 Sep 24 05:01 2 -> /dev/null

# cat /proc/cmdline; ls -l /proc/1/fd
console=ttymxc0,115200
total 0
lrwx------    1 root     root            64 Sep 24 05:20 0 -> /dev/console
lrwx------    1 root     root            64 Sep 24 05:20 1 -> /dev/console
lrwx------    1 root     root            64 Sep 24 05:20 2 -> /dev/console

--

Timo

[Buildroot] [PATCH 1/1] fs/cpio: make initramfs init script survive 'console=' kernel argument

[Timo Ketola]

Hi,

Should I do something with this?

--

Timo

[Buildroot] [PATCH 1/1] fs/cpio: make initramfs init script survive 'console=' kernel argument

[Yann E. MORIN]

Timo, All,

On 2019-09-23 10:58 +0000, Timo Ketola spake thusly:
> When booting with 'console=<empty>' in the kernel command line (as e.g.
> U-Boot does with silent flags in effect), opening /dev/console fails.
> That is fatal in the /init script and kernel will panic. It is also
> needless, because the kernel tries to open it anyway (well, as long as
> we have console node in initramfs /dev; cpio.mk creates that alright).
> 
> Signed-off-by: Timo Ketola <timo.ketola@exertus.fi>

I've applied to master, after extending the commit log with all the gory
details explaininng why we can indeed safely remove those redisrections
now.

Thank you for the patience on this patch.

Thanks also to Peter for helping on IRC about this research.

Regards,
Yann E. MORIN.

> ---
>  fs/cpio/init | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/fs/cpio/init b/fs/cpio/init
> index dbe09ac..72b2401 100755
> --- a/fs/cpio/init
> +++ b/fs/cpio/init
> @@ -1,7 +1,5 @@
>  #!/bin/sh
>  # devtmpfs does not get automounted for initramfs
>  /bin/mount -t devtmpfs devtmpfs /dev
> -exec 0</dev/console
> -exec 1>/dev/console
> -exec 2>/dev/console
> +
>  exec /sbin/init "$@"
> -- 
> 2.7.4
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 1/1] fs/cpio: make initramfs init script survive 'console=' kernel argument

[Peter Korsgaard]

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 > Timo, All,
 > On 2019-09-23 10:58 +0000, Timo Ketola spake thusly:
 >> When booting with 'console=<empty>' in the kernel command line (as e.g.
 >> U-Boot does with silent flags in effect), opening /dev/console fails.
 >> That is fatal in the /init script and kernel will panic. It is also
 >> needless, because the kernel tries to open it anyway (well, as long as
 >> we have console node in initramfs /dev; cpio.mk creates that alright).
 >> 
 >> Signed-off-by: Timo Ketola <timo.ketola@exertus.fi>

 > I've applied to master, after extending the commit log with all the gory
 > details explaininng why we can indeed safely remove those redisrections
 > now.

 > Thank you for the patience on this patch.

 > Thanks also to Peter for helping on IRC about this research.

Committed to 2020.02.x, thanks.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 1/1] fs/cpio: make initramfs init script survive 'console=' kernel argument

[Peter Korsgaard]

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 > Timo, All,
 > On 2019-09-23 10:58 +0000, Timo Ketola spake thusly:
 >> When booting with 'console=<empty>' in the kernel command line (as e.g.
 >> U-Boot does with silent flags in effect), opening /dev/console fails.
 >> That is fatal in the /init script and kernel will panic. It is also
 >> needless, because the kernel tries to open it anyway (well, as long as
 >> we have console node in initramfs /dev; cpio.mk creates that alright).
 >> 
 >> Signed-off-by: Timo Ketola <timo.ketola@exertus.fi>

 > I've applied to master, after extending the commit log with all the gory
 > details explaininng why we can indeed safely remove those redisrections
 > now.

 > Thank you for the patience on this patch.

 > Thanks also to Peter for helping on IRC about this research.

It unfortunately causes a regression :/

I have a setup booting from an initramfs, using devtmpfs, busybox init
and glibc. One of the initscripts used ttyname_r(3) (through the busybox
tty applet), and with this change ttyname_3() fails rather than
returning /dev/console.

Looking at the glibc code, it does a fstat on fd(0), and then compares
st_ino / st_dev (and optionally st_rdev) against all the entries under
/dev.

As the kernel does not mount devtmpfs for us, fd 0 refers to the
/dev/console entry in the rootfs (cpio), but after devtmpfs is mounted,
/dev/console is the entry in the devtmpfs so st_dev / st_ino will no
longer match :/

This logic seems to be added to support containers. See the following
glibc commit:

commit 15e9a4f378c8607c2ae1aa465436af4321db0e23
Author: Christian Brauner <christian.brauner@canonical.com>
Date:   Fri Jan 27 15:59:59 2017 +0100

    linux ttyname and ttyname_r: do not return wrong results

    If a link (say /proc/self/fd/0) pointing to a device, say /dev/pts/2, in a
    parent mount namespace is passed to ttyname, and a /dev/pts/2 exists (in a
    different devpts) in the current namespace, then it returns /dev/pts/2.
    But /dev/pts/2 is NOT the current tty, it is a different file and device.

    Detect this case and return ENODEV.  Userspace can choose to take this as a hint
    that the fd points to a tty device but to act on the fd rather than the link.

    Signed-off-by: Serge Hallyn <serge@hallyn.com>
    Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>


Notice: Once logged in, tty does work correctly. Presumably login
reopens stdin/stdout/stderr.

Any great ideas about how we can fix this? I would prefer to not add a
lot of logic in /init, so preferably not having to mount /proc and so
on. If we don't have a good solution, what then? Do we revert or keep it
like this?

-- 
Bye, Peter Korsgaard