desktop-packages team mailing list archive
-
desktop-packages team
-
Mailing list archive
-
Message #108959
Re: [Bug 1435687] Re: disable/enable WiFi on devices with read-only rootfs, the wifi network name will auto plus 1
(replied inline)
2015-03-26 20:46 GMT+08:00 Martin Pitt <martin.pitt@xxxxxxxxxx>:
> I think this overcomplicates things a lot. I see three options here:
>
> 1) My impression is that we don't actually care about persistant
> interface names on the phone. Therefore, phone image builds could just
> create/ship an empty /etc/udev/rules.d/75-persistent-net-generator.rules
> which will disable the one in /lib/udev/rules.d/ and therefore disable
> the generator completely.
>
This is doable to me.
2) If we actually do want persistant names across reboots, then
> /etc/udev/rules.d/ needs to become writable. It does not make sense to
> support a phone specific path for this if we could just make the above
> writable.
>
It's not about persistent names across reboots, the interface name will not
be consistent if driver reload happens, and that's what's happening on
embedded devices. Whenever driver reload happens, there will be an ADD
uevent which triggers 75-persistent-net-generator.rules.
> 3) As you already said, we could also enable net.ifnames=1 on the
> kernel command line to use "proper" interface names, which will also
> disable 75-persistent-net-generator.rules.
>
net.ifnames depends on systemd, and Ubuntu Phone is not yet upgrade to use
systemd by default.
> ** Package changed: systemd (Ubuntu) => ubuntu-settings (Ubuntu)
Vicamo
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to ubuntu-settings in Ubuntu.
https://bugs.launchpad.net/bugs/1435687
Title:
disable/enable WiFi on devices with read-only rootfs, the wifi network
name will auto plus 1
Status in systemd:
Fix Released
Status in ubuntu-settings package in Ubuntu:
New
Bug description:
On devices with read-only rootfs, e.g. mobile phones, nic device
number (wlan<N>) may increase every time disabled and re-enabled. To
be more precisely, this happens only on devices when disabling a NIC
removes the corresponding driver.
"/lib/udev/rules.d/75-persistent-net-generator.rules" checks whether
NAME attribute has been assigned to wlan<N> device: if yes, skip all
the followed steps, or, call to "/lib/udev/write_net_rules" to
generate a persistent device name rule file. That persistent file
should be created under "/etc/udev/rules.d" and named "70-persistent-
net.rules", so it guarantees NAME attribute should be assigned if
available before being read. However, when rootfs was previously
mounted as read-only, a file "/run/udev/tmp-rules--70-persistent-
net.rules" is created instead. This temporary file is supposed to be
moved back into "/etc/udev/rules.d" by a systemd service udev-finish
right after the system finishes start-up chaos. Again, if rootfs is
still mounted as read-only, this move will certainly fail. One last
important thing, /run/udev is _NOT_ included in udev rules inclusion
paths, so any rules written here will not be taken into account when
processing uevents.
So, when wlan0 is probed for the first time on a device with read-only
rootfs, udev creates "/run/udev/tmp-ruiles--70-persistent-net.rules"
and inserts one rule for it. When wlan0 is disabled and re-enabled,
since "/run/udev/tmp-rules--70-persistent-net.rules" is not taken into
account, its NAME attribute will not be set, and udev recognize it as
a new nic and tries to write another rule for it again. However, in
this time, "wlan0" has been taken in the previously written temporary
rules file, so "wlan1" is chosen instead, and an exactly the same
matching rule (except for NAME= part) is appended to "/run/udev/tmp-
rules--70-persistent-net.rules". When the device is again disabled and
re-enabled, "wlan2" will be assigned. And so on ....
This is a cloned bug from Debian bug 780705 (https://bugs.debian.org
/cgi-bin/bugreport.cgi?bug=780705), which affects Ubuntu Phone.
To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1435687/+subscriptions
References