On Tue 2021-07-27 14:37:01, Christian Brauner wrote:

On Tue, Jul 27, 2021 at 08:24:03PM +0800, Menglong Dong wrote:

quoted

Hello Christian,

On Thu, Jun 17, 2021 at 10:38 PM Christian Brauner
[off-list ref] wrote:

quoted

[...]

quoted

Hey Menglong,

Since we're very close to the next kernel release it's unlikely that
anything will happen before the merge window has closed.
Otherwise I think we're close. I haven't had the time to test yet but if
nothing major comes up I'll pick it up and route it through my tree.
We need to be sure there's no regressions for anyone using this.

Seems that it has been a month, and is it ok to move a little
further? (knock-knock :/)

Yep, sorry.
When I tested this early during the merge window it regressed booting a
regular system for me meaning if I compiled a kernel with this feature
enabled it complained about not being being able to open an initial
console and it dropped me right into initramfs instead of successfully
booting. I haven't looked into what this is caused or how to fix it for
lack of time.

I guess that you have seen the following message printed by
console_on_rootfs():

      "Warning: unable to open an initial console."

This function is responsible for opening stdin, stdout, stderr
file to be used by the init process.

I am not sure how this is supposed to work with the pivot_root
and initramfs.


Some more details:

console_on_rootfs() tries to open /dev/console. It is created
by tty_init(). The open() callback calls:

  + tty_kopen()
    + tty_lookup_driver()
      + console_device()

, where console_device() iterates over all registered consoles
  and returns the first with tty binding.

There is ttynull_console that might be used as a fallback. But I
am not sure if this is what you want.

Best Regards,
Petr