Problem with debian runit package / libowfat

Problem with debian runit package / libowfat

[Mike Bell]

runit on debian is linked against libowfat which doesn't understand
large device nums. EOVERFLOW. As a result a root on something with a
large num (like AoE devices on any shelf other than 0) won't be able to
start up runsvdir.

Perhaps a runit-dynamic package linked against glibc could be created?

Re: Problem with debian runit package / libowfat

[Gerrit Pape]

On Tue, Nov 21, 2006 at 08:08:58PM -0800, Mike Bell wrote:
> runit on debian is linked against libowfat which doesn't understand
> large device nums. EOVERFLOW. As a result a root on something with a
> large num (like AoE devices on any shelf other than 0) won't be able to
> start up runsvdir.

It's linked against the dietlibc, not libowfat.

> Perhaps a runit-dynamic package linked against glibc could be created?

Hmm, I would prefer to adapt the dietlibc.  Do you know what the glibc
does differently?, on what system/architecture are you having this
failure?, where does the EOVERFLOW happen?

Thanks, Gerrit.

Re: Problem with debian runit package / libowfat

[Mike Bell]

On Tue, Dec 05, 2006 at 10:52:03AM +0000, Gerrit Pape wrote:
> It's linked against the dietlibc, not libowfat.

Oops, think-o.

> Hmm, I would prefer to adapt the dietlibc.  Do you know what the glibc
> does differently?, on what system/architecture are you having this
> failure?, where does the EOVERFLOW happen?

Linux. Architecture doesn't matter.

The stat syscall can return a 32bit device number now that linux has
16bit majors and 16bit minors. Fixing it would involve expanding struct
stat by two bytes for every user, which is why I didn't report it on the
dietlibc list, I'm not sure it belongs in _diet_libc.

dietlibc returns EOVERFLOW whenever the major or minor is too big to fit
in an 8bit int.

Re: Problem with debian runit package / libowfat

[Paul Jarc]

Mike Bell <mike@mikebell.org> wrote:
> Fixing it would involve expanding struct stat by two bytes for every
> user, which is why I didn't report it on the dietlibc list, I'm not
> sure it belongs in _diet_libc.

The "diet" refers to the goal of small *code* size, not data.  I
wouldn't expect any objections on those grounds, and even the
transition should be relatively painless, since dietlibc is usually
linked statically.


paul