I tested it on SLES12-SP2-RC2 and with
63_simplify_systemd_reboot_halt_poweroff_shutdown.sh
I get in the recovery system those scripts:

RESCUE g136:~ # cat /bin/reboot
#!/bin/bash
echo umounting all filesystems
umount -vfar &>/dev/null
echo reboot in 3 seconds...
sleep 3
systemctl --force reboot

RESCUE g136:~ # cat /bin/halt  
#!/bin/bash
echo umounting all filesystems
umount -vfar &>/dev/null
echo halt in 3 seconds...
sleep 3
systemctl --force halt

RESCUE g136:~ # cat /bin/poweroff 
#!/bin/bash
echo umounting all filesystems
umount -vfar &>/dev/null
echo poweroff in 3 seconds...
sleep 3
systemctl --force poweroff

and

RESCUE g136:~ # cat /bin/shutdown 
#!/bin/bash
command=poweroff
for arg in "$@" ; do
    case "$arg" in
        (-r|--reboot) command=reboot ;;
        (-H|--halt)   command=halt ;;
    esac
done
$command

which seem to work well for me according to my very first tests.

Hmm - I think running umount verbose but then
send all to /dev/null is not yet the ultimate solution...

Now I umount actually verbosely.

The more I use it, the more I like it.
At least for me it seems to "just work".
But I didn't test on a non-systemd machine.

@gdha
please do not yet merge it - I like to add some enhancements
to make 63_simplify_systemd_reboot_halt_poweroff_shutdown.sh
work more fail safe.

Furthermore I ask for feedback if you like my verbose umounting
or if I should umount silently?

Personally I prefer verbosity (in contrast to the traditional Unix
behaviour "no news is good news") because I like to see feedback
from the computer that it is actually doing something and what that is
(even if that feedback is low-level technical gibberish that I do not
really understand like kernel boot messages and things like that).

Something is wrong with the test if systemd is not used

test -d $ROOTFS_DIR/usr/lib/systemd/system || return 0

that I copied from
build/GNU/Linux/61_verify_and_adjust_udev_systemd.sh
but therin is no comment that explains what that test
is about so that I probably misunderstood its meaning, cf.
https://github.com/rear/rear/wiki/Coding-Style

I tested on a non-systemd machine (SLES11-SP4) in my case
and I got a $ROOTFS_DIR/usr/lib/systemd/system directory.

I.e. it seems in the rear recovery system there is a
/usr/lib/systemd/system directory regardless
whether or not systemd is used?

...investigating...

It seems the test if systemd is used in
prep/GNU/Linux/28_include_systemd.sh
is the right one:

if ps ax | grep -v grep | grep -q systemd ; then

Furthermore it seems
usr/share/rear/build/GNU/Linux/10_copy_as_is.sh
copies the content of skel/default/usr/lib/systemd/system
into the rear recovery system regardless
whether or not systemd is actually used
which raises the question what adds that to the COPY_AS_IS
array regardless whether or not systemd is actually used...

It is not 10_copy_as_is.sh that copies the content
of skel/default/usr/lib/systemd/system
into the rear recovery system, it is
rescue/default/01_merge_skeletons.sh
that copies the content of skel/default/
into the rear recovery system.

This way the rear recovery system becomes 236K bigger
than actually needed when no systemd is used

$ du -hsc $( find usr/share/rear/skel/default/ | grep systemd )
16K     usr/share/rear/skel/default/etc/systemd
12K     usr/share/rear/skel/default/run/systemd
196K    usr/share/rear/skel/default/usr/lib/systemd
12K     usr/share/rear/skel/default/var/run/systemd
236K    total

but that is a different issue.

I fixed the test if systemd is used.
Now I use

# Skip if systemd is not used.
# Because the scripts below need the systemctl executable and because
# via prep/GNU/Linux/28_include_systemd.sh and build/GNU/Linux/10_copy_as_is.sh
# systemctl gets only copied into the recovery system if systemd is used,
# we can test here (i.e. after build/GNU/Linux/10_copy_as_is.sh had already run)
# if /bin/systemctl exists in the recovery system:
test -x $ROOTFS_DIR/bin/systemctl || return 0

Now it works for me on SLES12-SP2 with systemd
and on SLES11-SP4 without systemd.

@gdha
if you do not object I think I will merge it tomorrow.

@jsmeix looks perfect to! Thank you for the quick fix.

@schlomo
regarding what happens if 'umount -a' fails:
I added the explicit 'umount -a' plus 'sync' and 'sleep 3'
before I call things like 'systemctl --force reboot'
which is an advantage compared to what was
done before according to how I understood it in my
#953 (comment)

I.e. before there was only plain 'systemctl --force reboot'
without any explicit 'umount' and any delay to give the harddisk
a chance to write its caches onto the actual disk.

But again:
This is all according to my non-systemd-expert
perception of how things seem to work in systemd.