uname -p and uname -i reporting `unknown'

Bug #470550 reported by Matthias Klose
50
This bug affects 8 people
Affects Status Importance Assigned to Milestone
coreutils (Debian)
Fix Released
Unknown
coreutils (Ubuntu)
Fix Released
Low
Unassigned
Lucid
Won't Fix
Low
Unassigned
linux (Ubuntu)
Won't Fix
Undecided
Unassigned
Lucid
Won't Fix
Undecided
Unassigned

Bug Description

Binary package hint: coreutils

got bitten by build scripts using these; apparently on other distributions they report something else than `unknown'. these configure scripts make wrong assumptions:

       -p, --processor
              print the processor type or "unknown"

       -i, --hardware-platform
              print the hardware platform or "unknown"

Nevertheless for less surprises it would be useful to set these values to something else than "unknown".

Tags: kj-triage

Related branches

Matthias Klose (doko)
Changed in coreutils (Ubuntu Lucid):
milestone: none → lucid-alpha-1
status: New → Confirmed
Revision history for this message
C de-Avillez (hggdh2) wrote :

This has been discussed upstream; see:

* http://lists.gnu.org/archive/html/bug-coreutils/2005-09/msg00053.html for a more discussed thread, or
* http://lists.gnu.org/archive/html/bug-coreutils/2007-04/msg00089.html for a to-the-point one.

There are other hits, BTW.

Summary, as far as I can understand: coreutils will not provide 'uname -p -i' on Linux platforms since the 'sysinfo()' call does not support it, and /proc is er, considered too Linux-specific.

I would tend to mark this one INVALID, but I agree this should be available somewhere...

Revision history for this message
C de-Avillez (hggdh2) wrote :

Also see bug 111863.

Revision history for this message
C de-Avillez (hggdh2) wrote :

uh. Doko, you mention "apparently on other distributions". Do you have a reference to give me?

