Actually, I was able to just now get it to boot with that config, so this seems to be an intermittent problem. I hit it most of the time. It is during boot, and systemd
It may not be with systemd, but that is where the upgrades came from, everything else was working before that. Here is another failed boot. this is the last thing in the log. Mar 15 16:54:56 jket-deb NetworkManager[794]: <info> [1521154496.1043] device (enp3s0): carrier: link connected Mar 15 16:54:56 jket-deb ModemManager[788]: <info> Couldn't check support for device '/sys/devices/pci0000:00/0000:00:1c.2/0000:03:00.0': not supported by any plugin Mar 15 16:54:56 jket-deb ModemManager[788]: <info> Couldn't check support for device '/sys/devices/pci0000:00/0000:00:1c.7/0000:04:00.0': not supported by any plugin Mar 15 16:55:26 jket-deb NetworkManager[794]: <info> [1521154526.2209] device (br0): carrier: link connected Mar 15 16:55:27 jket-deb avahi-daemon[795]: Joining mDNS multicast group on interface br0.IPv6 with address fe80::fab1:56ff:feb8:524a. Mar 15 16:55:27 jket-deb avahi-daemon[795]: New relevant interface br0.IPv6 for mDNS. Mar 15 16:55:27 jket-deb avahi-daemon[795]: Registering new address record for fe80::fab1:56ff:feb8:524a on br0.*. Mar 15 16:55:29 jket-deb avahi-daemon[795]: Leaving mDNS multicast group on interface br0.IPv6 with address fe80::fab1:56ff:feb8:524a. Mar 15 16:55:29 jket-deb avahi-daemon[795]: Joining mDNS multicast group on interface br0.IPv6 with address 2603:3026:414:b1f0:fab1:56ff:feb8:524a. Mar 15 16:55:29 jket-deb avahi-daemon[795]: Registering new address record for 2603:3026:414:b1f0:fab1:56ff:feb8:524a on br0.*. Mar 15 16:55:29 jket-deb avahi-daemon[795]: Withdrawing address record for fe80::fab1:56ff:feb8:524a on br0. Mar 15 16:55:53 jket-deb systemd-udevd[429]: seq 2260 '/devices/pci0000:00/0000:00:01.0/0000:01:00.0' is taking a long time Mar 15 16:55:55 jket-deb systemd-udevd[429]: seq 3061 '/devices/virtual/vtconsole/vtcon1' is taking a long time Mar 15 16:57:53 jket-deb systemd-udevd[429]: seq 2260 '/devices/pci0000:00/0000:00:01.0/0000:01:00.0' killed Mar 15 16:57:55 jket-deb systemd-udevd[429]: seq 3061 '/devices/virtual/vtconsole/vtcon1' killed Mar 15 16:57:55 jket-deb systemd-udevd[429]: worker [466] terminated by signal 9 (KILL) Mar 15 16:57:55 jket-deb systemd-udevd[429]: worker [466] failed while handling '/devices/virtual/vtconsole/vtcon1' Mar 15 17:00:38 jket-deb NetworkManager[794]: <info> [1521154838.7769] device (wlp4s0): set-hw-addr: set MAC address to 6E:1A:B4:B7:1B:66 (scanning) Mar 15 17:00:38 jket-deb NetworkManager[794]: <info> [1521154838.7973] device (wlp4s0): supplicant interface state: ready -> disabled Mar 15 17:00:38 jket-deb NetworkManager[794]: <info> [1521154838.8324] device (wlp4s0): supplicant interface state: disabled -> inactive Mar 15 17:00:38 jket-deb wpa_supplicant[793]: wlp4s0: Reject scan trigger since one is already pending On Thu, Mar 15, 2018 at 4:40 PM, Michael Biebl <bi...@debian.org> wrote: > Am 15.03.2018 um 23:31 schrieb Jeff Ketchum: > > Package: systemd > > Version: 238-2 > > Severity: normal > > > > > > > > -- Package-specific info: > > > > -- System Information: > > Debian Release: buster/sid > > APT prefers unstable > > APT policy: (500, 'unstable') > > Architecture: amd64 (x86_64) > > Foreign Architectures: i386 > > > > Kernel: Linux 4.15.0-1-amd64 (SMP w/8 CPU cores) > > Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), > LANGUAGE=en_US.utf8 (charmap=UTF-8) > > Shell: /bin/sh linked to /bin/dash > > Init: systemd (via /run/systemd/system) > > LSM: AppArmor: enabled > > > > Versions of packages systemd depends on: > > ii adduser 3.117 > > ii libacl1 2.2.52-3+b1 > > ii libapparmor1 2.12-3 > > ii libaudit1 1:2.8.2-1 > > ii libblkid1 2.31.1-0.5 > > ii libc6 2.27-2 > > ii libcap2 1:2.25-1.2 > > ii libcryptsetup12 2:2.0.1-1 > > ii libgcrypt20 1.8.1-4 > > ii libgpg-error0 1.27-6 > > ii libidn11 1.33-2.1 > > ii libip4tc0 1.6.2-1 > > ii libkmod2 25-1 > > ii liblz4-1 0.0~r131-2+b1 > > ii liblzma5 5.2.2-1.3 > > ii libmount1 2.31.1-0.5 > > ii libpam0g 1.1.8-3.7 > > ii libseccomp2 2.3.1-2.1 > > ii libselinux1 2.7-2+b1 > > ii libsystemd0 238-2 > > ii mount 2.31.1-0.5 > > ii procps 2:3.3.12-4 > > ii util-linux 2.31.1-0.5 > > > > Versions of packages systemd recommends: > > ii dbus 1.12.6-2 > > ii libpam-systemd 238-2 > > > > Versions of packages systemd suggests: > > ii policykit-1 0.105-18 > > pn systemd-container <none> > > > > Versions of packages systemd is related to: > > pn dracut <none> > > ii initramfs-tools 0.130 > > ii udev 238-2 > > > > -- Configuration Files: > > /etc/systemd/journald.conf changed: > > [Journal] > > Storage=auto > > > > > > -- no debconf information > > > > I upgraded systemd, and after a failure to boot, realized it was on > > systemd:i386. > > I went into a recovery environment and removed systemd:i386 and > > installed systemd. > > After that It failed to boot at a different location. > > I was able to get it to boot by removing the kernel parameter > > for the nouveau driver to use the binary firmware. > > > > nouveau.config=NvGrUseFw=1 > > Where exactly is the problem that is caused by systemd? > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > >
_______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
