Could you please inspect the ppp case? I assumend the ppp is supported by NM. Is there anything missing? +++ This bug was initially created as a clone of Bug #1643763 +++ Description of problem: Ever since 'upgrading' to Fedora 29 I notice that `ifdown ppp0` now produces: WARN : [ifdown] You are using 'ifdown' script provided by 'network-scripts', which are now deprecated. WARN : [ifdown] 'network-scripts' will be removed from distribution in near future. WARN : [ifdown] It is advised to switch to 'NetworkManager' instead - it provides 'ifup/ifdown' scripts as well. This is impractical as this box does not run NetworkManager, has no use case for NetworkManager, and we think NetworkManager is overkill for something as simple as this. Furthermore ppp0 does not really go down as asked; the process stays up but the connection is gone. When running Fedora 28 things worked beautifully and pppd would be shut down. So we kill pppd manually and restart the ppp0 connection with: # ifup ppp0 WARN : [ifup] You are using 'ifup' script provided by 'network-scripts', which are now deprecated. WARN : [ifup] 'network-scripts' will be removed from distribution in near future. WARN : [ifup] It is advised to switch to 'NetworkManager' instead - it provides 'ifup/ifdown' scripts as well. ERROR : [/etc/sysconfig/network-scripts/ifup-eth] Device ppp0 does not seem to be present, delaying initialization. This does not work anymore. This means that functionality was intentionally destroyed. ifcfg-ppp0 is still present and used to steer ifup to /sbin/adsl-start. If a distro starts to `manipulate` functionality to favour an invalid solution, if a distro fails to see that there's use cases beyond NetworkManager, if a distro does not allow to enter the 'network-scripts' name in the Component field, then what must a user think? Version-Release number of selected component (if applicable): network-scripts-10.01-1.fc29.x86_64 How reproducible: Run Fedora 28 on firewall, notice how ifup/ifdown work as intended. `Upgrade` to fedora 29. Try to bring down the ppp0 connection. Actual results: See above. Expected results: # ifdown ppp0 # # ifup ppp0 # Additional info: Please change to component network-scripts if you can; I can't. This is marked Urgent as this a very confronting discovery. --- Additional comment from udo on 2018-10-28 16:13:01 CET --- More proof from a different machine: # rpm -qf /usr/sbin/ifup network-scripts-10.01-1.fc29.x86_64 NetworkManager-1.12.4-1.fc29.x86_64 If that is allowed to be a a situation, then why do we use rpms? # file /usr/sbin/ifup /usr/sbin/ifup: symbolic link to /etc/alternatives/ifup # file /etc/alternatives/ifup /etc/alternatives/ifup: symbolic link to /etc/sysconfig/network-scripts/ifup # file /etc/sysconfig/network-scripts/ifup /etc/sysconfig/network-scripts/ifup: Bourne-Again shell script, ASCII text executable # rpm -qf /etc/sysconfig/network-scripts/ifup network-scripts-10.01-1.fc29.x86_64 # ifup eth0 WARN : [ifup] You are using 'ifup' script provided by 'network-scripts', which are now deprecated. WARN : [ifup] 'network-scripts' will be removed from distribution in near future. WARN : [ifup] It is advised to switch to 'NetworkManager' instead - it provides 'ifup/ifdown' scripts as well. # rpm -q NetworkManager NetworkManager-1.12.4-1.fc29.x86_64 What is the benefit of ifup/ifdown in the NM rpm when NM has its own mechanism to manipulate interfaces? network-scripts provides an opportunity for choice, for a certain amount of freedom. We have NM on the other box for other unfree reasons, but the scripts still show the same message; i.e.: the intended situation is thus not met. (install NM and get rid of the mutilated scripts as NM has ifup as well)
From the original report, it does not seem that NetworkManager is involved. NetworkManager supports pppoe, and it supports for example starting ppp for a WWAN connection. However, there is no corresponding functionality to run pppd directly. I also don't think that it would make sense: in NetworkManager you configure a profile to connect to a certain type of network. That may or may not involve pppd as an implementation detail. For example, there is no mechanism to run pppd which honours /etc/ppp/peers (nor would be be desirable, because the connection profile in NetworkManager should contain the entire configuration). So no. NetworkManager doesn't have a replacement for ifup-ppp. > ERROR : [/etc/sysconfig/network-scripts/ifup-eth] Device ppp0 does not seem > to be present, delaying initialization. why does this call ifup-eth to handle an interface name ppp0? Looks like a fault ifcfg file to me.
We do not run NetworkManager on this box. There is no use case for NetworkManager on this box. (overkill of a construct like NetworkManager versus simple startup scripts, ping job, etc. The ifcfg file was unchanged for many, many months: NETWORKING_IPV6=yes IPV6INIT=yes IPV6FORWARDING=yes ONBOOT=no TYPE=xDSL PEERDNS=no DEVICE=ppp0 DEFROUTE=yes DEVNAME=adsl NS1=127.0.0.1 SEARCH="hierzo" DOMAIN="hierzo" This /used/ to cause that /sbin/adsl-start was called. After the upgrade it doesn't.
It's not clear to me that NetworkManager does anything wrong here (since it doesn't run). I am inclined to close this as NOTABUG. Objections? Suggestions?
So with that mentioned configuration and without network-scripts installed the NM will successfully start the network?
NetworkManager was chosen because: - network-scripts is not available as choice for component - NetworkManager is asvertised as 'solution' I simply need a fix for this issue. NM is a bug as it cannot handle USB ethernet, has no added value in static situations, is overkill for a static situation, and has no place on a working headless setup like this one.
(In reply to Lukáš Nykrýn from comment #4) > So with that mentioned configuration and without network-scripts installed > the NM will successfully start the network? There is no NetworkManager on that box. So why would I need one now? The script functionality is sufficient. Pushing 1.6 MB versus 63.1 KB. If this is forced I am forced too. There is enough to be changed in Fedora...
Please see my comment https://bugzilla.redhat.com/show_bug.cgi?id=1643763#c2
Why would I need another daemon for somethign that currently does not need one. NM logging is too much. Support experience was bad. And you making choices like this is even worse. NM is not unix, is not freedom and is simply more bugs. Fedora is becoming worse and worse and this is another step. Replacing scripts by NM is gearing up the complexity by at least 10^5. Expecting users in the same situation as me to understand this and to simply follow that is beyond weird. Please do respect my freedom of choice. Please do respect that simple solutions work best. Please respect that bloat is not the future. Support on scripts is too much?! But we do have support on NM? (multiple times the code size of the scripts) You already made a choice by making network-scripts a non-component in bugzilla.
This was a report about NM and ppp. I would be happy to answer any reasonable question, but please let's either continue in the original bug or you can start a mail thread.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
The core issue is forcing the user to use NM. This drive the split, this drove the `mutilation` AKA advertisement for NM scripts. NM has no use case here. We do not use wifi, have no mobile stuff, have solid wired connections. Scripts work fine, so why replace the few lines of shell scripts with something way more complex, way more featured, way more bugs?
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
The idea to drop a few kilobytes of shell scripts in favor of a multi megabyte C jubgle that is network-manager, even for simple static instalaltions is beyond me. There is no benefit. Nothing has changed here.
And we do deliver multiple bootloaders, databses, GUIs, etc, so why oh why is this few KB of scripts a problem? Because systemd-ism: everythign needs to put into ever larger daemons with feature creap and bad habits w.r.t. logging. The idea is as illogical as is the behemoth you call NetworkManager: when put on a machine with statis interface where the scripts perform up/down actions noiselessly. Enter NM: logging is abundant, especially when at 'info' and the config is at TRACE. (stock!) I.e.: the people repsonsible for the code did never ever consider a situation beyond testing. So why is this product put onto the people that do not want it? Since when doesn't Fedora have time to properly deliver the RPMS it wants to deliver?
And the support on gnome-shell is of the exemplarish kind? I.e.: support via this way is not an argument at all.
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.