Uoti Urpala <uoti.urp...@pp1.inet.fi> writes:
> Russ Allbery wrote:
>>Kay Sievers <k...@vrfy.org> writes:
>> > Hmm, why would upgrades break?
>>
>> > The old file would still be there, rename the devices (if you keep the
>> > patch to swap names, which upstream does not support any more), and take
>> > precedence over tht new names; the old rules file would just not be
>> > updated anymore when new devices appear.
>>
>> Manually-deployed /etc/network/interfaces files that assume a specific
>> device naming come to mind. We have tons of those at work.
>
> Why would those break? Just having a manually-deployed
> /etc/network/interfaces file that uses names like "eth0" should not
> break upgrades, because as mentioned in the part you quoted, the
> existing already-generated rules should still trigger and keep renaming
> the same card to eth0. So you need to assume something more to have an
> example of a problem case.
Things will break because the new scheme changes interface names which
never have been added to the generated rules.
As just one example, these names have been in use at some point in time
on my laptop:
bjorn@nemi:~$ egrep ^iface /etc/network/interfaces
iface lo inet loopback
iface eth0 inet manual
iface wlan0 inet manual
iface default inet dhcp
iface mbm0 inet dhcp
iface mb0 inet dhcp
iface wwan0 inet dhcp
iface wwan1 inet dhcp
iface test inet dhcp
iface debug inet dhcp
iface mob inet dhcp
iface mbb inet dhcp
iface testv4 inet dhcp
iface testv6 inet6 manual
iface usb0 inet dhcp
iface usb1 inet dhcp
iface tap0 inet manual
iface tap0.42 inet manual
iface bnep0 inet dhcp
Only two of them have persistent entries and can be expected to continue
working:
bjorn@nemi:~$ grep NAME /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:21:86:a3:25:7d", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="0c:8b:fd:08:09:71", ATTR{dev_id}=="0x0", ATTR{type}=="1",
KERNEL=="wlan*", NAME="wlan0"
I'm not claiming that I use all those entries, and some of them were
added due to breakage caused by the existing scheme. But this doesn't
change the fact that converting to the new scheme will cause additional
breakage, e.g. by renaming my internal wwanX devices to wwsomething.
I'll leave up to others to decide whether such breakage is acceptable or
not.
Bjørn
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ob81t0u0....@nemi.mork.no
