During the 90 second wait before my boot times out, I dropped into a debug-shell and ran `systemctl list-units`. This was the output: http://paste.debian.net/783995/ (good for 3 days). Of curiosity is that the other dev-mapper-LVG... devices show that they're inactive except for dev-mapper-LVG\x2droot.device, which makes sense since this is given a pass of 1 in /etc/fstab. What sorts of operations would be running on dev-mapper-LVG\x2droot.device so I can isolate which one might be hanging up? Also note in the dump that -.mount is both active and successfully mounted, which may explain why, even after the dev-mapper-LVG... processes time out that the debug-shell still shows a properly-mounted filesystem.
I suspected it might be fsck but disabling it both from fstab (pass=0) and the kernel command line (fsck.mode=skip) didn't work. What else can I check? On 19 July 2016 at 02:54, Borden Rhodes <j...@bordenrhodes.com> wrote: > 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