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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to