It's exactly as Jeremy points out -- NM should be detecting that wpasupplicant is not running and start it -- this should already have been working by way of wpasupplicant being dbus-activated.
The isolate command is there for a good reason. We want a dramatically different environment while oem-config is running -- users should not be logged in, daemons should not be running -- as anything running may block the steps taking in oem-config, such as the removal of the oem user at the end. Once all that is done, we isolate back to default mode -- this makes it so we don't have to do a full reboot just to get a working system after oem-config has been run. It seems to me like IgnoreOnIsolate for wpasupplicant would be the right thing to do, or to figure out why it isn't being properly started when NM tries to use it. 'systemctl isolate' is documented as being equivalent to changing runlevels in a system without systemd: that's pretty much exactly what we want after changing default.target back to what it really should be. If this doesn't work, we'll need to come up with a vastly different way of having oem-config work. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1576024 Title: Wifi "device not ready" after booting into OS for the 1st time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1576024/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
