Hi Milosz,
Thanks for your reply.
Actually let me explain you the situation in detail.
I wanted to implement software update testing in LAVA. Below is the job definition for this. --------------------------------- device_type: qemu job_name: qemu x86_64 software update testing timeouts: job: minutes: 20 action: minutes: 10 actions: power-off: seconds: 60 priority: high visibility: personal notify: criteria: status: finished recipients: - to: method: email email: sai.sathujoda@toshiba-tsip.com context: arch: x86_64 lava_test_dir: '/home/lava-%s' # ACTION BLOCK actions: - deploy: timeout: minutes: 15 to: tmpfs images: system: image_arg: '####' url: #### compression: xz firmware: image_arg: '****' url: **** # BOOT BLOCK - boot: timeout: minutes: 5 method: qemu media: tmpfs prompts: ["####@demo:~#"] auto_login: login_prompt: "demo login:" username: "####" password_prompt: "Password:" password: "####" # TEST_BLOCK - test: timeout: minutes: 5 definitions: - repository: metadata: format: Lava-Test Test Definition 1.0 name: sample-test description: "check reboot version" run: steps: - lava-test-case uname --shell uname -a - cd /home - wget --no-check-certificate -q swupdate_artifact - lsblk - swupdate -i swupdate_artifact - reboot from: inline name: sample-test-1 path: inline/sample-test.yaml - boot: timeout: minutes: 5 method: qemu media: tmpfs prompts: ["####@demo:"] auto_login: login_prompt: "demo login:" username: "####" password_prompt: "Password:" password: "####" - test: timeout: minutes: 5 definitions: - repository: metadata: format: Lava-Test Test Definition 1.0 name: sample-test description: "check partition switch" run: steps: - uname -a - lsblk - reboot from: inline name: sample-test-2 path: inline/sample-test.yaml
context: arch: x86_64 lava_test_results_dir: '/home/lava-%s' -------------------------------
If the reboot after successful swupdate does not cause any kernel panic, then the reboot is working fine, I am able to see the persistent changes in the root file system and no matter how many reboot i explicitly trigger in the job definition, i am not facing any issue.
But the problem here is, in case if the swupdate actually leads to a kernel-panic situation during reboot, then after 60s of watchdog timeout, a reboot is triggered by the watchdog as I mentioned earlier. Even then I have found no issues in booting kernel, setting up of all services and root file system, but the auto login failed because all the actions I have written after the watchdog reboot are not working.
So do you think this can be fixed on LAVA side or is this something LAVA is not ready to support ?
Is some work going on LAVA development side to fix this issue ? In case if you are have no info on this, do you think asking this in lava-dev mailing list might help ?
Thanks, Sai Ashrith