Messages in this thread | | | Date | Wed, 28 Jul 2021 10:07:40 +0200 | From | Petr Mladek <> | Subject | Re: [PATCH v6 2/2] init/do_mounts.c: create second mount for initramfs |
| |
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
| |