Comment 0 for bug 1505088

== 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
&#9679; 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
&#9679; 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.