1. 10 Jul, 2019 1 commit
    • Harald Sitter's avatar
      force a timeout on x11 start program · e4f712cb
      Harald Sitter authored
      in master krunner is now delayed until first use meaning the first use
      startup can take a while. make sure to wait more than a single screenshot
      for krunner to appear. otherwise we might type too soon and lose input
  2. 04 Jul, 2019 1 commit
  3. 17 May, 2019 2 commits
  4. 15 May, 2019 1 commit
    • Harald Sitter's avatar
      increase wait time for krunner a whole while · 089ace85
      Harald Sitter authored
      when trying to use it right after login the system may still be so busy
      that it doesn't produce results quickly enough. to prevent this from
      happening let's increase the wait a bit.
      this also makes slower systems more likely to pass without additional
  5. 14 May, 2019 1 commit
    • Harald Sitter's avatar
      port away from wait still screen · 0254cdb6
      Harald Sitter authored
      it's long deprecated and internally only a sleep anyway. a fairly long
      sleep though. so use short sleeps instead. it's not ideal but probably the
      least regressive approach to get away from the deprecation
  6. 11 Apr, 2019 2 commits
  7. 25 Sep, 2018 2 commits
  8. 24 Sep, 2018 1 commit
  9. 21 Sep, 2018 1 commit
  10. 14 Sep, 2018 1 commit
    • Harald Sitter's avatar
      unify live session reboots and force reset the system if necessary · 5bb887c9
      Harald Sitter authored
      ISO still get stuck on reboot sometimes. I've tried for days to get this
      properly fixed up now and failed miserably. I am almost entirely certain
      it has to do with dodgy unit order of casper.service, but I can't figure
      out what exactly is wrong or what it should be like. ultimatley
      casper.service is a bit garbage because it needs to run some time between
      plymouth starting and final happening, when exactly is hard to find out
      and also this is shitty to test since the only way to semi reliably
      reproduce it is via openqa.... so, instead simply force a reset of the
      power if the sytem didn't properly reboot after ~20 seconds of us hitting
      enter on the 'hit enter' screen.
      it sucks massively from a test reliability POV, but it's the only way I see
      to prevent flakeyness
  11. 11 Sep, 2018 2 commits
  12. 07 Sep, 2018 4 commits
    • Harald Sitter's avatar
      reduce the wait time for sudo a bit and stop waiting · c9f02d94
      Harald Sitter authored
      this takes screenshots as quickly as it can to decrease time between
      state change and matching making everything faster if a prompt appears.
      at the same time we'll reduce the overall time the prompt has to appear
      from 3 to 2 seconds to make the no-prompt scenario faster as well.
      ultimately this is a bit sucky because of the fact that we cannot really
      tell the two states apart, so we end up waiting when no prompt is going
      to appear anyway, or we wait not long enough when a prompt needs to appear.
      it may be worth considering to switch the qa images to not cache sudo at all
      that we we always know a prompt must appear. then again always having
      to wait for the prompt and entering password may end up slower with
      many sudo calls. all very meh
    • Harald Sitter's avatar
      remove temporary hack · 6eef8215
      Harald Sitter authored
    • Harald Sitter's avatar
      don't wait screen after livetest setup · a455e848
      Harald Sitter authored
      the original assertion is already that we are on the desktop. then we
      switch to a tty, login, do stuff, go back to x11 AND wait 2 seconds.
      if the session isn't ready by the time we come back from all that it's
      unlikely to pass responsiveness expectations the way it is and needs
      time scaling applied to account for the slowness
    • Harald Sitter's avatar
      reduce wait on switching to x11 · 7557ca06
      Harald Sitter authored
      wait_still_screen is internally nothing but a sleep (a longish one), we
      don't really need a long wait for the VT switch. 2 seconds should be
      plenty. if not the run probably should have its timing scale increased
      anyway (i.e. make everything have more leeway because the server is
      slow or whatever)
  13. 06 Sep, 2018 1 commit
  14. 05 Sep, 2018 2 commits
    • Harald Sitter's avatar
      use sysrq correctly · a08632e6
      Harald Sitter authored
      obviously missing the alt if you think about it, i.e. the MAGIC bit of the
      magic sysrq
    • Harald Sitter's avatar
      enable sysrq + add special sysrq debugging when stuck on plymouth · 4eec6b8d
      Harald Sitter authored
      this is special error handling.
      we have persistent problems that reboots get stuck. previous debugging
      attempts via journald didn't give useful results because according to the
      journal the system is shutting down as expected. It's clearly stuck on
      something though.
      so... to debug this we'll try to get as much out of the kernel as possible
      and then crash the system for good measure.
      additionally we'll now enable sysrq all the time since ubuntu's default
      security would disable most of the debugging commands. since we have no
      tests relying on the security being present we may as well just disable it
  15. 04 Sep, 2018 1 commit
  16. 28 Aug, 2018 2 commits
  17. 20 Aug, 2018 4 commits
  18. 06 Aug, 2018 3 commits
  19. 03 Aug, 2018 1 commit
    • Harald Sitter's avatar
      assert evdev in more locations · 6e4949b8
      Harald Sitter authored
      - livetest assertion makes sure we fail early if the ISO isn't using evdev
      - first_start asserts again after installation to make sure the evdev
        default properly applied from the ISO onto the system
  20. 02 Aug, 2018 2 commits
    • Harald Sitter's avatar
      split ttyS1 setup from early first start · 8f97074e
      Harald Sitter authored
      early first start also installs coredumpd. we MUST NOT do this on a live
      system as the apt update will screw up the offline test which partially
      relies on there actually being no internet, not only temporarily!
    • Harald Sitter's avatar
      enable ttyS1 logging for livetests · 304d0f5c
      Harald Sitter authored
      it appears time and again that the livetests get weirdly stuck on reboot
      into the final system. we have next to no useful data at that point in time
      and I have that ttyS1 logging will help us there
  21. 30 Jul, 2018 3 commits
  22. 19 Jul, 2018 1 commit
  23. 25 Jun, 2018 1 commit