[Touch-packages] [Bug 1828749] Re: ifconfig dummy0 : Device not found
Here is better evidence. Just now I ran the experiment using same kernel version, 4.19.42, as in the xenial experiment reported above. My conclusions are unchanged. The newly-introduced incompatible and inconsistent behavior depends on the modprobe release, not on the kernel release. I knew this to be true, as stated previously, but now we have clearer evidence on the record. ** Attachment added: "bionic: (same kernel) insmod and modprobe behave differently" https://bugs.launchpad.net/ubuntu/+source/net-tools/+bug/1828749/+attachment/5265060/+files/dummy-beaver.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
[Touch-packages] [Bug 1828749] Re: ifconfig dummy0 : Device not found
Contrasting attachment, as discussed in previous comment. ** Attachment added: "bionic: insmod and modprobe behave differently" https://bugs.launchpad.net/ubuntu/+source/net-tools/+bug/1828749/+attachment/5264585/+files/dummy-bionic.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
[Touch-packages] [Bug 1828749] Re: ifconfig dummy0 : Device not found
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
[Touch-packages] [Bug 1828749] Re: ifconfig dummy0 : Device not found
Message 2 of 2: This is easy to use and/or test ifup dummy0 and ifdown dummy0 You don't need to know the complexities of the motivation for why this is important; the test case is very simple. In the context of the ifupdown package, this requires putting a stanza like this in /etc/network/interfaces or /etc/network/interfaces.d/dummy: auto dummy0 iface dummy0 inet static netmask 255.255.255.255 address 10.10.2.105 Then the static dummy interface (a) should come up automagically at boot time, and can be further controlled by :; ifup dummy0 :; ifdown dummy0 Desired behavior: It should just work. Observed behavior: :; ifup dummy0 Cannot find device "dummy0" Failed to bring up dummy0. Highly informative workaround: :; ip link add dummy0 type dummy That command works, and makes the problem go away permanently. The ifup and ifdown commands 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. See the detailed workaround script attached previously. FWIW the ifconfig command exhibits all the same misbehavior; net-tools and ifupdown are affected in the same way, but remarkably enough the ip command (from the iproute2 package) is apparently not affected by this bug. -- 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: Incomplete 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
[Touch-packages] [Bug 1828749] Re: ifconfig dummy0 : Device not found
To reiterate and clarify: net-tools and ifupdown both exhibit the bug in bionic, whereas neither exhibits the bug in xenial. The bug is observed in the following package versions: :; apt-cache policy net-tools net-tools: Installed: 1.60+git20161116.90da8a0-1ubuntu1 Candidate: 1.60+git20161116.90da8a0-1ubuntu1 Version table: *** 1.60+git20161116.90da8a0-1ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages 100 /var/lib/dpkg/status and :; apt-cache policy ifupdown ifupdown: Installed: 0.8.17ubuntu1.1 Candidate: 0.8.17ubuntu1.1 Version table: *** 0.8.17ubuntu1.1 500 500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 100 /var/lib/dpkg/status 0.8.17ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages -- 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: Incomplete 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
[Touch-packages] [Bug 1828749] Re: ifconfig dummy0 : Device not found
Msg 1 of 2: Here is a use-case for ifup dummy0 and ifdown dummy0: I have multiple laptops. Sally has multiple laptops. Sometimes they are wired (for speed) and sometimes wireless (for portability). Sometimes we are at the same workplace, or at my abode, or her abode, or the local library, or the local cantina. Sometimes I am at some unfamiliar place, tasked with figuring out what's wrong with the local computer setup. That means many different DHCP servers, most of which I do not control. They do not all perform dynamic DNS in any reasonable way. It would of course be elegant to set up dynamic DNS, but that would be a lot of work in the best case, and would not be reliable in corner cases. I find it advantageous to bring up a dummy interface with a static address, and match that with a static entry in /etc/hosts. That simplifies the task of contacting this-or-that machine. No routing is required, because the interface will ARP the dummy address as well as the DHCP-assigned address. See next message for test and usage details. -- 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: Incomplete 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
[Touch-packages] [Bug 1828749] Re: ifconfig dummy0 : Device not found
Can you please transfer this to the ifupdown package? Or should I just resubmit it from scratch? The discussions of the importance of ifconfig are beside the point. The problem presented itself during boot-up, in connection with an "auto dummy0" directive in /etc/network/interfaces. If "auto dummy0" and "ifup dummy0" are not maintained then why bother to have a dummy device at all? This is the most important context, although there are MANY others. I reported the ifconfig context because it is the /simplest/ ... not the only manifestation. And no, I'm definitely not the first person to encounter the bug. I'm just the first to report it through this channel. My first message in this thread linked to a report that came up in another context. As for the software versions: I must have typed the "apt-cache policy net-tools" in the wrong window at one point. As stated before that and after that, the fact is that bionic is buggy while xenial is not. Specifically, the buggy packages are: :; apt-cache policy net-tools net-tools: Installed: 1.60+git20161116.90da8a0-1ubuntu1 Candidate: 1.60+git20161116.90da8a0-1ubuntu1 Version table: *** 1.60+git20161116.90da8a0-1ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages 100 /var/lib/dpkg/status and perhaps more to the point: :; apt-cache policy ifupdown ifupdown: Installed: 0.8.17ubuntu1.1 Candidate: 0.8.17ubuntu1.1 Version table: *** 0.8.17ubuntu1.1 500 500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 100 /var/lib/dpkg/status 0.8.17ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to net-tools in Ubuntu. https://bugs.launchpad.net/bugs/1828749 Title: ifconfig dummy0 : Device not found 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/net-tools/+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
[Touch-packages] [Bug 1828749] Re: ifconfig dummy0 : Device not found
*) As for priority: It's not as low as you might imagine. The problem affects not just ifconfig but also ifup, which is indispensable. It also affects the "raise network interface" target at boot time, as triggered by "auto dummy0" directives in /etc/network/interfaces. Symptom: :; ifup dummy0 Cannot find device "dummy0" Failed to bring up dummy0. This was hinted at in the original report but not emphasized. I emphasize it now. I mentioned ifconfig because it is the /simplest/ way to exhibit the bug. Feel free to change the headline of this bug to "ifup" (rather than "ifconfig") and transfer it to the ifupdown package (rather than net-tools) if you wish. This bug means that when I upgraded my machine remotely, it became unreachable, because the dummy0 interface carried the stable IP address that I was using. It took a great deal of work on my part to devise a workaround. *) In answer to your question: "until recently" means until I upgraded from xenial to bionic. I have another system still running xenial where ifconfig, ifup, and "raise network interface" all continue to work fine. The kernel version is exactly the same, 4.19.42; this may help you determine whether the regression is in user space and/or kernel space. On the other side of the same coin, I have yet another system with a squeaky clean bionic (installed ab_initio, not upgraded) that exhibits all the same problems with ifconfig, ifup, and "raise network interface". So it appears to be a bionic issue. I have no easy way to test the releases that came between xenial and bionic. All I know is that bionic is the latest LTS. It's supposed to be supported, and it's broken in a way that caused me a lot of grief. *) FURTHERMORE, there is nothing in the ifconfig man page to suggest that it is in any way deprecated. What's the deal? Choose your farce: -- Is it on double-secret probation? (Animal House) -- Doesn't it defeat the purpose of a deterrent if you keep it a secret? (Dr. Strangelove) -- Is perhaps the notice on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of the Leopard"? (Hitchhiker's Guide) If it really is deprecated and unsupported, somebody should file a separate bug against the documentation. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to net-tools in Ubuntu. https://bugs.launchpad.net/bugs/1828749 Title: ifconfig dummy0 : Device not found Status in net-tools package in Ubuntu: Incomplete 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/net-tools/+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
[Touch-packages] [Bug 1828749] Re: ifconfig dummy0 : Device not found
I put the attached file in if-pre-up.d/dummy-workaround to make my system work reliably. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to net-tools in Ubuntu. https://bugs.launchpad.net/bugs/1828749 Title: ifconfig dummy0 : Device not found 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/net-tools/+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
[Touch-packages] [Bug 1828749] Re: ifconfig dummy0 : Device not found
Here's the workaround. ** Attachment added: "workaround for ifconfig dummy0 bug" https://bugs.launchpad.net/ubuntu/+source/net-tools/+bug/1828749/+attachment/5263317/+files/dummy-workaround -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to net-tools in Ubuntu. https://bugs.launchpad.net/bugs/1828749 Title: ifconfig dummy0 : Device not found 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/net-tools/+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
[Touch-packages] [Bug 1828749] [NEW] ifconfig dummy0 : Device not found
Public bug reported: 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 ** Affects: net-tools (Ubuntu) Importance: Undecided Status: New ** Attachment added: "apport file describing the system" https://bugs.launchpad.net/bugs/1828749/+attachment/5263315/+files/apport.net-tools.yuq36yqq.apport -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to net-tools in Ubuntu. https://bugs.launchpad.net/bugs/1828749 Title: ifconfig dummy0 : Device not found 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/net-tools/+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
[Touch-packages] [Bug 1652381] Re: systematic way to refresh the random-seed again and again
Here's an even simpler argument why random-seed-load and random-seed-save should be seen as two separate stateless services, not as the "start" and "stop" of some single long-lived service. Suppose that during boot-up, random-seed-load fails for some reason. There are definitely ways this could happen. (OTOH there are a surprising number of things that could go wrong that systemd-random-seed save does /not/ report as an error ... but that is a topic for another day.) Now suppose that in the minutes, hours, or days that follow, the problem is resolved. Desired behavior: We really want the 'save' service to be performed at shutdown. The currently-observed behavior is that if 'load' failed then 'save' will never be performed. This is a Bad Thing from the security point of view. Splitting the services as discussed above makes this issue (among others) go away. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1652381 Title: systematic way to refresh the random-seed again and again Status in systemd package in Ubuntu: New Bug description: Background and rationale: There ought to be a nice systematic way to refresh the random-seed again and again, while the system is running normally, not just at boot time or at shutdown time. Sometimes a system may crash without carrying out an orderly shutdown. Indeed some systems never carry out an orderly shutdown; they run until they die. Therefore all the reasons why it is important to refresh the random-seed during shutdown are also good reasons for refreshing it from time to time during normal operations ... not just at startup. Desired behavior: The logical, systematic, traditional, and expected way to refresh the seed would be either "systemctl start systemd- random-seed" or equivalently "/etc/init.d/urandom start". The command should happily run as many times as desired, and should refresh the random-seed each time. Observed behavior: "systemctl start systemd-random-seed" doesn't have the desired effect. Apparently systemd considers the previous instance of systemd-random-seed.service to be still active, so additional starts don't do any good. Furthermore, "/etc/init.d/urandom start" has been re-implemented in terms of "systemctl start systemd-random-seed", so that doesn't work either. This is a significant regression relative to the pre-systemd behavior. Constructive suggestion. See attached patch. Recipe: :; systemctl start systemd-random-seed -- Observe that /var/lib/systemd/random-seed does not get refreshed. :; systemctl stop systemd-random-seed -- Apply the patch. :; systemctl daemon-reload :; systemctl start systemd-random-seed :; sleep 60 :; systemctl start systemd-random-seed -- observe that the seed now does get refreshed. There may be other ways of dealing with the issue, but this seems nice and simple. Tangent: In a non-essential way, this might touch on decisions about how best to address https://bugs.launchpad.net/bugs/1651947 Digression: There is a policy question as to how often to refresh the seed during normal operations. That is a question for another day. --- Observed on :; lsb_release -rd Description:Ubuntu 16.04.1 LTS Release:16.04 :; apt-cache policy systemd systemd: Installed: 229-4ubuntu13 Candidate: 229-4ubuntu13 Version table: *** 229-4ubuntu13 500 500 http://ubuntu.cs.utah.edu/ubuntu xenial-updates/main amd64 Packages 100 /var/lib/dpkg/status 229-4ubuntu10 500 500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages 229-4ubuntu4 500 500 http://ubuntu.cs.utah.edu/ubuntu xenial/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1652381/+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
[Touch-packages] [Bug 1652381] Re: systematic way to refresh the random-seed again and again
OK, I implemented approach (2) from the previous comment. The work consists of six steps, in two groups of three: ++ create system/systemd-random-seed-load.service ++ create system/systemd-random-seed-save.service -- get rid of the old system/systemd-random-seed.service ++ create system/sysinit.target.wants/systemd-random-seed-load.service ++ create system/shutdown.target.wants/systemd-random-seed-save.service -- get rid of the old system/sysinit.target.wants/systemd-random-seed.service The two new .service files are simple and straightforward. See attached patch. I retract my previous speculation about reimplementing the old systemd-random-seed.service because AFAICT it was only invoked from sysinit.target ... and anybody else who tried it almost certainly wasn't getting acceptable results. We must drop the whole idea of a systemd-random-seed "service" with an active state bookended by a single start-event and a single stop-event. That might have seemed elegant at first glance, but it did not capture the right semantics. It did not meet the security needs. Implementing two separate one-shot services does what is needed. It is close to the longstanding init.d/urandom behavior. ** Patch added: "two separate one-shot random-seed services" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1652381/+attachment/4796118/+files/random-seed.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1652381 Title: systematic way to refresh the random-seed again and again Status in systemd package in Ubuntu: New Bug description: Background and rationale: There ought to be a nice systematic way to refresh the random-seed again and again, while the system is running normally, not just at boot time or at shutdown time. Sometimes a system may crash without carrying out an orderly shutdown. Indeed some systems never carry out an orderly shutdown; they run until they die. Therefore all the reasons why it is important to refresh the random-seed during shutdown are also good reasons for refreshing it from time to time during normal operations ... not just at startup. Desired behavior: The logical, systematic, traditional, and expected way to refresh the seed would be either "systemctl start systemd- random-seed" or equivalently "/etc/init.d/urandom start". The command should happily run as many times as desired, and should refresh the random-seed each time. Observed behavior: "systemctl start systemd-random-seed" doesn't have the desired effect. Apparently systemd considers the previous instance of systemd-random-seed.service to be still active, so additional starts don't do any good. Furthermore, "/etc/init.d/urandom start" has been re-implemented in terms of "systemctl start systemd-random-seed", so that doesn't work either. This is a significant regression relative to the pre-systemd behavior. Constructive suggestion. See attached patch. Recipe: :; systemctl start systemd-random-seed -- Observe that /var/lib/systemd/random-seed does not get refreshed. :; systemctl stop systemd-random-seed -- Apply the patch. :; systemctl daemon-reload :; systemctl start systemd-random-seed :; sleep 60 :; systemctl start systemd-random-seed -- observe that the seed now does get refreshed. There may be other ways of dealing with the issue, but this seems nice and simple. Tangent: In a non-essential way, this might touch on decisions about how best to address https://bugs.launchpad.net/bugs/1651947 Digression: There is a policy question as to how often to refresh the seed during normal operations. That is a question for another day. --- Observed on :; lsb_release -rd Description:Ubuntu 16.04.1 LTS Release:16.04 :; apt-cache policy systemd systemd: Installed: 229-4ubuntu13 Candidate: 229-4ubuntu13 Version table: *** 229-4ubuntu13 500 500 http://ubuntu.cs.utah.edu/ubuntu xenial-updates/main amd64 Packages 100 /var/lib/dpkg/status 229-4ubuntu10 500 500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages 229-4ubuntu4 500 500 http://ubuntu.cs.utah.edu/ubuntu xenial/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1652381/+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
[Touch-packages] [Bug 1652381] Re: systematic way to refresh the random-seed again and again
I retract patch and recipe mentioned in the initial report. The problem is messier than I initially thought. One fundamental consideration is that apparently systemctl won't start a service that is marked active, and won't stop a service that is marked inactive. This is inconsistent with longstanding initscript behavior, where you can start (or stop) something as many times as you like. 0) Simple question: Is there a way to teach the system to ignore the nominal state and just run ExecStart or ExecStop as directed? Maybe type=stateless rather than type=oneshot? This would make things a whole lot simpler. 1) Arguably "most" of the problem goes away if we document "restart" (as in "systemctl restart systemd-random-seed") as the proper way to refresh the seed. That leaves init.d/urandom in a bad state, because it knows nothing of "restart". 2) Here's another approach to consider: A paire of separate services: systemctl start systemd-random-seed-load and systemctl start systemd-random-seed-save The latter is /started/ (not stopped!) at shutdown time. Neither service has an ExecStop method. Neither service ever becomes active. Either one can be started as many times as desired, in any order. This is the only way I can think of to capture the semantics of the longstanding init.d/urandom script. The present systemd-random-seed script can trivially be reimplemented in terms of the new pair of services. This approach (2) would still require some changes to init.d/urandom, but not quite as ugly as approach (1) would require. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1652381 Title: systematic way to refresh the random-seed again and again Status in systemd package in Ubuntu: New Bug description: Background and rationale: There ought to be a nice systematic way to refresh the random-seed again and again, while the system is running normally, not just at boot time or at shutdown time. Sometimes a system may crash without carrying out an orderly shutdown. Indeed some systems never carry out an orderly shutdown; they run until they die. Therefore all the reasons why it is important to refresh the random-seed during shutdown are also good reasons for refreshing it from time to time during normal operations ... not just at startup. Desired behavior: The logical, systematic, traditional, and expected way to refresh the seed would be either "systemctl start systemd- random-seed" or equivalently "/etc/init.d/urandom start". The command should happily run as many times as desired, and should refresh the random-seed each time. Observed behavior: "systemctl start systemd-random-seed" doesn't have the desired effect. Apparently systemd considers the previous instance of systemd-random-seed.service to be still active, so additional starts don't do any good. Furthermore, "/etc/init.d/urandom start" has been re-implemented in terms of "systemctl start systemd-random-seed", so that doesn't work either. This is a significant regression relative to the pre-systemd behavior. Constructive suggestion. See attached patch. Recipe: :; systemctl start systemd-random-seed -- Observe that /var/lib/systemd/random-seed does not get refreshed. :; systemctl stop systemd-random-seed -- Apply the patch. :; systemctl daemon-reload :; systemctl start systemd-random-seed :; sleep 60 :; systemctl start systemd-random-seed -- observe that the seed now does get refreshed. There may be other ways of dealing with the issue, but this seems nice and simple. Tangent: In a non-essential way, this might touch on decisions about how best to address https://bugs.launchpad.net/bugs/1651947 Digression: There is a policy question as to how often to refresh the seed during normal operations. That is a question for another day. --- Observed on :; lsb_release -rd Description:Ubuntu 16.04.1 LTS Release:16.04 :; apt-cache policy systemd systemd: Installed: 229-4ubuntu13 Candidate: 229-4ubuntu13 Version table: *** 229-4ubuntu13 500 500 http://ubuntu.cs.utah.edu/ubuntu xenial-updates/main amd64 Packages 100 /var/lib/dpkg/status 229-4ubuntu10 500 500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages 229-4ubuntu4 500 500 http://ubuntu.cs.utah.edu/ubuntu xenial/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1652381/+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
