Re: [PATCH v6 2/2] init/do_mounts.c: create second mount for initramfs

From: Petr Mladek <pmladek@suse.com>
To: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Menglong Dong <menglong8.dong@gmail.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Kees Cook <keescook@chromium.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	johan@kernel.org, ojeda@kernel.org, jeyu@kernel.org,
	masahiroy@kernel.org, joe@perches.com, Jan Kara <jack@suse.cz>,
	hare@suse.de, Jens Axboe <axboe@kernel.dk>,
	tj@kernel.org, gregkh@linuxfoundation.org, song@kernel.org,
	NeilBrown <neilb@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Barret Rhoden <brho@google.com>,
	f.fainelli@gmail.com, palmerdabbelt@google.com,
	wangkefeng.wang@huawei.com,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	vbabka@suse.cz, Alexander Potapenko <glider@google.com>,
	johannes.berg@intel.com,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	jojing64@gmail.com, terrelln@fb.com, geert@linux-m68k.org,
	linux-fsdevel@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>,
	Luis Chamberlain <mcgrof@kernel.org>,
	arnd@arndb.de, Chris Down <chris@chrisdown.name>,
	mingo@kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
	Josh Triplett <josh@joshtriplett.org>
Subject: Re: [PATCH v6 2/2] init/do_mounts.c: create second mount for initramfs
Date: Wed, 28 Jul 2021 10:07:40 +0200	[thread overview]
Message-ID: <YQEQTO+AwC67BT4u@alley> (raw)
In-Reply-To: <20210727123701.zlcrrf4p2fsmeeas@wittgenstein>

On Tue 2021-07-27 14:37:01, Christian Brauner wrote:
> On Tue, Jul 27, 2021 at 08:24:03PM +0800, Menglong Dong wrote:
> > Hello Christian,
> > 
> > On Thu, Jun 17, 2021 at 10:38 PM Christian Brauner
> > <christian.brauner@ubuntu.com> wrote:
> > >
> > [...]
> > >
> > > 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