Thank you for your message, Michael, and please forgive the delay in responding.
I tried booting with the 4.5 kernel after 4.6 failed to boot. It seems, by then, that the damage had been done as I got identical symptoms on both boots. I agree with you that the cryptsetup/LVM is to blame (although I'd blame LVM more). The hypothesis to test multi-user.wants came from being able to boot into single user mode without incident and isolate default.target once I'm in single user mode. I can also isolate default.target from the early debug shell. I tried to follow your advice. It seems that my box could accurately identify the partitions from `ls`-ing through the /dev directory and seeing everything set up correctly. fstab and crypttab also seem to be intact during the hangup. I ran `udevadm info` on everything I could find in /sys/class/block/ the settings you told me to check are as follows: ./dm-0 (mapper/sda5_crypt): SYSTEMD_READY=1; TAGS=:systemd: ./dm-1 (mapper/LVG-root): TAGS=:systemd: (SYSTEMD_READY is not present) ./dm-2 (mapper/LVG-var): TAGS=:systemd: (SYSTEMD_READY is not present) ./dm-3 (mapper/LVG-tmp): TAGS=:systemd: (SYSTEMD_READY is not present) ./dm-4 (mapper/LVG-home): TAGS=:systemd: (SYSTEMD_READY is not present) ./sda: TAGS=:systemd: (SYSTEMD_READY is not present) ./sda1 (/boot): TAGS=:systemd: (SYSTEMD_READY is not present) ./sda5 (crypttab/LVM partition): TAGS=:systemd: (SYSTEMD_READY is not present) I hope that's legible. I can pastebin the full output for each of those commands if it helps. For kicks and giggles, I ran `sudo lvmconfig --type diff` which yielded devices { cache_dir="/run/lvm" } I'm grasping at straws so I don't know if this is relevant or not. With thanks, By-the-by, since it's been a while since I've been able to tackle this, here's the rest of the e-mail thread for context: https://lists.debian.org/debian-user/2016/06/msg00670.html