Project

General

Profile

Bug #12040

Bug #10288: Fix newly identified issues to make our test suite more robust and faster

Test suite cannot sometimes connect to the remote shell: "Dropped out-of-order remote shell response: got id but expected id NNNN"

Added by intrigeri over 2 years ago. Updated 18 days ago.

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Test suite
Target version:
-
Start date:
12/19/2016
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

  Scenario: Installing an old version of Tails to a pristine USB drive # features/usb_upgrade.feature:51
    Given a computer                                                   # features/step_definitions/common_steps.rb:122
    And the computer is set to boot from the old Tails DVD             # features/step_definitions/usb.rb:67
    And the network is unplugged                                       # features/step_definitions/common_steps.rb:163
    And I start the computer                                           # features/step_definitions/common_steps.rb:189
[log] CLICK on (1024,384)
[log] TYPE "    " 
[log] TYPE " autotest_never_use_this_option blacklist=psmouse 
" 
calling as root: echo 'hello?'
Dropped out-of-order remote shell response: got id  but expected id 1280
calling as root: echo 'hello?'
Dropped out-of-order remote shell response: got id  but expected id 1281
calling as root: echo 'hello?'
Dropped out-of-order remote shell response: got id  but expected id 1282
calling as root: echo 'hello?'
Dropped out-of-order remote shell response: got id  but expected id 1283
calling as root: echo 'hello?'
Dropped out-of-order remote shell response: got id  but expected id 1284
calling as root: echo 'hello?'
Dropped out-of-order remote shell response: got id  but expected id 1285
calling as root: echo 'hello?'
Dropped out-of-order remote shell response: got id  but expected id 1286
calling as root: echo 'hello?'
Dropped out-of-order remote shell response: got id  but expected id 1287
calling as root: echo 'hello?'
Dropped out-of-order remote shell response: got id  but expected id 1288
calling as root: echo 'hello?'
Dropped out-of-order remote shell response: got id  but expected id 1289
calling as root: echo 'hello?'
Dropped out-of-order remote shell response: got id  but expected id 1290
calling as root: echo 'hello?'
Dropped out-of-order remote shell response: got id  but expected id 1291
calling as root: echo 'hello?'
Dropped out-of-order remote shell response: got id  but expected id 1292
calling as root: echo 'hello?'
Dropped out-of-order remote shell response: got id  but expected id 1293
calling as root: echo 'hello?'
Dropped out-of-order remote shell response: got id  but expected id 1294
calling as root: echo 'hello?'
Dropped out-of-order remote shell response: got id  but expected id 1295
calling as root: echo 'hello?'
Dropped out-of-order remote shell response: got id  but expected id 1296
calling as root: echo 'hello?'
Dropped out-of-order remote shell response: got id  but expected id 1297
calling as root: echo 'hello?'
Dropped out-of-order remote shell response: got id  but expected id 1298
calling as root: echo 'hello?'
Dropped out-of-order remote shell response: got id  but expected id 1299
calling as root: echo 'hello?'
Dropped out-of-order remote shell response: got id  but expected id 1300
calling as root: echo 'hello?'
Dropped out-of-order remote shell response: got id  but expected id 1301
calling as root: echo 'hello?'
Dropped out-of-order remote shell response: got id  but expected id 1302
    When the computer boots Tails                                      # features/step_definitions/common_steps.rb:278
      Remote shell seems to be down
      Last ignored exception was: Timeout::Error: execution expired (Timeout::Error)
      ./features/support/helpers/misc_helpers.rb:83:in `rescue in try_for'
      ./features/support/helpers/misc_helpers.rb:33:in `try_for'
      ./features/support/helpers/exec_helper.rb:16:in `wait_until_remote_shell_is_up'
      ./features/support/helpers/vm_helper.rb:453:in `wait_until_remote_shell_is_up'
      ./features/step_definitions/common_steps.rb:292:in `/^the computer (re)?boots Tails$/'
      features/usb_upgrade.feature:56:in `When the computer boots Tails'
    And I log in to a new session                                      # features/step_definitions/common_steps.rb:297
    And all notifications have disappeared                             # features/step_definitions/common_steps.rb:439
    And I create a 4 GiB disk named "old"                              # features/step_definitions/common_steps.rb:139
    And I plug USB drive "old"                                         # features/step_definitions/common_steps.rb:145
    And I "Clone & Install" Tails to USB drive "old"                   # features/step_definitions/usb.rb:118
    Then the running Tails is installed on USB drive "old"             # features/step_definitions/usb.rb:273
    But there is no persistence partition on USB drive "old"           # features/step_definitions/usb.rb:287
    And I unplug USB drive "old"                                       # features/step_definitions/usb.rb:63
      Scenario failed at time 01:17:18

It seems weird that "got id" is not followed by an actual ID.


Related issues

Related to Tails - Bug #11846: The remote shell can mix up responses after an execution has been aborted Resolved 09/27/2016
Related to Tails - Bug #11892: Sometimes the remote shell doesn't start because of missing initial Space when modifying the kernel cmdline In Progress 10/31/2016

History

#1 Updated by intrigeri over 2 years ago

  • Related to Bug #11846: The remote shell can mix up responses after an execution has been aborted added

#2 Updated by u about 1 year ago

  • Related to Bug #11892: Sometimes the remote shell doesn't start because of missing initial Space when modifying the kernel cmdline added

#3 Updated by intrigeri 18 days ago

FTR, this happened 300 times in the 1051 test suite runs for which we have a debug.log on Jenkins today. I've taken a look at a few of those and it seems this did not prevent the scenarios from passing.

Also available in: Atom PDF