Re: boot times out after dist-upgrade on Stretch
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 <jrvp@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
Reply to: