Bug 480105

Summary: "uname -p" print the processor type as "unknown" during vnc install
Product: Red Hat Enterprise Linux 5 Reporter: Yolkfull Chow <yzhou>
Component: busyboxAssignee: Ivana Varekova <varekova>
Status: CLOSED ERRATA QA Contact: BaseOS QE <qe-baseos-auto>
Severity: medium Docs Contact:
Priority: low    
Version: 5.3CC: dvlasenk, kvolny, rvokal
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 534081 (view as bug list) Environment:
Last Closed: 2009-09-02 09:09:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 534081    
Attachments:
Description Flags
Patch to add -o and -i support
none
Patch to add -o and -i support (fixed) none

Description Yolkfull Chow 2009-01-15 03:04:28 UTC 
Description of problem:
Use http+vnc install, press "Enter" to enter into shell after vncserver is launched, type "uname -p" to print processor type whereas get output "unknown". 

Version-Release number of selected component (if applicable):
Snapshot 20090106.0

How reproducible:
Everytime

Steps to Reproduce:
1. use http+vnc to install
2. press "Enter" after vncserver is launched
3. type "uname -p"
  
Actual results:
get output of "unknown" when issue 'uname -p'

Expected results:
It should return right processor type, x86_64 or i686

Additional info:
In 'uname --help', the interpretation for argument '-p' is: print the processor type, doesn't say it may return 'unknown'.
Comment 1 Yolkfull Chow 2009-01-15 03:29:21 UTC 
Problem could be reproduced in 5.2 as well.
Comment 2 Denys Vlasenko 2009-01-19 16:01:18 UTC 
Even though uname() system call does not have this information, Fedora's uname reports -p and -i:

   -m, --machine
   -p, --processor
   -i, --hardware-platform

# uname -mpi
i686 i686 i386

# uname -mpi
x86_64 x86_64 x86_64

but closer look reveals that it is Fedora-specific addition. Upstream coreutils-7.0 does not do that:

# pwd
/root/srcdevel/bbox/tmp/coreutils-7.0/src
# ./uname -mpi
x86_64 unknown unknown


I think it makes sense to stop printing "unknown", as it is against the rules
("-a, --all print all information, in the following order, *except omit -p and -i if unknown*"), and start printing "GNU/Linux" as OS name.

This will make busybox's uname fully match coreutils-7.0:


# ./busybox_old uname -a
Linux localhost.localdomain 2.6.29-0.28.rc1.fc11.x86_64 #1 SMP Sun Jan 11 20:52:37 EST 2009 x86_64 unknown

# ./busybox uname -a
Linux localhost.localdomain 2.6.29-0.28.rc1.fc11.x86_64 #1 SMP Sun Jan 11 20:52:37 EST 2009 x86_64 GNU/Linux

# ./uname -a
Linux localhost.localdomain 2.6.29-0.28.rc1.fc11.x86_64 #1 SMP Sun Jan 11 20:52:37 EST 2009 x86_64 GNU/Linux

This still won't match Fedora's uname:

# uname -a
Linux localhost.localdomain 2.6.29-0.28.rc1.fc11.x86_64 #1 SMP Sun Jan 11 20:52:37 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
Comment 3 Denys Vlasenko 2009-01-19 16:31:11 UTC 
Created attachment 329360 [details]
Patch to add -o and -i support

flip #if 0 to #if 1 in the patch to get "Fedora-compatible" behavior
Comment 4 Denys Vlasenko 2009-01-19 16:53:46 UTC 
Created attachment 329363 [details]
Patch to add -o and -i support (fixed)

Oops... need to widen option bit variable...
Comment 10 errata-xmlrpc 2009-09-02 09:09:29 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1249.html