Feature #8262
Automatically test that all services have started correctly
100%
Description
systemctl is-system-running
, run as root, should succeed.
Subtasks
Related issues
Related to Tails - |
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
- Parent task set to Feature #10277