[tbot] How to debug acquire_linux

[Harald Seiler]

Hello Wolfgang, Heiko,

On Fri, 2018-11-23 at 10:31 +0100, Heiko Schocher wrote:
> Hello Wolfgang,
> 
> Am 23.11.2018 um 10:08 schrieb Wolfgang Denk:
> > Hallo Harald,
> > 
> > In message <1542962899.2564.5.camel at denx.de> you wrote:
> > > 
> > > > The second not working case seems if the board prints some data on the
> > > > console after the login propt is sent. This is the case when a daemon
> > > > has the stdout set to the console. Also in this case, it seems that tbot
> > > > gets confused.
> > > 
> > > Yes, this is an open issue:
> > > 
> > > 	https://github.com/Rahix/tbot/issues/1
> > > 
> > > I don't know how we best handle this case ... Do you have any ideas?
> > 
> > Hm... why does tbot not recognise the prompt even if it is embedded
> > in other output?  Strict anchoring to something like "^<prompt>$"
> > seems a bit restrictive to me...
> 
> And here the problems begin ... in linux, we are fine, as we have
> defined an unique prompt ... but in U-Boot you may have "=> " for a lot
> of boards ... and "=> " can occur in for example testing memory dumps...
> 
> Can we be sure linux prompt is never disturbed by other output ?

As mentioned in my other mail, we need to somehow ensure that clobber does
not happen after TBot acquires the shell.  Else a lot of things can fail.

For example:  TBot runs `echo $?` after each command to retrieve the return value.
What if a kernel message happens exactly during that call? Now TBot will try to
parse this message as an `int`, which will of course fail ...

> > Alternatively, one could try to trigger a reprinting of the prompt by
> > sending a newline (or, depending on contect, maybe a ^D) character?
> 
> Yep, thats the reason why you saw last year on the embedded some Ctrl-C
> characters in old tbot demo ... you remember?

This "solution" you used is something I want to avoid at all costs, because
I feel it will lead to a lot of headaches down the line ...

> > I. e., if no prompot is recognized after the expected timeout,
> > instead of hard failing, try sending a newline and check again?
> 
> no newline please, as if you are in U-Boot, may a previous command
> gets started again. I vote for Ctrl-C. This can be sended safely in
> U-Boot and Linux.

I noticed that as well ... I think in U-Boot I have this issue under
control, it is more of a Linux problem.

I prefer a solution that keeps the console clean for the aforementioned
reason.  I think TBot should at all times be able to reason about the
state of the board and never have to resort to brute-forcing it into some
semi-known situation.

Log clobber during boot and login is non-deterministic and as such something
out of TBot's control.  We can work around this by allowing the login and
password prompts to be in the middle of other messages.  I don't think we need
some ^C solution for that, because the board should send the login prompt at
least once by itself.

After logging in, we need to prevent clobber as much as possible.  I am not
sure what is the best solution for that, my idea is to use sysctl to disable
logging to the console.  This only works if we have root access though ...

> Yes I vote for adding such a feature.
> 
> bye,
> Heiko

-- 
Harald

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-62  Fax: +49-8142-66989-80   Email: hws at denx.de