I have conducted more investigation into the cause, resulting in a significant restatement of the issue.
As far as this bug is concerned, it appears there has been no regression, indeed no change in behavior in ifconfig (net-tools package) or ifup (ifupdown package). However it could be argued that all along they have not handled dummy devices very well. The big change appears to be in modprobe (kmod package). As of xenial it behaved the same is insmode (also kmod package) but as of bionic it behaves differently. In particular, insmod tickles the device in such a way that dummy0 comes into existence (in a down state) whereas bionic modprobe leaves it nonexistent. (Higher-numbered devices such as dummy1 are nonexistent in all cases, when the module is newly installed.) The "ip link add" command is fully capable of bringing a dummy device into existence, but apparently neither ifconfig nor ifup has ever had this capability. This is a problem for dummy1 (always) and, what's worse, for dummy0 (as of bionic). You can see the gory details by comparing the typescripts attached to this comment (for xenial) and the next (for bionic). So ... even though the change in behavior occurred in modprobe, it could be argued that the new modprobe behavior is more logical, because it treats dummy0 and dummy1 the same now. By the same token, since dummy1 was never handled well by ifconfig or ifup, it could be argued that the best way to proceed would be to make those programs more robust. Crib the code from "ip link add" to bring the device into existence when appropriate. ** Attachment added: "xenial: insmod and modprobe behave the same" https://bugs.launchpad.net/ubuntu/+source/net-tools/+bug/1828749/+attachment/5264584/+files/dummy-xenial.logg -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1828749 Title: ifconfig dummy0 : Device not found Status in ifupdown package in Ubuntu: New Status in net-tools package in Ubuntu: New Bug description: Desired behavior: The ifconfig command should be able to deal with the dummy device. This worked fine until recently. Observed behavior: :; ifconfig dummy0 dummy0: error fetching interface information: Device not found This problem appeared when I upgraded to bionic. Highly informative workaround: :; ip link add dummy0 type dummy That command works, and makes the problem go away permanently. The ifconfig command works fine after that. The ifup and ifdown commands also work fine after that. For convenient debugging, you can use the command: :; ip link del dummy0 type dummy which makes the problem come back. You can also experiment with dummy1 et cetera. Package ownership issues: Compare: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909204 That report was filed against ippusbxd, which is almost certainly not the relevant package. For that matter, I have no idea whether the root cause is in the net-tools package or the kernel networking stack. All I know is the ip command plays nicely with the kernel while the ifconfig command does not. Notes: The kernel module for the dummy interface is preloaded in all situations described here. That's not the issue. An apport file is attached, to describe the environment. Also, since you asked: :; apt-cache policy net-tools net-tools: Installed: 1.60-26ubuntu1 Candidate: 1.60-26ubuntu1 Version table: *** 1.60-26ubuntu1 500 500 http://ubuntu.cs.utah.edu/ubuntu xenial/main amd64 Packages 100 /var/lib/dpkg/status :; lsb_release -rd Description: Ubuntu 16.04.6 LTS Release: 16.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1828749/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
