Description of problem: Some recent changes cause the following error output Error: an inet prefix is expected rather than "0/0". Error: an inet prefix is expected rather than "0/0". Closer check shows that this happens in /etc/sysconfig/network-scripts/ifdown-post and 'sh -x' shows this: ..... + check_default_route + LC_ALL=C + ip route list match 0/0 Error: an inet prefix is expected rather than "0/0". + grep -q default + '[' eth = ippp -o eth = isdn ']' + add_default_route eth1 + . /etc/sysconfig/network ++ NETWORKING=yes ++ HOSTNAME=localhost.localdomain ++ NOZEROCONF=yes ++ NETWORKING_IPV6=no + check_default_route + LC_ALL=C + ip route list match 0/0 Error: an inet prefix is expected rather than "0/0". ..... The device in question is actually configured that way: # ip addr show dev eth1 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:02:b3:a3:60:e4 brd ff:ff:ff:ff:ff:ff inet 192.168.23.192/24 brd 192.168.23.255 scope global eth1 inet 192.168.1.3/24 brd 192.168.1.255 scope global eth1:0 inet6 fe80::202:b3ff:fea3:60e4/64 scope link valid_lft forever preferred_lft forever # ip ro 192.168.23.0/24 dev eth1 proto kernel scope link src 192.168.23.192 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.3 default via 192.168.23.254 dev eth1 with eth1 configured via DHCP and a static alias. Version-Release number of selected component (if applicable): initscripts-8.80-1 How reproducible: always Additional info The error in question showed up after 20080827 rawhide changes so maybe is should charged to iproute-2.6.26-1.fc10 which showed up in this set?
Hm, iproute no longer seems to take 0/0, only 0.0.0.0/0. Is this intentional?
Well, the correct address _is_ 0.0.0.0/0. I try to investigate which patch did the change and if it's intentional. But in the meantime it should be fixed in dhclient #460577 and in initscripts (not sure which package is responsible). I'm persuade that using whole address can't do any harm in the future.
Can be fixed for rawhide; I'd prefer not to have to push this back to prior releases, though.
CC'ing dhclient maintainer.
http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=b4a2679dfeee219db109dd1259e3519263ed4773
I'm not seeing the problem that pushing this to other releases (F9 in particular) would cause -- I see no breakage potential at least.
What I mean is that if the ip change is pushed back, we're forced to upgrade initscripts wherever the /sbin/ip change goes... I'd rather avoid that if possible. (Especially since there may be other scripts using the old syntax.)
The problem with abbreviate addresses was fixed in upstream of iproute and I'll do update for F-9. Please let's the init scripts as they are. It's better to use whole address in them.
*sigh* OK, I'll push the initscripts changes to F-9 too at some point, but are we sure there aren't other scripts that will break on Fedora 9 with this?
initscripts-8.76.4-1 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/initscripts-8.76.4-1
I'm sorry I want to say: leave F-9 as it is although it's better to use whole address. Using whole address from rawhide is fine for me.
Ah, ok. Thanks!
Thanks for fixing this bug. I had fixed it manually in my initscripts and I forgot to report it. Awesome job guys.
initscripts-8.76.4-1 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
iproute-2.6.26-1 has been pushed to F8 updates and has the same error messages. What is the action..update iproute to F9 version or wait for new initscripts.
Oof, do we really need new feature updates to F8 at this point?
I'm sorry, I updated without the patch which fix "address problem" :( It has been fixed in next update.