[hardy] "ip" broken

Hi,

Do you get that error message for all usage of ip, or just that particular one?
Also, can you please post the result of "uname -a"?

Thanks

Linux nodea 2.6.21-prep #11 SMP Tue Feb 12 19:15:35 UTC 2008 x86_64 GNU/Linux

This is the stock RH kernel with Xen extensions built from source .. you know why I'm not using the Ubuntu Kernel (!)

I can confirm this bug on hardy.

simple steps to reproduce

ip link set eth0 down
<RTNETLINK answers: Invalid argument>

This is called by the Xen network-bridge script also.

fixed by installing hardy iproute package with --force-depends (since libdb package is missing from the repos)

This is a pretty major bug. It might be a amd64 bug....

I can't reproduce this in Hardy - however I'm not using xen.

libdb is in fact in gutsy main so the force-depends shouldn't be necessary.

I am doing a fresh install and upgrade to latest gutsy.

I will make sure I can reproduce it in that situation

latest hardy i meant...

iproute at alpha6 does seem to work.

I am still downloading updates and them will need to install the ubuntu-xen-server package.

I don't see how the xen packages could break the ip command, but I guess it could be possible....

it seems that i can't reproduce this problem on the hardy then kernel.

it is possible it only happens on the Xen kernel from http://xen.org/download/

It might be a few days before i can test further as we need to do some benchmarks on Xen and KVM in a working state.

I can't test more later.

This bug (bug #199533) still exists and might or might not be related. Again, more testing is needed.

https://bugs.launchpad.net/ubuntu/+source/xen-3.2/+bug/199533

I meant to say I *can* test more later.

sorry for the confusion.

any other testers appreciated :)

Also I can confirm this bug on hardy with OpenVZ kernel.

root@hnode02:~# uname -a
Linux hnode02 2.6.18-fza-028stab053.5-amd64 #1 SMP Sat Mar 1 19:50:43 UTC 2008 x86_64 GNU/Linux

Bye.

fdb: did you install the older versions of iproute and libdb to work around the problem?

Ok, I have pinned the iproute package in /etc/apt/preferences

Package: iproute
Pin: release a=gutsy
Pin-Priority: 900

Then I have removed iproute and reinstalled all packages removed (also the old libldap-2.4-2 and iproute 20070313-1ubuntu2)

Now it work...but is a dirty solution!

Thank you!
Bye

I don't know if this should be forward to OpenVZ Ubuntu team.

I make a mistake, it don't work:
with old iproute i don't get RTNETLINK error but ARP requests to OpenVZ VE aren't resolved so VM aren't reachable via network.

Moreover during startup of VE I get:

Starting VE ...
VE is mounted
Adding IP address(es): 192.168.100.110
[: 42: ==: unexpected operator
Setting CPU units: 2013
Configure meminfo: 36234
Set hostname: www.altraqua.com
File resolv.conf was modified
VE start in progress...

The "unexpected operator" error seem due to function vzarp() exactly command at line 146 of /usr/lib/vzctl/scripts/vps-functions.

I have another server NOT amd64 (Xeon) with 8.04 and openvz up and running.

Does ubuntu have an OpenVZ package or a OpenVZ team?

You should add the package that it affects if so.

Are you able to see a fix for it. Most likely it is fixed upstream right?

Someone are working on hardy-openvz kernel:
http://git.openvz.org/?p=ubuntu-hardy-openvz;a=summary

Ok, I'll wait for release.

Bye.

The info for iproute lists ubuntu-core-dev as the maintainers. Please reassign if I'm making a mistake.

I'm sorry to say but this is actually 1/2 user error and 1/2 xen logistics. Xen while creating the briding for DomU's, renames eth0 to peth0. You can verify this by running "chmod -x /etc/init.d/xend ; reboot" and verifying that iproute works as you expect it to.

Please see http://wiki.xensource.com/xenwiki/XenNetworking for a more concise description.

Paul, "ubuntu-core-dev" is "the set of people responsible for the 'main' section of the Ubuntu archive", so it's not particularly meaningful to assign a bug to that group. :) It does get eyeballs on it, though; let's see what we come up with.

James, I'm pretty sure that this is /not/ user error wrt xen interface names; if I pass an invalid interface name, I get:

$ sudo ip link set cheesecake up
Cannot find device "cheesecake"
$

This is not the "invalid argument" error that's being reported.

However,

... gah, wrong button.

However, this bug is *not* reproducible for me with the standard hardy kernel on amd64. So far, it looks like everyone who's reporting this bug is running a non-Ubuntu kernel - can anyone reproduce this problem with an Ubuntu kernel?

This may come down to configuration issues on kernel builds that we don't control, but we need more information yet to determine that. Setting to 'incomplete'.

Information that would be useful here is:
- an strace of the ip command, showing what operation is returning the EINVAL error
- a copy of the kernel config for the kernels where this bug is visible.

Mmm,

It is true I am running a non-Ununtu kernel ...

Perhaps because the Ubuntu Xen kernel, certainly upto Gutsy, was simply too unstable to be of any use. I'm running ~ 20 Xen instances across 4 servers and spent a LONG TIME trying to make raw Ubuntu work. My eventual solution was to switch to a RH2.6.21 kernel, ALL of my problems have gone away and I now experience 100% uptime as opposed to continuous problems every day.

If you're going to tell me that I can't run Ubuntu and use a recent alternative kernel when Ubuntu's kernel is a paper weight, then you're telling me I need to switch to Fedora - which given my investment in Ubuntu I'd rather not do.

I can't think of any reason why it would not be possible to add a little flexibility into package upgrades to make them ever so slightly backwards compatible and give people a little wriggle room when Ubuntu is less than perfect (never happens obviously, but just in case ... ;-) )

Another example; they've put something rather nasty into rsync, so it generates lots of errors when you run the Gutsy version on a 2.6.21 kernel. Apparently the distro version RELIES on a specific feature in the 2.6.22 kernel ... Arhrhrhrhrhrh! Calling all programmers; don't let user-level applications fail just because someone adds "0.0.01" to a kernel version!!

Ok, I've gone back to a dapper kernel and have been able to confirm that the iproute in hardy is not compatible with a dapper kernel, whereas it is compatible with a gutsy (and, obviously, with a hardy) kernel.

So this bug is of interest for an LTS - anyone who upgrades from Ubuntu 6.06 to 8.04 will be unable to use the ip command until they've rebooted to the new kernel.

Luckily, the fix for this has already been identified by the maintainer, so we can grab it from snapshot.debian.net and have this fixed for Ubuntu 8.04.

This bug was fixed in the package iproute - 20071016-2ubuntu1

---------------
iproute (20071016-2ubuntu1) hardy; urgency=low

  * Cherry-picked merge from Debian unstable, remaining changes:
    - debian/patches/tc_qdisc_segv.patch: Fix an off-by-one error that
      causes segfaults in tc on amd64.
    - Modify Maintainer value to match the DebianMaintainerField
      specification.
    LP: #192294.

iproute (20071016-2) unstable; urgency=low

  [ Andreas Henriksson ]
  * fix incompatibility with older kernels (Closes: #457161)
    (Cherry picked from upstream)

 -- Steve Langasek <email address hidden> Sat, 12 Apr 2008 07:05:46 +0000

Hardy is a great work its ok for beginners but if you want something just not in the mainstream such as xen perhaps,
then ANYTHING like this ubuntu will fail.

It has been my misfortune since brezzy badger that I usae ubuntu its ok for the run of the mill stuff but thats IT

For a ROCK solid debian OS then its sarge, etch and the release perhaps in Sept 08 of Lenny

Ubuntu has brought many people to Linux so its still s good system I feel it needs more testing before release

alex

Alex: Hardy at the stage you were using it was in development, and there were tonns of warnings posted all over the place saying "Don't use this on production machines". You were using hardy during its testing stage, and the fix was released before Hardy :)