Revision history for this message
Matthias Klose (doko) wrote : Re: [Bug 470550] Re: uname -p and uname -i reporting `unknown'

On 03.11.2009 18:03, C de-Avillez wrote:
> uh. Doko, you mention "apparently on other distributions". Do you have a
> reference to give me?

asked somebody to check on Fedora, which apparently sets these.

Revision history for this message
Omer Akram (om26er) wrote :

uname -i in fedora 12 gave me i386.

Revision history for this message
C de-Avillez (hggdh2) wrote :

Thanks. I will download the sources for coreutils on Fedora 12, and see what goes on there.

Revision history for this message
C de-Avillez (hggdh2) wrote :

I cherry-picked the uname patch from Fedora 12; tested it locally, on Karmic, Lucid, and on coreutils GIT. All seem to work without a glitch.

I am publishing coreutils 7.4-2ubuntu2 on my PPA, and attaching the debdiff for Lucid here. Nevertheless, I would really appreciate some more tests.

Changed in coreutils (Ubuntu Lucid):
assignee: nobody → C de-Avillez (hggdh2)
status: Confirmed → In Progress
Revision history for this message
Omer Akram (om26er) wrote :

that ppa works fine uname -i and uname -p worked

C de-Avillez (hggdh2)
Changed in coreutils (Ubuntu Lucid):
status: In Progress → Confirmed
Revision history for this message
linflaas (linflaas) wrote :

Hi all,

Have the problem Ubuntu 9.10 :

ubuntu:/usr$ uname -i
unknown
ubuntu:/usr$

But i've found another uname installed :

ubuntu:/usr$ /usr/lib/klibc/bin/uname -i
i386
ubuntu:/usr$

This is working well :

ubuntu:/usr$ /usr/lib/klibc/bin/uname -a
Linux ubuntu 2.6.31-15-generic #50-Ubuntu SMP Tue Nov 10 14:54:29 UTC 2009 i686 i386
ubuntu:/usr$ /usr/lib/klibc/bin/uname -s
Linux
ubuntu:/usr$ /usr/lib/klibc/bin/uname -n
ubuntu
ubuntu:/usr$ /usr/lib/klibc/bin/uname -r
2.6.31-15-generic
ubuntu:/usr$ /usr/lib/klibc/bin/uname -v
#50-Ubuntu SMP Tue Nov 10 14:54:29 UTC 2009
ubuntu:/usr$ /usr/lib/klibc/bin/uname -m
i686
ubuntu:/usr$ /usr/lib/klibc/bin/uname -i
i386
ubuntu:/usr$

Can anyone explain me why two version of uname please ?
And how to use /usr/lib/klibc/bin/uname instead of /bin/uname

Txs all

Revision history for this message
Omer Akram (om26er) wrote :

i686 is your processor's and i386 is the kernel's

Revision history for this message
C de-Avillez (hggdh2) wrote :

@linflaas:
/usr/lib/klibc/bin is provided by the libklibc package, and is for use with initramfs. This is a work-in-progress, and does *not* replace coreutils.

I really do not think you should use it in lieu of the standard utilities in coreutils.

Revision history for this message
linflaas (linflaas) wrote :

OK txs a lot.

i then will wait for release ;)

Steve Langasek (vorlon)
Changed in coreutils (Ubuntu Lucid):
milestone: lucid-alpha-1 → none
Revision history for this message
C de-Avillez (hggdh2) wrote :

For the record, my PPA has a GIT coreutils package for Lucid with this patch in (https://edge.launchpad.net/~hggdh2/+archive/ppa).

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Milestoning: this breaks some 3rd party installer scripts.

Changed in coreutils (Ubuntu Lucid):
importance: Undecided → Low
milestone: none → ubuntu-10.04
Revision history for this message
C de-Avillez (hggdh2) wrote :

un-assigning myself, marking as Triaged, waiting for Sponsorship.

Changed in coreutils (Ubuntu Lucid):
assignee: C de-Avillez (hggdh2) → nobody
status: Confirmed → Triaged
Revision history for this message
Colin Watson (cjwatson) wrote :

We should have dealt with this before, but I'm afraid that it seems that at this point this is far too risky to do for Lucid. Won't-Fixing for Lucid, and we can reconsider this for Maverick.

Changed in coreutils (Ubuntu Lucid):
status: Triaged → Won't Fix
Changed in coreutils (Ubuntu):
milestone: ubuntu-10.04 → later
Changed in coreutils (Ubuntu Lucid):
milestone: ubuntu-10.04 → none
Revision history for this message
Sebastien Bacher (seb128) wrote :

Could somebody get that change in maverick now?

Revision history for this message
Artur Rona (ari-tczew) wrote :

I tested this patch and it works. Waiting for ACK from ubuntu-release team.

Revision history for this message
Scott Kitterman (kitterman) wrote :

No, I think once again it is too late for this. It should go in pre-feature freeze.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Now would be the time in the cycle to get such change in, Colin, Mathias do you think it makes sense? Could you sponsor it if that's the case?

Revision history for this message
Sebastien Bacher (seb128) wrote :

the merge request comment suggest upstream didn't ack the patch so unsubscribing sponsors

Revision history for this message
C de-Avillez (hggdh2) wrote :

Upstream coreutils will not ack the patch; this has been discussed over and over upstream, and their position is this is a service that should be provided by the kernel (via sysinfo() or uname(), probably).

As such we either carry this delta, or close this bug WONTFIX.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

so lets add 'linux' to this bug, if it's fixed in either that or coreutils depending on the outcome.

tags: added: kj-triage
Revision history for this message
C de-Avillez (hggdh2) wrote :

For the record, I have added the Debian bug about this -- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193170.

Changed in coreutils (Debian):
status: Unknown → Won't Fix
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package coreutils - 8.5-1ubuntu5

---------------
coreutils (8.5-1ubuntu5) natty; urgency=low

  * debian/patches/80_fedora_sysinfo.dpatch: make 'uname -i -p' return the
    real processor/hardware, instead of unknown. Patch cherry-picked from
    Fedora 12 (original: coreutils-4.5.3-sysinfo.patch, from the
    coreutils-7.6-5.src.rpm). LP: #470550.
 -- C de-Avillez <email address hidden> Tue, 10 Nov 2009 12:38:24 -0600

Changed in coreutils (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Steve Conklin (sconklin) wrote :

While this might be a valid request for a change to the kernel, it will have to be come from upstream in order for us to consider it. In any case, the change wouldn't meed our requirements to be applied as an SRU to Lucid:

https://wiki.ubuntu.com/KernelTeam/KernelUpdates

Set to wontfix

Changed in linux (Ubuntu):
status: New → Won't Fix
Changed in linux (Ubuntu Lucid):
status: New → Won't Fix
Changed in coreutils (Debian):
status: Won't Fix → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.