As my previous messages have gone entirely ignored, I'm hoping that someone can help me with this problem, which I hope is simpler. My boot times out trying to start a number of devices. One of them, for example, is dev-mapper-LVGx2dtmp.device. Another is dev-disk-byx2duuid-<UUID>.device. I can `systemctl show ` these devices but I can't disable them. Can someone tell me what they're there for, what created them and how I can, for debugging purposes, disable them from being called?
On 22 July 2016 at 00:09, Borden Rhodes <j...@bordenrhodes.com> wrote: > 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
