Wrong uuid before it fails and drops to the grub rescue prompt. That is the uuid of your /dev/mapper partition. Grub should be looking for the uuid of sda1. It can't find vmlinuz & initrd.img. They are now on sda1.

/dev/sda1: UUID="37a1d9e9-2597-4fc7-ad7f-95def918c030" TYPE="ext4" PARTUUID="df76ca67-01" <-- this guy

Check your grub.cfg. You should find a bunch of:

--set=root 05eb424f-c4f8-4a5e-88d4-7a95764f7e58

That should be reading:

--set=root 37a1d9e9-2597-4fc7-ad7f-95def918c030

You get the grub rescue prompt because grub can't find the 2 needed boot files. If it fails because of bad crypttab or lvm mistakes in the initramfs image file, it will drop to an (initramfs) shell instead of a grub rescue prompt.

(search & replace is ur friend) 

Once you boot into the OS, crypttab needs to have the uuid for sda2, like:
crypt UUID=b23b7722-8c39-47f1-a49b-cd6cc7ac4eae none luks,discard

and fstab needs to have the entry for sda1 and the /dev/mapper entry for the luks device.

# /boot was on /dev/sda1 during installation
UUID=37a1d9e9-2597-4fc7-ad7f-95def918c030 /boot           ext4    defaults        0       2
/dev/mapper/crypt /               ext4    errors=remount-ro 0       1 

(yep, that's a space after the uuid and the word 'crypt')

Then have it pump you out a new initrd.img with mkinitramfs

Those are called 'stubs' in computer science. They are put there as a deprecation to keep apps & utilities that reference them from failing catastrophically. (It's kinda like having a "guest" bedroom, but never inviting anyone to spend the night (which demonstrates that you are socially competent, but you don't actually have to go there)).

No, it is ignored.  Thanks though.

For the primary network interface, changing the interface from using "dhcp" to "manual" solves this ..

My approach to this was to change the line:

for i in 1 2 4 8 16 32; do

to:

for i in 1; do

My reasoning is this; This do_stop() function always fails. Always. The failure is innocuous. Always. Soo .. the only thing I need to do is mitigate the timeout interval before failure.

I read somewhere on a Debian site that the function is trying to affect something that has already shut down or unmounted.