[tbot] Problem with Linux boot to prompt

[Lukasz Majewski]

Hi Harald,

> Hi Lukasz,
> 
> On Thu, 2019-01-24 at 00:17 +0100, Lukasz Majewski wrote:
> > Dear tbot users,
> > 
> > I'm trying now to boot into Linux prompt (the
> > LinuxStandaloneMachine), and then execute 'uname -a'
> > 
> > The idea is to use boot_to_shell, log in, and execute 'uname -a'
> > https://rahix.de/tbot/module-board.html#tbot.machine.board.LinuxStandaloneMachine.boot_to_shell
> > 
> > Test case:
> > 
> > @tbot.testcase
> > def linux_uname(
> >     lab: typing.Optional[linux.LabHost] = None,
> >     board_linux: typing.Optional[board.LinuxStandaloneMachine] =
> > None, ) -> None:
> >     with contextlib.ExitStack() as cx:
> >         if board_linux is None:
> >             lh  = cx.enter_context(lab or tbot.acquire_lab())
> >             b   = cx.enter_context(tbot.acquire_board(lh))
> >             lnx = cx.enter_context(tbot.acquire_linux(b))
> >         else:
> >             lnx = board_linux
> > 
> >         lnx.boot_to_shell('root at display5:~# ')
> >         lnx.exec0("uname", "-a")
> >   
> 
> Hmm, you are not supposed to call `boot_to_shell` yourself.
> This is done internally when you enter the machine context:
> 
> 	lnx = cx.enter_context(tbot.acquire_linux(b))
> 
> Which is equivalent to this:
> 
> 	with tbot.acquire_linux(b) as lnx:
> 	    ...
> 
> If you are curious, the call happens here:
> 
> 	https://github.com/Rahix/tbot/blob/master/tbot/machine/board/linux.py#L288
> 
> I guess, I should mention this in the docs ...

Apparently I do understand things in a different way :-) (Or I'm biased
by other tests systems, which I've been using).

> 
> > (For simplicity I'm using the Linux Standalone Machine).
> > 
> > The output of -vvv:
> > 
> > │   │    <> 
> > │   │    <> 
> > │   ├─> 'root\n'
> > │   ├─< 'root\r\n'
> > │   │    <> display5 login: root
> > │   ├─< '\x1b7\x1b[r\x1b[999;999H\x1b[6n'
> > │   ├─< 'root at display5:~# '
> > 
> > The 'root at display5:~# ' is sent to the "channel", but there is no
> > reaction on it (I'm using picocom -b 115200 /dev/ttyUSB0 to handle
> > serial console).
> > Do I need to use regexp here ?
> >   
> 
> As stated above, you do not need to do anything.  tbot waits for the
> login prompt,

Ok. Se tbot waits for "display5 login:" and then send root.

> send username and optionally a password and then has a
> more or less sophisticated way of determining if the shell popped up.

From the above -vvv output, it seems like:

'\x1b7\x1b[r\x1b[999;999H\x1b[6n'
'root at display5:~# '

are received (but not displayed if -v or -vv is specified).
It seems like tbot has logged into the system's shell.

The problem in my case is that the test case hangs in this place and 
"uname -a" is not sent.

May the problem be with that I'm using "dash", but tbot now only
supports 'ash' and 'bash' ?


> As soon as it has, it will force the shell into a known state and
> give control back to your testcase to run commands.  If your config
> is correct, simply removing the `boot_to_shell` line should do the
> trick.

The board hangs as presented in the -vvv output above. Only Ctrl+C
works and the board is powered off.

> 
> > 
> > A side question(s):
> > -------------------
> > 
> > 1. Is it possible to return value from test case to make it fail?
> > 
> > For example - I do lnx.exec0() then do some work on text received
> > and on that basis I would like to make the test pass or fail.
> > Similar use case is with parsing 'dmesg' output.
> >   
> 
> A testcase fails if it raises an Exception.  If you want to manually
> create a failure:
> 
> 	if "bad output" in lnx.exec0("cat", "/var/log/syslog"):
> 	    raise Exception("Found bad output!")

Ok. So no exception is -> OK , with Exception -> ERROR

Just for the future consideration - other frameworks also allows other
results for tests - like SKIP,

> 
> > 
> > 2. Do we have any timeout of booting u-boot/kernel? 
> > 
> > A very common test case is to check if the board still boots after
> > update of SPL/u-boot/linux. I can hack some in-test case timeout
> > (and pass with -p the value), but maybe there is a better way?  
> 
> Sadly not yet.  Normal command execution (like exec(), exec0()) can
> take a timeout parameter, but boot does not have this functionality
> yet.
> 
> If you need this right now, you can use this hack:
> 
> 	import signal
> 
> 	def handler(_signum, _frame):
> 	    """ Signal handler for timeout """
> 	    raise TimeoutError()
> 
> 	# in your testcase
> 	signal.signal(signal.SIGALRM, handler)
> 
> 	# timeout 60 seconds
> 	signal.alarm(60)
> 	try:
> 	    # Do your things here
> 	    ...
> 	except TimeoutError:
> 		tbot.log.message("Aborting run because it took too
> long.")
> 

Ok. Thanks

> > (If anybody has such functionality, please share :-) )
> > 
> > Thanks in advance for your help.
> > 
> > Best regards,
> > 
> > Lukasz Majewski
> >   




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/tbot/attachments/20190124/e5cff3af/attachment.sig>