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
