Newest Ubuntu builds of systemd have networking issues

[Luke]

Systemd_218-6ubuntu1 and later cannot connect to network except via USB, I just posted this bug report:

https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1420601

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.


with this comment below:

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

[Kano]

Why do you need dracut? initramfs-tools add much more network drivers by default.

[Luke]

Dracut supports asynchronous processes in the initramfs

Why do you need dracut? initramfs-tools add much more network drivers by default.

Well, one feature of dracut is the ability by not installing "dracut-network" to keep the network inactive until the root filesystem is mounted, I'm pretty sure you can do this in initramfs-tools as well. Dracut does not start the network unless it needs to for a network boot.

The orignal reason I switched to dracut was to port my replacement for cryptsetup's boot time disk decryption script to systemd back in May 2014. The purpose of this package is to allow unlocking many hard drives with one passphrase, holding it only in RAM , then overwriting the variable containing it, then unsetting it before exit. Dracut can run systemd in the initramfs and I had to presume in the long run all systems (or most) would use systemd in the initramfs. I wanted this job OUT of the way. Later, I found I could modify my script to unlock all the non-root drives first and asynchonously, using the root drive's unlocking time to hold the script open long enough for all of them to complete. That takes 2 seconds off the boot time, but works only in Dracut/systemd. In initramfs-tools, the asynchonous processes get killed after root unlocks.

Systemd has it's own module for unlocking LUKS volumes,but with the version of systemd that was in Ubuntu in May 2014 it was full of race conditions. It was supposed to be able to cache a passphrase for multiple disks, but this never worked and I do not know how it goes about clearing and unsetting that variable after it is done. That kind of code I prefer to write myself so I know exactly what it does. I did examine the cryptsetup systemd module to look for any evidence of say, saving passphrases to disk and found none, but not being a C coder all I could do is look for obvious commands to do so,

Anyway, I have found that even in non-encrypted machines, Dracut is faster, and current versions of Plymouth even work better with it. I am using a hacked dracut package ported over from Debian, as the Ubuntu version is too old to use systemd in the initramfs. About a month of work went into getting everything tuned, booting from a legacy initramfs-tools initramfs is slower and plymouth does not come up as fast.