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