I've used an old Acer Travelmate 4000 laptop as my local server for ages with Ubuntu Desktop.
This year, I installed 16.04 i386 Server Edition and couldn't be happier. The entire working set of Linux, network stack and apache2 uses only 37MB of the 2GB onboard… No Swap For You!
Trouble is, issuing a reboot (or shutdown) command always hangs at the same point at the console: 'Reached target Shutdown', requiring a hard power off and restart.
What can I can do to diagnose this further?
UPDATE: Per suggestion, I keyed commands on the console under sudo to 'systemctl start debug-shell' followed by a 'reboot'.
However, this vanilla server lacks a window manager, so when the final console message 'Reached target Shutdown' appears, no keystroke combination is able to spawn a VT and list any failed jobs. The Alt+SysRq incantation is also ineffective at continuing the reboot.
Anyway, there is now a new last-gasp message line which reads: "[278.430967] systemd-shutdown: Failed to finalize DM devices. ignoring"
I tried the workaround to disable swap space during shutdown in a similar bug report, but it didn't help; probably because my 3GB swapfile is unused and /tmp usage is minimal (~2%).
Is there anything else I can try to move the markers forward here?
UPDATE 2: Capturing the output of the suggested journalctl and systemctl commands to a file yielded nothing out of the ordinary.
Since there's no GUI on this server, I used this github code to enable Xenial Proposed before updating/upgrading/rebooting to ensure the new systemd-229 was in the mix.
Sadly, it made no difference. I don't know if it's related, but I took the option at Ubuntu installation time to use default LVM Volume Groups for /boot, /home, /var, /tmp and swap.
Am I really the only one seeing this problem?
(Here's a screenshot of the console after issuing a reboot, plus waiting another 3 minutes or so):
Best Answer
Who knows when/if this problem: "systemd-shutdown: Failed to finalize DM devices. ignoring." will ever be fixed on this old platform - nothing I've read would suggest it'll be anytime soon.
In the meantime, this work-around allows me to reboot my server without physically power cycling the machine.
All the following commands are under sudo:
echo 1 > /proc/sys/kernel/sysrq sync && echo b > /proc/sysrq-triggerIf running the script remotely via ssh, I find I also need to hard close my ssh window and re-establish a new ssh session (after waiting a minute for the machine to become reachable).