Re: boot times out after dist-upgrade on Stretch
On 2016-06-15 07:58 +0000, Borden Rhodes wrote:
> I ran apt dist-upgrade on Stretch (with a few Sid packages) which made
> the following changes:
>
> Start-Date: 2016-06-14 19:42:39
> Commandline: apt-get dist-upgrade
> Requested-By: me (1000)
> Install: libdw1:amd64 (0.163-5.1, automatic),
> linux-image-4.6.0-1-amd64:amd64 (4.6.1-1, automatic)
> Upgrade: wwwconfig-common:amd64 (0.2.2, 0.3.0), libcomerr2:amd64
> (1.43-3, 1.43.1-1), libcomerr2:i386 (1.43-3, 1.43.1-1), libcups2:amd64
> (2.1.3-5, 2.1.3-6), fuse2fs:amd64 (1.43-3, 1.43.1-1), e2fsprogs:amd64
> (1.43-3, 1.43.1-1), boinc-client:amd64 (7.6.32+dfsg-2, 7.6.33+dfsg-1),
> libbabeltrace1:amd64 (1.3.2-1, 1.4.0-1), cups-server-common:amd64
> (2.1.3-5, 2.1.3-6), e2fslibs:amd64 (1.43-3, 1.43.1-1),
> cups-common:amd64 (2.1.3-5, 2.1.3-6), libspice-server1:amd64
> (0.12.6-4, 0.12.6-4.1), boinc-manager:amd64 (7.6.32+dfsg-2,
> 7.6.33+dfsg-1), libss2:amd64 (1.43-3, 1.43.1-1), live-config-doc:amd64
> (5.20151121, 5.20160608), libdatetime-timezone-perl:amd64
> (1:1.98-1+2016d, 1:2.00-1+2016d), cups-ppdc:amd64 (2.1.3-5, 2.1.3-6),
> libcupsmime1:amd64 (2.1.3-5, 2.1.3-6), python-paramiko:amd64
> (1.16.0-1, 2.0.0-1), linux-image-amd64:amd64 (4.5+73, 4.6+74),
> libboinc7:amd64 (7.6.32+dfsg-2, 7.6.33+dfsg-1), libcupsppdc1:amd64
> (2.1.3-5, 2.1.3-6), libbabeltrace-ctf1:amd64 (1.3.2-1, 1.4.0-1),
> live-config:amd64 (5.20151121, 5.20160608), cups-bsd:amd64 (2.1.3-5,
> 2.1.3-6), cups-core-drivers:amd64 (2.1.3-5, 2.1.3-6),
> cups-daemon:amd64 (2.1.3-5, 2.1.3-6), libcupsimage2:amd64 (2.1.3-5,
> 2.1.3-6), cups:amd64 (2.1.3-5, 2.1.3-6), boinc:amd64 (7.6.32+dfsg-2,
> 7.6.33+dfsg-1), libcupscgi1:amd64 (2.1.3-5, 2.1.3-6),
> cups-client:amd64 (2.1.3-5, 2.1.3-6), live-config-systemd:amd64
> (5.20151121, 5.20160608), libjpeg62-turbo:amd64 (1:1.4.2-2,
> 1:1.5.0-1), libjpeg62-turbo:i386 (1:1.4.2-2, 1:1.5.0-1), xterm:amd64
> (324-2, 325-1)
> End-Date: 2016-06-14 19:46:44
The only package related to the boot process seems to be
linux-image-4.6.0-1-amd64. However, there could be others which were
upgraded earlier. When did you last boot before this upgrade?
> The system worked normally until I rebooted a few hours later. After
> entering my encryption password (more on that later), boot up stalls
> with a message saying that "A start job is running for" and then
> switches between sda5_crypt.device, x2dhome.device, x2dvar.device,
> x2dtmp.device, <UUID-for-my-root-partition>.device and
> <UUID-for-my-dm-crypt-partition>.device.
>
> After 90 seconds, the start up jobs timeout and the boot tries to
> start an emergency shell. However, the prompt never appears, responds
> to ^C or ^D as some suggest it might. However, CTRL+ALT+DEL works, so
> I know the system isn't completely locked up.
>
> The only error messages I can read after that, as earlier ones would
> get truncated, are that systemd-tmpfiles.setup.service,
> binfmt-support.service and networking.service all failed to start.
Those probably fail because /tmp and /var could not be mounted.
> I can, however, boot into single user recovery without the stall,
> timetout or any error messages.
>
> I think it's relevant to note that my hard drive has a msdos partition
> table (and a legacy BIOS), a LVM partition containing dm-crypt'd
> partitions, each of which is formatted with a btrfs file system. Put
> another way, here's my fstab:
> # <file system> <mount point> <type> <options> <dump> <pass>
> /dev/mapper/LVG-root / btrfs defaults 0 1
> # /boot was on /dev/sda1 during installation
> UUID=<UUID here> /boot btrfs defaults 0 2
> /dev/mapper/LVG-home /home btrfs defaults 0 2
> /dev/mapper/LVG-tmp /tmp btrfs defaults 0 2
> /dev/mapper/LVG-var /var btrfs defaults 0 2
> /dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
>
> What hasn't worked:
> - One site suggested that systemd requires acl. I added acl to all of
> the options in fstab without success.
That's red herring, acl is only needed to tune the permissions for the
journal.
> - Another user on Arch had very similar symptoms to mine:
> https://bbs.archlinux.org/viewtopic.php?id=210008 . However, my system
> doesn't have mkinitcpio, so I can't try the solution that worked for
> him. However, I have initramfs, so maybe adapting his solution would
> work. I'd need guidance as to how so that I don't waste hours
> experimenting with config files.
I guess lvm already works in the initramfs, otherwise your root
filesystem could not be mounted.
> Could I get direction on how to troubleshoot this?
Does the problem show up when you boot with the previous kernel
(probably 4.5)?
Cheers,
Sven
Reply to: