touch-packages team mailing list archive

[luke <lukefromdc@xxxxxxxxxxxx>]

Ubuntu version is Vivid (alpha) on all machines, booting systemd by
default with upstart removed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1420601

Title:
  Systemd_218-6ubuntu1 and later cannot connect to network except via
  USB

Status in systemd package in Ubuntu:
  New

Bug description:
  
  systemd_218-6ubuntu1_amd64.deb   and later work ONLY with USB networking devices when booted from Dracut. Dracut network module is NOT in use, and binaries needed to connect to the network do not appear in my initramfs, yet systemd version loaded from it determines whether or not network can be connected. With an AMD Athlon II x4 machined and a Gigabyte AMD motherboard (785 series I think), I get the systemd networking unit entering a failed state, and the wired network cannot be turned on. On an Intel Atom Pine Trail netbook the wireless attempt to connect to the network but hangs on requesting an IP address from the router, never completing. Rolling back systemd to systemd_218-5ubuntu2_amd64.deb always fixes this and brings back normal network connectivity.  Finally, an AMD bulldozer machine connected by a USB wifi device has no trouble at all with the newer builds of systemd.

  systemd_218-5ubuntu2_amd64.deb , which came out Jan 23, seems to be
  the last good version. Same upstream version of systemd, apparently
  just build-time changes caused this.

  I'm not sure if this bug will appear with a normal Ubuntu initramfs-
  tools initramfs (I use Dracut with systemd in the initramfs), but I
  bring this up because my /boot partition is not normally mounted (so
  as not to corrupt a monitored hash value) and which version of systemd
  is in the initramfs, not the version on disk, determines whether or
  not networking functions on my machines.  I do understand my setup has
  diverged a lot from normal Ubuntu, someone should see if this problem
  exists in a normal Ubuntu install. If not I will need to find out what
  changed(possibly a udev rule?) and revert it myself in all later
  versions.

  I've been using systemd with dracut/systemd in the initramfs since
  last May, I now rely on it to run a parallelized version of my multi-
  encrypted disk unlocking program and am not about to revert it.
  Initramfs-tools seems to be unable to cope with multiple asynchrounous
  instances of cryptsetup, while dracut/systemd handles it just fine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1420601/+subscriptions