Possible bug when auto login is used on the device

[Hvunt]

Hello.

I have a problem with a case when a board uses an autologin. read_until_prompt method doesn't work if the device keeps sending logs.
For example, if we set login_promt like this ~ # and the input bytearray will become like this ~ # [ 10.364872] startup_sh[0]: IP is: 192.168.80.254 the method will just ignore the string.

My suggestion is to replace endwith with find here

Please, guide me if I'm wrong.

[Rahix]

Hi,

this is the age-old console log clutter issue. The solution is to set your login_prompt to something that allows for additional characters. Then, you also set a login_delay which waits for all this clutter to pass by before starting shell interaction. Overall, something like this should work:

    # Allow clutter after the login prompt
    login_prompt = tbot.Re(r"~ # .{0,100}")
    # Wait for 2 seconds until all messages have been printed
    login_delay = 2

Let me know if this works!

[MihaiGruieti1]

@Rahix main problems I see with your solution:

1. timming for the "clutter" passing might be diffrent, depending on software changes which affect the startup traces that are dumpped to std out
2. cyclic traces, in many cases includign ours there are traces which are dumpeed cyclically to the std out, sometime with no predictable timing from one test setup to the other,

[Rahix]

@MihaiGruieti1, sorry for the delayed response. Your points are absolutely valid - however there is not really anything we can do about that. tbot expects a clean console which isn't interrupted by random trace messages. It would be impossible to build a robust console parser which can deal with such random clutter.

Instead, it is your duty to provide such a clean console. My suggestion above is a workaround for situations where you can't change the kernel config for a silent console. In similar spirit, another workaround is to immediately send a
sysctl kernel.printk="1 1 1 1" command after login to effectively disable the kernel traces as well. But ideally, you should configure your system to not dump kernel log messages into the userspace console in the first place.