Hello! After making some changes to a Yocto-based Linux image I ran into the sys-subsystem-net-devices-multi-user.device timeout problem. Various people have reported that, for example here: https://www.reddit.com/r/archlinux/comments/4mnkyu/timeout_during_boot/?st=j03jwv0d&sh=14c1a955 In my case I traced it down to this combination of circumstances: * /etc/machine-id is missing during booting. * systemd then auto-enables all system units according to their [Install] section because it detects a first-boot scenario. * /lib/systemd/system/wpa_supplicant@.service contains Alias=multi-user.target.wants/wpa_supplicant@%i.service in its [Install] section. * That gets turned into a symlink: /etc/systemd/system/multi-user.target.wants/wpa_supplicant@.service -> /lib/systemd/system/wpa_supplicant@.service. * systemd then seems to replace %i in that service file with "multi-user", so multi-user.target ends up depending on wpa_supplicant@multi-user.service, which in turn depends on sys-subsystem-net-devices-multi-user.device. * That multi-user "device" of course never appears -> 90 second delay until the unit times out. The same happens for the other wpa_supplicant*@.service flavors. This %i was introduced in: https://w1.fi/cgit/hostap/commit/wpa_supplicant/systemd/wpa_supplicant.service.arg.in?h=hostap_2_6&id=893a0a558cd8fd9a7dc5827f379e0f8a273a4fe5 Apparently the motivation was to get rid of a hard-coded wlan0, but how was it supposed to work with %i instead? Arend, do you still remember? There's a bug 477 mentioned in that commit, but that probably was in the bug tracker which is now gone? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
