All, After bandaiding my server back together by putting a 4-port pci-sata controller in it to work around the failed onboard disk controller, the system is up and running fine. In the BIOS, currently the onboard sata controller is 'Enabled', but each of the sata ports is 'Disabled'. When I check the status of something with systemclt, I get an odd error at the end of each command, eg: [15:47 phoinix:~/.ssh] # sc status smbd ● smbd.service - Samba SMB/CIFS server Loaded: loaded (/usr/lib/systemd/system/smbd.service; enabled; vendor preset: disabled) Active: active (running) since Sat 2015-08-22 22:57:26 CDT; 1 day 16h ago Main PID: 542 (smbd) CGroup: /system.slice/smbd.service ├─542 /usr/bin/smbd -D └─559 /usr/bin/smbd -D Bus error (core dumped) Looking at the journal and looking at the core dumps, the only other process that is implicated is: Cannot add dependency job for unit cups.socket, ignoring: Unit cups.socket failed to load: No such file or directory. Nothing else is generating a core dump. But each time I check the status of a process, it ends with: Bus error (core dumped) The only other thing I see in the journal that may or may not be related is: Aug 24 14:21:58 phoinix systemd[13187]: pam_unix(systemd-user:session): session opened for user root by (uid=0) Aug 24 14:21:58 phoinix systemd[13187]: Unit type .busname is not supported on this system. I don't know if that's related, but it was the only thing else tangentially related to 'bus'. Looking at the core dump list with 'coredumpctl list' show a handful of files: [17:46 phoinix:~/.ssh] # coredumpctl list TIME PID UID GID SIG PRESENT EXE Mon 2015-04-06 19:00:15 CDT 342 0 0 11 /usr/bin/cupsd Tue 2015-05-26 13:15:01 CDT 23265 0 0 11 /usr/bin/crond Tue 2015-05-26 14:01:01 CDT 23563 0 0 11 /usr/bin/crond Tue 2015-05-26 14:05:01 CDT 23593 0 0 11 /usr/bin/crond Sun 2015-08-23 05:51:43 CDT 3151 0 0 7 * /usr/bin/systemctl Sun 2015-08-23 05:52:16 CDT 3179 0 0 7 * /usr/bin/systemctl Sun 2015-08-23 07:11:33 CDT 3639 0 0 7 * /usr/bin/systemctl Sun 2015-08-23 07:12:31 CDT 3652 0 0 7 * /usr/bin/systemctl Mon 2015-08-24 15:30:11 CDT 13565 0 0 7 * /usr/bin/systemctl Mon 2015-08-24 15:32:05 CDT 13580 0 0 7 * /usr/bin/systemctl Mon 2015-08-24 15:53:37 CDT 13696 0 0 7 * /usr/bin/systemctl Looking at the dumps in gdb shows: [17:47 phoinix:~/.ssh] # coredumpctl gdb 13696 PID: 13696 (systemctl) UID: 0 (root) GID: 0 (root) Signal: 7 (BUS) Timestamp: Mon 2015-08-24 15:53:37 CDT (1h 54min ago) Command Line: systemctl status smbd Executable: /usr/bin/systemctl Control Group: /user.slice/user-1000.slice/session-c2.scope Unit: session-c2.scope Slice: user-1000.slice Session: c2 Owner UID: 1000 (david) Boot ID: aeecdf7479ea4b43aae7f1b9b83b2502 Machine ID: 8d32bcc3152b4a1f87c4d71f948f93fb Hostname: phoinix Coredump: /var/lib/systemd/coredump/core.systemctl.0.aeecdf7479ea4b43aae7f1b9b83b2502.13696.1440449617000000.lz4 Message: Process 13696 (systemctl) of user 0 dumped core. <snip> (gdb) bt #0 0x00007f353981becf in ?? () #1 0x00007f3539801c09 in ?? () #2 0x00007f3539801d38 in ?? () #3 0x00007f3539801b64 in ?? () #4 0x00007f3539801d38 in ?? () #5 0x00007f3539801b64 in ?? () #6 0x00007f353980310e in ?? () #7 0x00007f35397f4080 in ?? () #8 0x00007f353983340b in ?? () #9 0x00007f35397ed1d1 in ?? () #10 0x00007f35397e2414 in ?? () #11 0x00007f35386f5790 in __libc_start_main () from /usr/lib/libc.so.6 #12 0x00007f35397e3049 in ?? () (gdb) frame 0 #0 0x00007f353981becf in ?? () (gdb) info frame Stack level 0, frame at 0x7ffed3907080: rip = 0x7f353981becf; saved rip = 0x7f3539801c09 called by frame at 0x7ffed3907160 Arglist at 0x7ffed3906fd8, args: Locals at 0x7ffed3906fd8, Previous frame's sp is 0x7ffed3907080 Saved registers: rbx at 0x7ffed3907048, rbp at 0x7ffed3907050, r12 at 0x7ffed3907058, r13 at 0x7ffed3907060, r14 at 0x7ffed3907068, r15 at 0x7ffed3907070, rip at 0x7ffed3907078 (gdb) quit I haven't seen or noticed this happening before, but obviously the first core dump was back in April related to cups. The question is "What should I check?" and "Does any of this look related to BIOS settings and the new disk controller?" (that looks more doubtful after looking over all the information) Anybody have experience with this type thing? -- David C. Rankin, J.D.,P.E.