Comment 47 for bug 138691

A long row of boot/shut-down cycles with varying parameters got me a bit closer to the solution:

All the machines we use have static NFS mounts for some additional directories in /usr/local plus automounted home directories (also via NFS). I haven't experimented with the home directories yet (all tests were run using a local user), but I discovered this:
If I manually unmount the static NFS mounts prior to shutting down, the shutdown will succeed. Further investigation showed that the shutdown actually hangs in umountnfs.sh (/etc/rc0.d/S31umountnfs.sh) right at the "umount" command. Hence, something has happened previously during the shutdown process that prevents the "umount" from succeeding.

I went even further and added a custom script to /etc/rc0.d to investigate at which point "umount" would fail to work. Unmounting of the static NFS shares worked fine until after sendsignals (/etc/rc0.d/S20sendsignals) has been run, i.e. I can add a script at S19.... or any of the K... levels that unmounts the NFS shares and it will succeed. If I add it as S21... or higher, it will hang at "umount", just like the umountnfs.sh script does. It looks like "sendsignals" kills something that is vital to unmounting the NFS shares (NetworkManager?!).
However, this does not explain why there is a difference between initiating shutdown from within KDE/kdm and running "shutdown -P now" from the console. For that, I have no idea whatsoever...

Now that I can design a workaround for this, I will have a look at the automounted directories...