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.
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)
I will start a bit broadly here. In Fedora <= 28 you had three tools that could set up the network installed in the default installation. NM, initscripts (network-scripts) and scripts in dracut. But we don't have enough people to support that. In fact, right now there is nobody that would work on the initscripts package. And since we are trying to build a coherent distribution, we are trying to standardise everything on top of one solution and that is NetworkManager. I completely expect that there will be people that will not like it. We agreed on a transition period where we will still support the old scripts, but we want to make clear that the old scripts are considered deprecated now. Also, we have removed it from the default installation to see what will break and fix those problems. We are also providing compatibility commands inside NM so we won't break the existing scripts. So in short, please give NM a chance, I understand that its size might be a problem, but that is a cost for the universal solution. But if you encounter any other issue don't hesitate to file features request for NM. > Please change to component network-scripts if you can; I can't. Unfortunately, bugzilla's component is based on the list of source RPMs and network-scripts still belong under initscripts.
Why then do we have a network-scripts rpm? dracut scripts you count as a way to manage a network? So you want NM to live in the dracut ramdisk? I do not need a daemon for a network that runs without such daemon now. NM is not a replacement. Of course you already set your course in your steering committee and did not consult the critical user. This shows another problem in Fedora. Because how much support is required for the network-scripts these days? And how much support is need for NM?
(In reply to udo from comment #3) > Why then do we have a network-scripts rpm? As I wrote, it is from the transition period. If user find something missing in NM, they can still use the old package. > dracut scripts you count as a way to manage a network? Yes, if you boot from network dracut has its own set of scripts to do that. > So you want NM to live in the dracut ramdisk? Yes, it is already done in the latest version of dracut (as opt-in). > > I do not need a daemon for a network that runs without such daemon now. > NM is not a replacement. Even with NM you don't need a daemon, you can use "configure-and-quit=true" > > Of course you already set your course in your steering committee and did not > consult the critical user. > This shows another problem in Fedora. I understand you see this as a problem, but packages in Fedora are maintained by the community, we really can't force anyone to provide all of the alternatives to all tools. I would like to point out that we have not just dropped the network-script. We are willing to keep them around until we are sure that NM covers all of the possible use cases. > > Because how much support is required for the network-scripts these days? > And how much support is need for NM? There are bugs in network-scripts and there is nobody willing to work on it anymore. On the other hand, there is the whole group of engineers working on NM.
The unprofessional thing shows clearly: Due to a power outage my MythTV box had to start again after power came back. eth0 did not come up although this had worked PERFECTLY for many months. Manually issuing `ifup eth0` at the console did give us network connectivity after issuing: 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. So despite the warning the functionality really has been botchered. If a distro thinks this is acceptable this will further confirm my opinion. Writing `there is the whole group of engineers working on NM.` shows that there is no common sense and no understanding of context when a group of engineers is needed for a behemoth versus perhaps one man tinkering on the network scripts. Of course nothign will change for thegood as the decision has already been made without hearing me first.
From NetworkManager.conf manual page, part about configure-and-quit: When this option is true, network configuration for WiFi, WWAN, Bluetooth, ADSL, and PPPoE interfaces cannot be preserved due to their use of external services, and these devices will be deconfigured when NetworkManager quits even though other interface's configuration may be preserved. Does that look like it can work for my PPPoE? Why can this work without a daemon in a non-NM situation? I.e.: what problem are we creating? Is it a design issue? The lack of freedom of choice that is approaching is huge.
> Writing `there is the whole group of engineers working on NM.` shows that > there is no common sense and no understanding of context when a group of > engineers is needed for a behemoth versus perhaps one man tinkering on the > network scripts. The problem is that there is nobody willing to do the tinkering on network-scripts. Right now it is just me and I could use that time better. But anyway, you know my opinion, I know yours. The current state is that the network-scripts are deprecated and that is not going to change. So nothing to do in this bug.
So we can conclude: - The Fedora Steering Committee did not ask me about the decision to drop those hugely complex networking scripts - The Fedora Steering Committee did not ask me is I was interested to do (which!?) tasks with these hugely complex networking scripts - The Fedora Steering Committee instead chooses to go fix a hugely more complex, still buggy daemon that is not really needed in certain common situations with even more people that they cannot afford for these hugely complex networking scripts No sarcasm, just trying to portray certain views from a Unix(tm) related company.
Oh, and I forgot to mention: As a nice goodbye and to convince users to move over to the more complex, more resource hungry, more buggy solution we sabotage the hugely complex networking scripts
For an initial install on a headless server with static ip's, what are you providing for quick setup?
Assign to get an answer.
The default installation should work in such case.
Is there a mechanism to modify the 'features' on network device? My current e1000e needs to invoke "ethtool -K lan2 gso off gro off tso off" to bypass a bug. Any kind of escape mechanism?
Ethtool was deprecated long time ago. I think you should write an idea rule that will do what you need when the device shows up.
Ah.. Great stable tooling that provides a solution: https://docs.fedoraproject.org/en-US/Fedora/13/html/Deployment_Guide/s1-networkscripts-interfaces.html ETHTOOL_OPTS=<options> where <options> are any device-specific options supported by ethtool. For example, if you wanted to force 100Mb, full duplex: ETHTOOL_OPTS="autoneg off speed 100 duplex full" Instead of a custom initscript, use ETHTOOL_OPTS to set the interface speed and duplex settings.
I don't think that ethtool (the command line tool nor the ioctl API) is deprecated. And with initscripts, it continues to work with ETHTOOL_OPTS. btw, in NetworkManager this would be $ nmcli connection modify "$PROFILE" ethtool.feature-gso off ethtool.feature-gro off ethtool.feature-tso off $ nmcli connection modify "$PROFILE" ethernet.auto-negotiate off ethernet.speed 100 ethernet.duplex full Other ethtool options are not supported yet. You could wite a dispatcher script (`man NetworkManager`) or a udev rule (not sure) or your own script.
Sorry I have meant that ethtool_opts was deprecated long time ago: https://github.com/fedora-sysv/initscripts/commit/9f0c9be19a6324b161a699b68fadb4ea2349edc3
(In reply to Lukáš Nykrýn from comment #17) > Sorry I have meant that ethtool_opts was deprecated long time ago: > https://github.com/fedora-sysv/initscripts/commit/ > 9f0c9be19a6324b161a699b68fadb4ea2349edc3 - Why? - Why wasn't the documentation updated? - Why wasn't this a factor to keep networking-scripts around? (scripts could do exactly this better than NM can do right now) The whole story simply shows a lack of context by making decisions like this. (also see iio-sensors-proxy, gnome-online-accounts, bolt, etc) This means the perceived quality is negatively impacted. Does the committee want that?
(In reply to udo from comment #18) > - Why wasn't the documentation updated? Because nobody maintains the network.scripts. I will repeat myself again, but that is still the main reason for those changes. But I don't see here anything that would need a change in the initscripts package so closing again.
(In reply to Lukáš Nykrýn from comment #19) > (In reply to udo from comment #18) > > - Why wasn't the documentation updated? > Because nobody maintains the network.scripts. You did not ask me even since mentioning that before. How much would 'maintenance' cost? Who decided that? When? What was the vote like? What was the argumentation like? I assume we can all read these things or is this kakistocracy a closed entity? > but that is still the main reason for those changes. What changes? The mutilation or the text? Or both? So please let us review the commits for those changes so we can find the mutilation. > But I don't see here anything that would need a change in the initscripts > package so closing again. The ETHTOOL thing needs to be brought back, this is simply doable by reverting the removal. Fedora (the project, the committee) is grandly inflating the actual cost of maintenance for a small set of scripts versus the group (!) of peopel needed to 'maintain' NM that cannot yet cope with ethernet over USB. (while the kernel can, as far as I know)
All of the decisions were done by initscripts upstream which these days means just me. I value your opinion but all decision are done on the principles of meritocracy. And I find your talk about kakistocracy offensive to me so I will not comment this further. If anyone else reading this bug has any other technical issues please feel free to open a new bug.
*sigh* Just tried to find any mention of ethtool.feature.* in any documentation... Nothing.... If it is going to be deprecated... Some documentation or a how-to to convert? The error message is NOT (very NOT) obvious. The only reason I noticed was a huge slew of unwanted arp entries. This will catch a lot of people when it does disappear... Yeah, I can see it now. Upgrade to Fxx, and suddenly you don't have a network anymore, and you can't even google a solution....
(In reply to Chaim Frenkel from comment #22) > Just tried to find any mention of ethtool.feature.* in any documentation... > Nothing.... That is a documentation bug (bug 1614726). If NetworkManager persists the connection profile as ifcfg file (the default on Fedora), then NM also uses ETHTOOL_OPTS variable for that and it should work just the same. That means, you are welcome to edit the ifcfg file (as you used to), followed by `nmcli connection reload`. Personally, I find nmcli more convenient to use (in particular with bash completion). Also, the names of the "ethtool.feature-*" option directly corresponds to the -K arguments in `man ethtool`.
Trying to make the defect as clear as possible in as little space as possible: - `ifdown ppp0` does not kill pppd - `ifup ppp0` does not start pppd Some happenings: [root@vuurmuur ~]# ps -ef|grep ppp root 1835 1 0 Dec08 ? 00:00:07 /usr/sbin/pppd call vdsl root 1927 1 0 Dec08 ? 00:00:00 dhclient -6 -P ppp0 root 2001 1757 0 17:01 pts/0 00:00:00 grep --color=auto ppp [root@vuurmuur ~]# killall -9 pppd [root@vuurmuur ~]# 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. [root@vuurmuur ~]# ps -ef|grep ppp root 1927 1 0 Dec08 ? 00:00:00 dhclient -6 -P ppp0 root 2033 1757 0 17:02 pts/0 00:00:00 grep --color=auto ppp [root@vuurmuur ~]# /sbin/adsl-start SIOCDELRT: No such process Plugin rp-pppoe.so loaded. RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7 .1 2042 ppp0 route add default dev ppp0 ip -6 route add default dev ppp0 ---- ---- . [root@vuurmuur ~]# Prefix BOUND6 old= new=2001:181:a812::/48 I.e.: /sbin/adsl-start, which used to be called by `ifup ppp0`, does no longer get called. Same for /sbin/adsl-stop. Food for thought for the fixing of this issue. Furthermore I also noticed that on one machine, which only has the NM component NetworkManager-libnm-1.12.4-2.fc29.x86_64, the ifup-action fails on the eth0 interface during boot. I.o.w.: eth0 is not up after boot, which used to work OK. Later on, when logging onto the console I can successfully do `ifup eth0`. Both of these issues were not present in Fedora 28 and only came with the current network-scripts-10.01-1.fc29.x86_64. As you can see core functionality of this package is impacted.
> I.e.: /sbin/adsl-start, which used to be called by `ifup ppp0`, does no longer get called. Same for /sbin/adsl-stop. Food for thought for the fixing of this issue. Note that the "network-scripts" part of initscripts is very similar between f28 and f29 (aside the deprecation warning). It's unclear where they'd differ. Try running `bash -x ifup ppp0`. > Furthermore I also noticed that on one machine, which only has the NM component NetworkManager-libnm-1.12.4-2.fc29.x86_64, the ifup-action fails on the eth0 interface during boot. Not sure what you mean with "only has NM component NM-libnm". Do you have NetworkManager daemon running? Does `ifup` delegate/call to `nmcli connection up`? Anyway, it seems better to focus only on one issue at a time. In particular because you have the ppp0 failure on a system without NetworkManager.
The ppp0 issue: [root@vuurmuur ~]# bash -x ifup ppp0 [ OK ] + unset WINDOW + . /etc/init.d/functions ++ TEXTDOMAIN=initscripts ++ umask 022 ++ PATH=/sbin:/usr/sbin:/bin:/usr/bin ++ export PATH ++ '[' 1757 -ne 1 -a -z '' ']' ++ '[' -d /run/systemd/system ']' ++ case "$0" in ++ '[' -z '' ']' ++ COLUMNS=80 ++ '[' -z '' ']' ++ '[' -f /etc/sysconfig/init ']' ++ BOOTUP=color ++ RES_COL=60 ++ MOVE_TO_COL='echo -en \033[60G' ++ SETCOLOR_SUCCESS='echo -en \033[1;32m' ++ SETCOLOR_FAILURE='echo -en \033[1;31m' ++ SETCOLOR_WARNING='echo -en \033[1;33m' ++ SETCOLOR_NORMAL='echo -en \033[0;39m' ++ LOGLEVEL=1 ++ tty ++ grep --quiet -e /dev/ttyS ++ __sed_discard_ignored_files='/\(~\|\.bak\|\.old\|\.orig\|\.rpmnew\|\.rpmorig\|\.rpmsave\)$/d' ++ '[' '' = 1 ']' +++ cat /proc/cmdline ++ strstr 'BOOT_IMAGE=/vmlinuz-4.19.5-rt4 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/usr net.ifnames=0 systemd.log_level=warning selinux=0 audit=0 plymouth.enable=0 3 LANG=en_US.UTF-8 threadirqs pci=noaer initrd=/initramfs-4.19.5-rt4.img' rc.debug ++ '[' 'BOOT_IMAGE=/vmlinuz-4.19.5-rt4 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/usr net.ifnames=0 systemd.log_level=warning selinux=0 audit=0 plymouth.enable=0 3 LANG=en_US.UTF-8 threadirqs pci=noaer initrd=/initramfs-4.19.5-rt4.img' = 'BOOT_IMAGE=/vmlinuz-4.19.5-rt4 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/usr net.ifnames=0 systemd.log_level=warning selinux=0 audit=0 plymouth.enable=0 3 LANG=en_US.UTF-8 threadirqs pci=noaer initrd=/initramfs-4.19.5-rt4.img' ']' ++ return 1 ++ return 0 + cd /etc/sysconfig/network-scripts + . ./network-functions ++ PATH=/sbin:/usr/sbin:/bin:/usr/bin ++ export PATH +++ hostname ++ HOSTNAME=vuurmuur ++ '[' -z '/\(~\|\.bak\|\.old\|\.orig\|\.rpmnew\|\.rpmorig\|\.rpmsave\)$/d' ']' + '[' -f ../network ']' + . ../network ++ IPV6FORWARDING=yes + CONFIG=ppp0 + '[' -z ppp0 ']' + is_true + case "$1" in + return 1 + net_log 'You are using '\''ifup'\'' script provided by '\''network-scripts'\'', which are now deprecated.' warning ifup + local 'message=You are using '\''ifup'\'' script provided by '\''network-scripts'\'', which are now deprecated.' + local level=warning + local name=ifup + '[' -z 'You are using '\''ifup'\'' script provided by '\''network-scripts'\'', which are now deprecated.' ']' + '[' -z warning ']' + '[' -z ifup ']' + case $level in + local 'txt_level=WARN ' + echo 'WARN : [ifup] You are using '\''ifup'\'' script provided by '\''network-scripts'\'', which are now deprecated.' WARN : [ifup] You are using 'ifup' script provided by 'network-scripts', which are now deprecated. + '[' -x /usr/bin/logger ']' + /usr/bin/logger -p daemon.warning -t ifup 'You are using '\''ifup'\'' script provided by '\''network-scripts'\'', which are now deprecated.' + return 0 + net_log ''\''network-scripts'\'' will be removed from distribution in near future.' warning ifup + local 'message='\''network-scripts'\'' will be removed from distribution in near future.' + local level=warning + local name=ifup + '[' -z ''\''network-scripts'\'' will be removed from distribution in near future.' ']' + '[' -z warning ']' + '[' -z ifup ']' + case $level in + local 'txt_level=WARN ' + echo 'WARN : [ifup] '\''network-scripts'\'' will be removed from distribution in near future.' WARN : [ifup] 'network-scripts' will be removed from distribution in near future. + '[' -x /usr/bin/logger ']' + /usr/bin/logger -p daemon.warning -t ifup ''\''network-scripts'\'' will be removed from distribution in near future.' + return 0 + net_log 'It is advised to switch to '\''NetworkManager'\'' instead - it provides '\''ifup/ifdown'\'' scripts as well.' warning ifup + local 'message=It is advised to switch to '\''NetworkManager'\'' instead - it provides '\''ifup/ifdown'\'' scripts as well.' + local level=warning + local name=ifup + '[' -z 'It is advised to switch to '\''NetworkManager'\'' instead - it provides '\''ifup/ifdown'\'' scripts as well.' ']' + '[' -z warning ']' + '[' -z ifup ']' + case $level in + local 'txt_level=WARN ' + echo 'WARN : [ifup] It is advised to switch to '\''NetworkManager'\'' instead - it provides '\''ifup/ifdown'\'' scripts as well.' WARN : [ifup] It is advised to switch to 'NetworkManager' instead - it provides 'ifup/ifdown' scripts as well. + '[' -x /usr/bin/logger ']' + /usr/bin/logger -p daemon.warning -t ifup 'It is advised to switch to '\''NetworkManager'\'' instead - it provides '\''ifup/ifdown'\'' scripts as well.' + return 0 + need_config ppp0 + local nconfig + CONFIG=ifcfg-ppp0 + '[' -f ifcfg-ppp0 ']' + return + '[' -f ifcfg-ppp0 ']' + '[' 0 '!=' 0 ']' + source_config + CONFIG=ifcfg-ppp0 + DEVNAME=ppp0 + . /etc/sysconfig/network-scripts/ifcfg-ppp0 ++ 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 + '[' -r keys-adsl ']' + case "$TYPE" in + DEVICETYPE=ppp + '[' -n '' ']' + '[' -n '' ']' + '[' -z ppp0 -a -n '' ']' + '[' -z ppp ']' + '[' -z '' -a -n '' ']' + '[' -z '' ']' + REALDEVICE=ppp0 + '[' -z '' ']' + SYSCTLDEVICE=ppp0 + '[' ppp0 '!=' ppp0 ']' + ISALIAS=no + is_nm_running + dbus-send --system --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetNameOwner string:org.freedesktop.NetworkManager + '[' foo = fooboot ']' + '[' -n '' ']' + '[' -n '' -a xDSL = Bridge ']' + '[' '' = true -a -n '' -a ppp0 '!=' lo ']' + '[' '' = yes ']' + '[' '' = bootp -o '' = dhcp ']' + '[' -x /sbin/ifup-pre-local ']' + OTHERSCRIPT=/etc/sysconfig/network-scripts/ifup-ppp + '[' '!' -x /etc/sysconfig/network-scripts/ifup-ppp ']' + OTHERSCRIPT=/etc/sysconfig/network-scripts/ifup-xDSL + '[' '!' -x /etc/sysconfig/network-scripts/ifup-xDSL ']' + OTHERSCRIPT=/etc/sysconfig/network-scripts/ifup-eth + exec /etc/sysconfig/network-scripts/ifup-eth ifcfg-ppp0 ERROR : [/etc/sysconfig/network-scripts/ifup-eth] Device ppp0 does not seem to be present, delaying initialization. [root@vuurmuur ~]# /sbin/adsl-start SIOCDELRT: No such process Plugin rp-pppoe.so loaded. RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7 .1 4086 ppp0 route add default dev ppp0 SIOCADDRT: File exists ip -6 route add default dev ppp0 ---- ---- . (etc) On this box no NM component is present. I see no attempts for /sbin/adsl-start. The ifcfg-ppp0 file was not changed recently: [root@vuurmuur network-scripts]# ls -l ifcfg-ppp0 -rw-r--r-- 1 root root 481 Feb 24 2017 ifcfg-ppp0 The *other* (eth0 issue) box has it installed because: # rpm -e NetworkManager-libnm-1.12.4-2.fc29.x86_64 nm-connection-editor-1.8.18-2.fc29.x86_64 libnma-1.8.18-2.fc29.x86_64 error: Failed dependencies: libnm.so.0()(64bit) is needed by (installed) tracker-2.0.3-1.fc28.x86_64 libnm.so.0()(64bit) is needed by (installed) gnome-control-center-3.30.2-1.fc29.x86_64 libnm.so.0()(64bit) is needed by (installed) gnome-settings-daemon-3.30.1.2-2.fc29.x86_64 libnm.so.0()(64bit) is needed by (installed) gnome-shell-3.30.2-1.fc29.x86_64 libnm.so.0(libnm_1_0_0)(64bit) is needed by (installed) tracker-2.0.3-1.fc28.x86_64 libnm.so.0(libnm_1_0_0)(64bit) is needed by (installed) gnome-control-center-3.30.2-1.fc29.x86_64 libnm.so.0(libnm_1_0_0)(64bit) is needed by (installed) gnome-settings-daemon-3.30.1.2-2.fc29.x86_64 libnm.so.0(libnm_1_0_0)(64bit) is needed by (installed) gnome-shell-3.30.2-1.fc29.x86_64 libnm.so.0(libnm_1_2_0)(64bit) is needed by (installed) gnome-control-center-3.30.2-1.fc29.x86_64 nm-connection-editor is needed by (installed) gnome-control-center-3.30.2-1.fc29.x86_64 libnma(x86-64) is needed by (installed) gnome-shell-3.30.2-1.fc29.x86_64 libnma.so.0()(64bit) is needed by (installed) gnome-control-center-3.30.2-1.fc29.x86_64 libnma.so.0(libnma_1_2_0)(64bit) is needed by (installed) gnome-control-center-3.30.2-1.fc29.x86_64 (dependency hell!) This package NetworkManager-libnm-1.12.4-2.fc29.x86_64 holds no daemon. Just locale and libs.
> The *other* (eth0 issue) box has it installed because: > # rpm -e NetworkManager-libnm-... libnm and libnma are shared libraries. That doesn't mean you need NetworkManager (the daemon) installed nor required to run. It's fine to have the libraries installed and that a few programs will load these libraries. Of course, they won't use NetworkManager (the daemon) nor offer that functionality. But apart from that, they should work just fine. Yes, there is an certain overhead of having an unused library. But it would cost effort to fix that, only to get a desktop environment which cannot configure the network (via the GUI). Btw. compare to KDE, where you can uninstall "plasma-nm" package or other DEs that don't have any native integration and all use nm-applet/nm-connection-editor. gnome-control-center requiring nm-connection-editor maybe should be relaxed (because gnome-control-center's networking panel already does something similar as nm-connection-editor, but more streamlined, less options). On the other hand, you merely save a few megabytes of disk space by removing it. Probably not worth the effort. Do `dnf remove NetworkManager` to remove NM. That's it. Anyway, if you don't have NetworkManager (the daemon) running, then NM is innocent when `ifup` fails.
> + OTHERSCRIPT=/etc/sysconfig/network-scripts/ifup-ppp > + '[' '!' -x /etc/sysconfig/network-scripts/ifup-ppp ']' > + OTHERSCRIPT=/etc/sysconfig/network-scripts/ifup-xDSL > + '[' '!' -x /etc/sysconfig/network-scripts/ifup-xDSL ']' > + OTHERSCRIPT=/etc/sysconfig/network-scripts/ifup-eth > + exec /etc/sysconfig/network-scripts/ifup-eth ifcfg-ppp0 # dnf provides /etc/sysconfig/network-scripts/ifup-ppp # dnf install network-scripts-ppp ?
(In reply to Thomas Haller from comment #28) > # dnf install network-scripts-ppp > > ? Yes! That fixed the ppp issue. (T H A N K S !) Why didn't this rpm get installed when moving to fedora 29? Perhaps a missing dependency?
How to debug the eth0 issue which appears on boot?
(In reply to udo from comment #29) > (In reply to Thomas Haller from comment #28) > > # dnf install network-scripts-ppp > > > > ? > > Yes! That fixed the ppp issue. (T H A N K S !) > > Why didn't this rpm get installed when moving to fedora 29? Perhaps a > missing dependency? I think https://src.fedoraproject.org/rpms/ppp/c/bb9869600908ae815942efa1115cce1da4bcf10d?branch=f29 is wrong. To my understanding, it should specify "Provides"/"Obsoletes" so that on update the package is installed.
(In reply to udo from comment #30) > How to debug the eth0 issue which appears on boot? you could write "set -x" on top of /etc/rc.d/init.d/network, reboot, and look at the log.
Hmm... Your suggestion doesn't seem to do the trick... # nmcli connection modify lan2 ethtool.feature.gso off Error: invalid or not allowed setting 'ethtool': 'ethtool' not among [connection, 802-3-ethernet (ethernet), 802-1x, dcb, ipv4, ipv6, tc, proxy].
(In reply to Thomas Haller from comment #32) > (In reply to udo from comment #30) > > How to debug the eth0 issue which appears on boot? > > you could write "set -x" on top of /etc/rc.d/init.d/network, reboot, and > look at the log. I'll try that later this week!
(In reply to Chaim Frenkel from comment #33) > Hmm... Your suggestion doesn't seem to do the trick... > > > # nmcli connection modify lan2 ethtool.feature.gso off > Error: invalid or not allowed setting 'ethtool': 'ethtool' not among > [connection, 802-3-ethernet (ethernet), 802-1x, dcb, ipv4, ipv6, tc, proxy]. ah right. Added in NetworkManager 1.14.0 (Fedora 29 has 1.12.something).
So it was time to reboot the machine with the eth0 issue. 'set -x' in /etc/rc.d/init.d/network. I did not find anything related in dmesg nor /var/log/messages. Where do I need to look? After the reboot `ifup eth0` fixes the networking, something that worked beautifully well (automagically!) until fedora 29 came along.
So we checked `chkconfig --list`. And we asked: who disabled 'network'? I did not.
I think we have a valid issue here, so I am reopening this BZ. If you install network-scripts on Fedora 29, it would follow that the network service should be enabled. After installing network-scripts: [dsneddon@localhost ~]$ sudo chkconfig --list [...] network 0:off 1:off 2:off 3:off 4:off 5:off 6:off Upon reboot, none of the interfaces in /etc/sysconfig/network-scripts/ifcfg-* with NM_CONTROLLED=no start on boot, even if ONBOOT=yes is set. Shouldn't the network service be enabled when network-scripts is installed? Otherwise, the network-scripts will not function as expected. Note that this problem is affecting Red Hat OpenStack Platform testing on Fedora 29.
I think the actual issue in this bug is comment 31, and thus it should be reassigned to ppp. > I think we have a valid issue here, so I am reopening this BZ. If you install network-scripts on Fedora 29, it would follow that the network service should be enabled. I don't see how this issue is related to the things discussed here. Could you please open a separate bug? Thank you. What does "systemctl status network.service" say? Did you issue a daemon-reload after installing the package?
(In reply to Thomas Haller from comment #39) > I think the actual issue in this bug is comment 31, and thus it should be > reassigned to ppp. That makes sense. > I don't see how this issue is related to the things discussed here. Could > you please open a separate bug? Thank you. Done, we can continue the discussion here: https://bugzilla.redhat.com/show_bug.cgi?id=1667265 > > What does "systemctl status network.service" say? Did you issue a > daemon-reload after installing the package? [dsneddon@localhost ~]$ systemctl status network.service ● network.service - LSB: Bring up/down networking Loaded: loaded (/etc/rc.d/init.d/network; generated) Active: inactive (dead) Docs: man:systemd-sysv-generator(8) I did not issue a daemon-reload after installing the package, but I did reboot.
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.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-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 '30'. 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 30 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 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.
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 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. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.