Feature #8262

Automatically test that all services have started correctly

Added by intrigeri 2014-11-13 22:58:05 . Updated 2015-09-26 07:06:14 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Test suite
Target version:
Start date:
2014-11-13
Due date:
% Done:

100%

Feature Branch:
kytv:test/8262-system-is-ready
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

systemctl is-system-running, run as root, should succeed.


Subtasks


Related issues

Related to Tails - Bug #9393: Improve systemd boot semantics of tails-wait-until-tor-has-bootstrapped.service Resolved 2015-05-13

History

#1 Updated by kytv 2014-11-24 22:56:11

  • Assignee set to kytv

Will try once I can make a working Jessie build.

#2 Updated by intrigeri 2014-12-18 11:39:13

Any news on that one? (Hopefully you now have enough RAM to take care of it :)

#3 Updated by kytv 2014-12-20 17:48:45

Yes, the RAM part’s not an issue anymore (thanks!), but I consistently get the “Oh no! Something has gone wrong” screen and need to figure out why (and I don’t know anything about GNOME 3). I also need to try booting the Jessie iso on ‘bare metal’.

For the record, the ISO I’m working with was built by jenkins:

789499f435df3202be3395d4650c2d346dd91d521c2dc21f7f2467822cf4c17d *tails-i386-feature_jessie-1.3-20141218T0512Z-a5b78e1.iso

#4 Updated by intrigeri 2014-12-21 10:06:47

> I consistently get the “Oh no! Something has gone wrong” screen

In GDM or after login?

> I also need to try booting the wheezy iso on ‘bare hardware’.

You mean Jessie, right?

> For the record, the ISO I’m working with was built by jenkins:
>

> 789499f435df3202be3395d4650c2d346dd91d521c2dc21f7f2467822cf4c17d *tails-i386-feature_jessie-1.3-20141218T0512Z-a5b78e1.iso
> 

An ISO built yesterday (locally) from commit 3a16e4e5 boots fine here,
and allows me to log in.

#5 Updated by kytv 2014-12-22 23:16:40

intrigeri wrote:
> > I consistently get the “Oh no! Something has gone wrong” screen
>
> In GDM or after login?

After login.

> > I also need to try booting the wheezy iso on ‘bare hardware’.
>
> You mean Jessie, right?

Oof. Yes, Jessie. (I updated the comment above with the correct info).

> > For the record, the ISO I’m working with was built by jenkins:
> > […]
>
> An ISO built yesterday (locally) from commit 3a16e4e5 boots fine here,
> and allows me to log in.

I’ll try building a newer one and/or trying with a newer one from jenkins, as well as making sure my test VM is up-to-date.

#6 Updated by kytv 2015-01-05 22:12:34

So….

I continued to consistently get the “Oh no screen” even when booting the Jessie ISO in KVM /outside/ of the test suite. I enabled an option in my BIOS called ‘Unleashing Mode’ and now I can login to the desktop in a libvirt-managed KVM session. Running with “kvm -m 2048 -cdrom /path/to/ISO” still leads to the “Oh no” screen after login.

In the test suite I consistently get the “Oh no” screen. I guess it may be video related but don’t have any data/proof to back that up with. Yet.

#7 Updated by kytv 2015-05-13 01:19:02

  • Status changed from Confirmed to In Progress
  • Assignee changed from kytv to intrigeri
  • QA Check set to Ready for QA
  • Feature Branch set to kytv:test/8262-system-is-ready

intrigeri wrote:
> systemctl is-system-running, run as root, should succeed.

This doesn’t appear to be the case if the network isn’t plugged. Instead you get starting and an exit status of 1. I suppose it’s because of

tails-wait-until-tor-has-bootstrapped.service                                       loaded activating start     start Wait for Tor to Have Bootstrapped

This being the case I added the check to the Tor is ready step.

diff --git a/features/step_definitions/common_steps.rb b/features/step_definitions/common_steps.rb
index d2f8037..30b50c7 100644
--- a/features/step_definitions/common_steps.rb
+++ b/features/step_definitions/common_steps.rb
@@ -304,6 +304,8 @@ Given /^Tor is ready$/ do
   next if @skip_steps_while_restoring_background
   step "Tor has built a circuit"
   step "the time has synced"
+  assert(@vm.execute('systemctl is-system-running').success?,
+         'At least one system service failed to start.')
 end

 Given /^Tor has built a circuit$/ do

IIRC (I can’t find the email) I was requested to assign this to intrigeri once it was taken care of.

#8 Updated by intrigeri 2015-05-13 08:08:46

  • related to Bug #9393: Improve systemd boot semantics of tails-wait-until-tor-has-bootstrapped.service added

#9 Updated by intrigeri 2015-05-13 08:12:00

> I suppose it’s because of

>

> tails-wait-until-tor-has-bootstrapped.service                                       loaded activating start     start Wait for Tor to Have Bootstrapped
> 

Correct, good catch! I’m not sure that what I’ve implemented has the correct semantics, though => I’ve just filed Bug #9393.

> This being the case I added the check to the Tor is ready step. […]

OK, excellent. I suppose that’s the best we can do until the targets/units semantics issue I’m raising above is resolved. I’ll test this and merge once happy :)

#10 Updated by kytv 2015-05-16 09:01:54

Applied in changeset commit:c83479d2381c3dc2871d02f75f04d49d8f18a5a9.

#11 Updated by intrigeri 2015-05-16 09:01:55

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Applied in changeset commit:b6d6248606c9f4bf2674732606b732a14ff263ae.

#12 Updated by intrigeri 2015-05-16 09:02:32

  • Assignee deleted (intrigeri)
  • QA Check changed from Ready for QA to Pass

Merged, thanks!

#13 Updated by anonym 2015-09-26 07:06:14