[SRU justification]
The switch from upstart to systemd in 15.10 has left the ppc64-diag package's daemons not correctly autostarting on boot. This prevents the proper operation of the package's functionality.
[Regression potential]
Because we are now running code that was previously not being autorun on Ubuntu 15.10, regressions are possible. However, this same upstream version of code is also included in trusty-updates and vivid-updates, where the services do correctly autostart because those releases use upstart rather than systemd, and there are no reports of problems against them.
[Test case]
1. Install ppc64-diag on wily. Confirm that the opal service is not running:
$ systemctl status opal_errd.service
opal_errd.service - opal_errd (PowerNV platform error handling) Service
Loaded: loaded (/usr/lib/systemd/system/opal_errd.service; disabled; vendor preset: enabled)
Active: inactive (dead)
2. Install ppc64-diag from wily-proposed. Confirm that the opal service is now running.
[Original bug report]
== Comment: #0 - Application Cdeadmin <email address hidden> - 2015-09-19 18:46:05 ==
== Comment: #1 - Application Cdeadmin <email address hidden> - 2015-09-19 18:46:07 ==
==== State: Open by: belldi on 19 September 2015 17:35:01 ====
Headline
++++++++++
Surelock: GA2: z138e: System and FSP dumps are not moving from FSP to Ubuntu 15.10 partition during continous user dump test, TER 93148
Note(s)
++++++
This system is in use for Surelock GA2 Hardware Systems Test. You should contact the system tester or defect submitter before performing any disruptive actions.
Problem Description
++++++++++++++++++++
On Ubuntu 15.10 partition, I created directory /var/log/dump and installed the ppc64-diag package. I ran following commands to complete both tasks.
sudo mkdir /var/log/dump #Create dump directory
sudo apt-get install ppc64-diag #install PPC64 diagnostic package
Afterwards, I ran HTX to exercise the hardware in system, specifically focused on exercising between Corsa-CAPI cards and the flash system. Then, I started TER 93148 for continuous user dump. For TER 93148, I ran a script that continuously intiates a USER dump about every 2 hours. The system dump and fsp dump are expected to move from FSP to Ubuntu partition after system reaches runtime and boots the Ubuntu partition. However, the system and FSP dumps aren't getting moved from the FSP to the Ubuntu partition.
System and FSP dumps still present on FSP
Not getting moved to ubuntu partition despite
creating /var/log/dump/ and installing ppc64-diag
on ubuntu partition
++++++++++++++++++++++++++++++++++++++++++++++
$ rtim timeofday
System time is valid: 2015/09/19 22:05:14.744413 <-- GMT time
mchollin@cougarp01:~$ sudo systemctl status opal_errd.service
● opal_errd.service - opal_errd (PowerNV platform error handling) Service
Loaded: loaded (/usr/lib/systemd/system/opal_errd.service; disabled; vendor preset: enabled)
Active: inactive (dead)
mchollin@cougarp01:~$ sudo systemctl enable opal_errd.service
Synchronizing state of opal_errd.service with SysV init with /lib/systemd/systemd-sysv-install...
Executing /lib/systemd/systemd-sysv-install enable opal_errd
Created symlink from /etc/systemd/system/multi-user.target.wants/opal_errd.service to /usr/lib/systemd/system/opal_errd.service.
mchollin@cougarp01:~$ sudo systemctl status opal_errd.service
● opal_errd.service - opal_errd (PowerNV platform error handling) Service
Loaded: loaded (/usr/lib/systemd/system/opal_errd.service; enabled; vendor preset: enabled)
Active: inactive (dead)
mchollin@cougarp01:~$
The unit is "disabled" initially, and then after i manually run "enable" it becomes "enabled." This seems to indicate that the debs that we installed aren't quite doing the right things after their installation. This is a bug that needs to go to launchpad for fix out in ubuntu - not something that's specific to surelock.
It's a good find either way.
== Comment: #16 - Application Cdeadmin <email address hidden> - 2015-10-09 17:16:04 ==
==== State: Open by: belldi on 09 October 2015 16:05:27 ====
I'm reopening defect. Issue isn't resolved yet.
== Comment: #17 - Stewart Smith <email address hidden> - 2015-10-09 18:17:41 ==
Moving to BugsAgainstDistros for Ubuntu.
== Comment: #18 - Application Cdeadmin <email address hidden> - 2015-10-11 22:25:07 ==
==== State: Open by: belldi on 11 October 2015 12:48:45 ====
#=#=# 2015-10-11 12:48:44 (CDT) #=#=#
Action = [reopen]
#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#
==== State: Open by: mchollin on 11 October 2015 15:07:41 ====
#=#=# 2015-10-11 15:07:30 (CDT) #=#=#
#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#
==== State: Open by: mchollin on 11 October 2015 15:08:37 ====
#=#=# 2015-10-11 15:08:36 (CDT) #=#=#
#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#
==== State: Open by: mchollin on 11 October 2015 21:22:39 ====
Summary: ppc64-diag, when installed on Ubuntu 15.10 does not automatically "enable" the opal_errd daemon. This means that opal_errd, while installed, does not actually -start- on boot.
LTC - please move this to the appropriate component (launchpad? elsewhere?) so that the ppc64-diag package for Ubuntu 15.10 can make a fix for this. Probably any other distro that relies on systemd should be checked as well to make sure all expected daemons actually -start- when ppc64_diag is installed.
------- Comment From <email address hidden> 2015-10-12 06:21 EDT-------
#=#=#=#
#=#=#=#
#=#=#=#
== Comment: #18 - Application Cdeadmin <email address hidden> - 2015-10-11 22:25:07 ====== State: Open by: belldi on 19 September 2015 17:35:01 ====
== Comment: #16 - Application Cdeadmin <email address hidden> - 2015-10-09 17:16:04 ====== State: Open by: cde00 on 12 October 2015 01:21:01 ====