uname -i and -p report "unknown"

Bug #111863 reported by Jeff Abbott
2
Affects Status Importance Assigned to Milestone
coreutils (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: coreutils

I've got several hosts running Feisty, and both "uname -i" and "uname -p" report "unknown." Some examples:

PowerMac G4 -- 933MHz PowerPC G4
--------------------------------
uname -i:
    unknown
uname -p:
    unknown
uname -m:
    ppc
uname -a:
   Linux chrysanthemum 2.6.20-15-powerpc #3 Sun Apr 15 06:45:49 UTC 2007 ppc GNU/Linux

Dell OptiPlex GX620 -- 3.4GHz Pentium 4
---------------------------------------
uname -i:
    unknown
uname -p:
    unknown
uname -m:
    x86_64
uname -a:
   Linux nightshade 2.6.20-15-generic #2 SMP Sun Apr 15 06:17:24 UTC 2007 x86_64 GNU/Linux

Pengiun Computing Relion 230 -- 2x 2.4GHz Pentium 4 Xeon
--------------------------------------------------------
uname -i:
    unknown
uname -p:
    unknown
uname -m:
    i686
uname -a:
   Linux dandelion 2.6.20-15-server #2 SMP Sun Apr 15 07:41:34 UTC 2007 i686 GNU/Linux

HP Compaq nw8440 Mobile Workstation -- 2.0GHz Core Duo T2500
------------------------------------------------------------
uname -i:
    unknown
uname -p:
    unknown
uname -m:
    i686
uname -a:
    Linux dahlia 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux

We've also got a Dell PowerEdge 1950 with a single 2.0GHz Xeon 5130 CPU running CentOS 5, which reports:

uname -i:
    x86_64
uname -p:
    x86_64
uname -m:
    x86_64
uname -a:
    Linux HOSTNAME_SCRUBBED 2.6.18-8.1.1.el5 #1 SMP Mon Apr 9 09:43:24 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux

I see behavior similar to the above CentOS 5 example on my i686 CentOS 4 machines.

Both CentOS 5 and Ubuntu Feisty have the same version of uname -- 5.97 -- so I'm not sure what's going on. Anything else I need to check?

Revision history for this message
Micah Cowan (micahcowan) wrote :

Thank you for your bug report.

This behavior is according to the documentation. Under the descriptions for both "-i" and "-p", it states, "Print `unknown' if the kernel does not make this information easily available, as is the case with Linux kernels."

Most of the values for options given to the uname command come from a call to uname(). The "-i" and "-p" options, though, are not defined in POSIX (and so aren't portable). Some systems, especially BSD, provide additional, separate information for these concepts of "hardware architecture" or "processor type", and print these values obtained from a special system call, either sysinfo() or sysctl(). Linux, however, does not offer the BSD-style sysinfo() (it has an entirely different system call named sysinfo()); and it does not offer a value for the HW_MODEL or HW_MACHINE_ARCH in sysctl().

So, these options are extensions, provided to take advantage of some more-or-less BSD-specific features. Rather than just give an error when these options are used on OSses that don't support them, as they could have done, they opted to have them print "unknown" instead.

The "-m" option, on the other hand, is extremely portable, and may be depended upon to give reliable results.

Changed in coreutils:
status: Unconfirmed → Rejected
Revision history for this message
Micah Cowan (micahcowan) wrote :
Revision history for this message
Jeff Abbott (fdivbug) wrote :

Michah,

Thank you very much for that informative reply -- that clarifies the Ubuntu uname situation immensely. I do wonder why RHEL/CentOS (and possibly other distros) behave differently, but this isn't an appropriate discussion venue for that. I would question why Ubuntu doesn't follow suit, but your reasoning based on the information above is sound enough for me.

Thanks,
Jeff

Revision history for this message
Micah Cowan (micahcowan) wrote :

You're welcome. And I meant to address the CentOS thing: my guess (unverified) would be that in the absence of information from the methods I described, they just copy the value of -m. As to whether or not Ubuntu should do such a thing is another matter, and I'm not prepared (nor authorized :) ) to categorically say "no". But, it's something that would require more discussion. If you'd like, you might start a discussion at ubuntu-devel-discuss <https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss>.

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.