Hi,
In LAVA v1, one could declare login commands to be run after logging in and before starting any of the tests. For example:
"actions": [ { "command": "deploy_image", "parameters": { "image": "https://some-url-to-a-rootfs.ext4.img.gz", "bootfstype": "ext2", "login_commands": [ "sudo su" ], "login_prompt": "login:", "username": "username", "password_prompt": "Password:", "password": "password" } },
In this case, "sudo su" is needed to open a regular user session and inherit the user's environment while also having root privileges.
In LAVA v2, there isn't the possibility to do anything like this directly. One could define a test with inline commands, but this is not ideal. The login commands are not a test but part of how the job sets up the environment in which the tests are run - i.e. it's part of the initial conditions. Also it's quite a convoluted and lengthy way of running some commands, and it relies on the side effects of that "login commands test" to persist when running subsequent tests.
So I've made a couple of patches to see how this could be implemented in LAVA v2 with an extra parameter in auto_login:
https://review.linaro.org/#/q/topic:T5703-login-commands
For example:
- boot: method: qemu auto_login: login_prompt: 'login:' username: user password_prompt: 'Password:' password: password login_commands: - sudo su
Essentially, this makes auto_login more flexible. At the moment, after logging in auto_login sets the shell prompt: this is already some kind of hard-coded login command. Some jobs need to run other things such as "sudo su" to stick to the same example.
Another login command we've used is "systemctl --failed" to show if any systemd units (services) failed to load during boot.
Notes from the Gerrit reviews:
* The login commands can't be part of a device definition as they are not related to the device hardware or the boot configuration. For example, when running Android, one would not want to run "sudo su" but maybe "setprop ..." or something else - to be defined in each job.
* The login commands should not be fixed in a given distro / userspace configuration as each job may need to set up a different initial environment. For example, some jobs may need to be run with a regular user and would not use the "sudo su" login command.
* Some documentation and unit tests would need to be added for this to be merged. This is to first discuss the idea and review the code changes.
Any thoughts? Would it make sense to add this feature or maybe implement it differently?
Best wishes, Guillaume