Re: boot times out after dist-upgrade on Stretch
First, a huge shout out to /usr/share/doc/systemd/README.Debian.gz for
telling me that appending systemd.debug-shell to the linux line in
grub would let me run a shell even whilst the main boot couldn't drop
into an emergency shell. I think this should be writ in large friendly
letters at the start of any boot-related troubleshooting guide from
now on.
With that, I could dump journalctl and systemctl list-jobs to files.
In perusing these files, it confirms that boot chokes at 4
dev-disk-by\x2duuid-<...>.device, dev-mapper-sda5_crypt.device &
dev-mapper-LVG\x2d<home|var|tmp>.device, but curiously not
dev-mapper-LVG\x2droot. root, of course, has a fstab pass value of 1
whereas the others have a pass value of 2. Is this a clue? The
list-jobs dumps also show some 94 other units waiting in line to run.
A little search-fu later, it seems I may have caught this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758808. However,
other searches on other distros suggest everything from hdparm needing
to be removed (didn't work), to incorrect fstab entries (did you guys
see any error in them?), to lunar cycles, to a butterfly flapping its
wings etc.
Anyhow, notwithstanding any better ideas, I think I'm going to
redirect this conversation to bug 758808.
> Date: Thu, 16 Jun 2016 13:56:48 -0400
> From: Borden Rhodes <jrvp@bordenrhodes.com>
> To: debian-user@lists.debian.org
> Subject: Re: boot times out after dist-upgrade on Stretch
> Message-ID: <[🔎] CABeHYofhP+9tVT9BM=A3txX5HWufu3rztPqcnB99MBmhSogy-Q@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Thank you for getting back to me, Sven,
>
> I normally run apt-get update; apt-get dist-upgrade immediately after
> my computer boots. According to the messages log, I turned the
> computer on about 5 minutes before running that command and the last
> log entry was about 3.5 hours later at 22:59. I hadn't fiddled with
> any other settings during that boot. Unfortunately, without /var
> loading on the dead boots, I can't get any log information except when
> I successfully boot into the recovery console.
>
> I should have mentioned that I also tried booting from the 4.5 kernel
> and got the exact same symptoms. I also tried running update-grub in
> case it had made a mistake whilst installing the 4.6 kernel.
>
> Notwithstanding better ideas, I'm thinking of doing the Windows Safe
> Mode troubleshooting method where I work out the systemd differences
> between the default and recovery targets and gradually add services
> until I find the one that breaks the system. I'm inferring that, since
> recovery mode works but normal mode doesn't, then one of the
> targets/services in normal mode is to blame for the lock up. I don't
> suppose I could trouble the list for a resource on how to do that?
Reply to: