"Configuring network interfaces...execvp of 'uml_net' failed - errno = 2" error msg

Hi all,
I am trying to integrate 2.6.x support to debian and I encountered a blocking issue on networking configuration.
If you use the 2.4.x uml kernel the UML image work fine with network, but if you use an available 2.6.x uml image or a 2.6.x image of mine the uml bootstrap phase hangs with the following error message:

Setting up networking...done.
* /etc/network/options is deprecated.
Setting up IP spoofing protection...done (rp_filter). Configuring network interfaces...execvp of 'uml_net' failed - errno = 2

From previous messages I read that this concerns uml_net and its permissions.

Do you have an idea how to work around this issue? I also need it to apply to the future debian uml support.

Thank you in advance

Cheers

SteX

Quoted 3 lines

If you use the 2.4.x uml kernel the UML image work fine with network, but if you use an available 2.6.x uml image or a 2.6.x image of mine the uml bootstrap phase hangs with the following error message:

Indeed on the same machine and with same config? It's strange, I never saw

this incompatibility, and I can't find bugs in the code able to produce this (with a quick look). Could you check on your part?

Quoted 4 lines

Setting up networking...done.
* /etc/network/options is deprecated.
Setting up IP spoofing protection...done (rp_filter). Configuring network interfaces...execvp of 'uml_net' failed - errno = 2

Quoted 2 lines

From previous messages I read that this concerns uml_net and its permissions.

Which are them? It should be setuid root and executable...

However, since:

# perror 2
OS error code   2:  No such file or directory

Uml is saying it didn't find uml_net, or some of its libraries, not that there's a permission problem.

Possibly it's lying and printing the wrong code, dunno. But from current code:

arch/um/os-Linux/helper.c:helper_child

        execvp(argv[0], argv);
        errval = errno;
        printk("execvp of '%s' failed - errno = %d\n", argv[0], errno);

it seems not (that source file was somewhere else, guess in arch/um/kernel, until 2.6.14, but I think the content was the same).

On Fri, Feb 17, 2006 at 01:07:50PM +0100, Blaisorblade wrote:
Hi Paolo,

Quoted 6 lines

Quoted 3 lines

If you use the 2.4.x uml kernel the UML image work fine with network, but if you use an available 2.6.x uml image or a 2.6.x image of mine the uml bootstrap phase hangs with the following error message:

Indeed on the same machine and with same config? It's strange, I never saw

yes, first I tried my own configuration, then I downloaded a prebuild uml kernel from http://uml.nagafix.co.uk/ and I tried with this one. Same error again.
Then I extracted the configuration from that image and I rebuild with that config, same error for the same problem.

ste@etinarcadiaego{~}$ ll /usr/lib/uml/uml_net
-rwsr-x---  1 root uml-net 19836 2004-04-15 03:03 /usr/lib/uml/uml_net

Another info: I used either the kernel.org sources and the debian's linux-source(s).

Quoted 8 lines

yes, first I tried my own configuration, then I downloaded a prebuild uml kernel from http://uml.nagafix.co.uk/ and I tried with this one. Same error again.
Then I extracted the configuration from that image and I rebuild with that config, same error for the same problem.

ste@etinarcadiaego{~}$ ll /usr/lib/uml/uml_net
-rwsr-x---  1 root uml-net 19836 2004-04-15 03:03 /usr/lib/uml/uml_net

Ok, thanks for this informative info. This is the solution.

In short, echo $PATH | grep /usr/lib/uml, and if needed man 3 execvp, could enlighten you... or even the fact that I do:

# ls -l /usr/bin/uml_net
-rws--x--x  1 root root 22856 16 feb 18:49 /usr/bin/uml_net

On Fri, Feb 17, 2006 at 03:05:28PM +0100, Blaisorblade wrote:
Ciao Paolo,

Quoted 2 lines

# ls -l /usr/bin/uml_net
-rws--x--x  1 root root 22856 16 feb 18:49 /usr/bin/uml_net

damn, it drived me crazy!!!

now it works, and I am going to provide the
solution in debian.

What it sounds strange is that:

stex@landini{~}$ ll /usr/bin/uml*

(quoted diff) +0 -3

-rwxr-xr-x 1 root root 10296 2006-02-17 03:39 /usr/bin/uml_mconsole
-rwxr-xr-x 1 root root  9784 2006-02-17 03:39 /usr/bin/uml_mkcow
-rwxr-xr-x 1 root root 12356 2006-02-17 03:39 /usr/bin/uml_moo

lrwxrwxrwx 1 root root 20 2006-02-17 12:13 /usr/bin/uml_net ->
/usr/lib/uml/uml_net

(quoted diff) +0 -2

-rwxr-xr-x 1 root root 15624 2006-02-17 03:39 /usr/bin/uml_switch
-rwxr-xr-x 1 root root  4168 2006-02-17 03:39 /usr/bin/uml_watchdog

(I temporarily linked uml_net from the current position) all the other uml_* files resides on /usr/bin. I am going to fix this.

Thanks Paolo for your usual good suggestions :))

For the future packaging: I do believe that Debian's defaults have been actually planned while uml_utilities haven't, so I like the idea of switching to Debian paths as defaults, and possibly using the current ones as fallbacks.

Quoted 4 lines · Blaisorblade

For the future packaging: I do believe that Debian's defaults have been actually planned while uml_utilities haven't, so I like the idea of switching to Debian paths as defaults, and possibly using the current ones as fallbacks.

Yup, as long as they are not too Debian-specific.

Quoted 6 lines · Jeff Dike

Quoted 4 lines · Blaisorblade

For the future packaging: I do believe that Debian's defaults have been actually planned while uml_utilities haven't, so I like the idea of switching to Debian paths as defaults, and possibly using the current ones as fallbacks.

Quoted 1 line

Yup, as long as they are not too Debian-specific.

They tend to make more sense and adhere better to the
FHS. /var/run/uml-utilities requires support from the distro, but having uml_net in /usr/lib is a correct idea, for instance.

I'm confused, why would you have executables in a shared library directory instead of /usr/bin or some such? (These are runnable elf binaries, not shared libraries, correct?)

Quoted 9 lines · Jeff Dike

Quoted 7 lines · Blaisorblade

Quoted 4 lines

For the future packaging: I do believe that Debian's defaults have been actually planned while uml_utilities haven't, so I like the idea of switching to Debian paths as defaults, and possibly using the current ones as fallbacks.

Yup, as long as they are not too Debian-specific.

Quoted 3 lines

They tend to make more sense and adhere better to the
FHS. /var/run/uml-utilities requires support from the distro, but having uml_net in /usr/lib is a correct idea, for instance.

I'm confused, why would you have executables in a shared library directory instead of /usr/bin or some such? (These are runnable elf binaries, not shared libraries, correct?)

Quoted 7 lines · Blaisorblade

Quoted 5 lines · Jeff Dike

Quoted 4 lines · Blaisorblade

For the future packaging: I do believe that Debian's defaults have been actually planned while uml_utilities haven't, so I like the idea of switching to Debian paths as defaults, and possibly using the current ones as fallbacks.

Quoted 5 lines

Quoted 1 line

Yup, as long as they are not too Debian-specific.

They tend to make more sense and adhere better to the
FHS. /var/run/uml-utilities requires support from the distro, but having uml_net in /usr/lib is a correct idea, for instance.

I'm confused, why would you have executables in a shared library directory instead of /usr/bin or some such?

(These are runnable elf binaries, not
shared libraries, correct?)

Quoted 3 lines

Once discovered the issue and find the workaround [1], I am wondering why, if you moved uml_net from /usr/bin to /usr/lib/uml/, you left the other uml_* executable on the first dir.

This was to comply with the FHS:

http://www.pathname.com/fhs/pub/fhs-2.3.html

uml_net is not intended to be executed by a user, only invoked as an auxiliary program by UML itself.

I discussed this with Jeff at the time, and he agreed that it should move, but never moved it upstream apparently.

I patched the Debian UML sources to match.

Quoted 1 line

Is it worthy to move all of them to /usr/lib/uml/?

No, see above.

The same with uml_switch, isn't it?

On Tue, Feb 21, 2006 at 08:14:50AM -0800, Matt Zimmerman wrote:
Hi Matt,

Quoted 12 lines · Stefano Melchior

Quoted 3 lines

Once discovered the issue and find the workaround [1], I am wondering why, if you moved uml_net from /usr/bin to /usr/lib/uml/, you left the other uml_* executable on the first dir.

This was to comply with the FHS:

http://www.pathname.com/fhs/pub/fhs-2.3.html

uml_net is not intended to be executed by a user, only invoked as an auxiliary program by UML itself.

Quoted 8 lines

I discussed this with Jeff at the time, and he agreed that it should move, but never moved it upstream apparently.

I patched the Debian UML sources to match.

Quoted 1 line

Is it worthy to move all of them to /usr/lib/uml/?

No, see above.

Ok, I understood, thank you.
On the Makefile of uml_net source, and I read:

BIN_DIR ?= /usr/bin

If Jeff, Paolo and the UML devel team all agree, we can patch it and transform the line in:

BIN_DIR ?= /usr/lib/uml

The same with uml_switch, isn't it?