CentOS Version Command and Update CentOS to New Version

View the CentOS Version and Update with Shell Commands

CentOS is a popular Linux Operating System for enterprise computing, web servers and Virtual Private Servers.

In this article:

  • View CentOS version
  • Check if CentOS is 64-bit or 32-bit
  • View the Centos server Name
  • View CentOS kernel version
  • View list of available CentOS updates
  • Updating CentOS
  • Rebooting CentOS
  • Listing CentOS installed packages

In these examples root is the logged in user, in practice a different superuser will normally be used when maintaining a server. These commands are executed in the shell.

View CentOS Version

When CentOS boots the version is briefly displayed on a boot screen and may be configured to show on the shell login but will probably show the kernel version:

Centos 
Kernel 2.6.32-431.el6.i686 on an i686

servername login:

Once logged in at the CentOS shell prompt find the CentOS version using:

[root@servername ~]# cat /etc/*release
CentOS release 6.5 (Final)

or

[root@servername ~]# cat /etc/issue
CentOS release 6.5 (Final)

or

[root@servername ~]# cat /etc/redhat-release
CentOS release 6.5 (Final)

Check if CentOS is 64-bit or 32-bit

To check if CentOS is 64-bit or 32-bit use the uname command with the -p option (p for processor):

[root@servername ~]# uname -p
x86_64

The 64-bit CentOS will display x86_64 and 32-bit will display i686.

Display the CentOS Server Name (Host Name)

Use hostname to display the systems name:

[root@servername ~]# hostname
servername.server

Display the CentOS Kernel Version

Use uname to see the kernel version:

[root@servername ~]# uname -r -v
2.6.32-431.el6.i686 #1 SMP Fri Nov 22 00:26:36 UTC 2013

List Available CentOS Updates

List available updates using yum, here piped (using |) to less to view one screen at a time using the space bar. Use q to quit the listing:

[root@servername ~]# yum list updates | less

Update CentOS

Update CentOS using yum, package downloads may need to be confirmed:

[root@servername ~]# yum update

(Note: After confirming the update packages will download, extract and install. If this fails you may see messages such as “Trying other mirrors”“Error Downloading Packages” and “[Errno 256]”. Use the command “yum clean metadata”  and try “yum update” again. If it still reports errors use the command “yum clean all” and try again.)

Rebooting CentOS

Restart CentOS:

[root@servername ~]# reboot

or

[root@servername ~]# shutdown -r now

One logged back in use the commands above to check the updated versions:

[root@servername ~]# uname -r -v
2.6.32-504.3.3.el6.i686 #1 SMP Tue Dec 16 22:55:44 UTC 2014

[root@servername ~]# cat /etc/issue
CentOS release 6.6 (Final)

List CentOS Installed Packages

List installed packages using yum, piped to less to view a page at a time (to quit):

[root@servername ~]# yum list installed|less

Further Information

For more information on CentOS see their Wiki and the CentOS web site at centos.org.

See also:

Supporting Multiple API Versions in Android

Writing Code for Different API Levels

How do you handle changes in the Android Application Programming Interface (API) in code? By placing code that uses changed APIs into a separate class, then wrapping the use of that class in a test. The test is comparing the device’s API level against the code’s target API level. The Build class provides the relevant version numbers to use in the test. However, there are other considerations in supporting multiple API versions. These factors are explored in this article.

Android Robot Logo in the Supporting Multiple API Versions ArticleNew versions of Android provide new classes, additions to existing classes and deprecated classes and methods. (Deprecated classes and methods are those that are no longer required and will be removed in future releases.)  These changes are due to the Android platform continuously evolving to take advantage of new hardware, new ideas and to improve performance.

Reference Documentation API Level Filter

The Android Reference documentation has details on all the classes in all the APIs. Each part of a class has a label to denote in which API level it first appeared. The API documentation can apply a filter based on API level to grey out the classes and parts of classes that were not available prior to a give API version.

Supporting Multiple API Versions in Android

The Android API Differences Report

To see an overview of the changes between an Android API level and the previous API release view the Android API Differences Report. The report is viewed online at the Android Developers web site. The address is http://developer.android.com/sdk/api_diff/X/changes.html where is the API level to examine the differences from the previous level. For example if X is 9 then the differences report show the changes from API level 8 (Froyo) to API level 9 (Gingerbread). A link to each differences report is in the post Android Versions Numbering and API Levels.

Reading the Android Devices API Version

The API version used by an Android device is read from the static Build class in the android.os package. The Build.VERSION.SDK_INT returns the API level. The various API levels are defined in Build.VERSION_CODES.

For example here is some code to test for API level 9 (the first Android Gingerbread release):

The App running this code must have the minSdkVersion attribute in the manifest (AndroidManifest.xml) set to 4 (Donut) or higher. Prior to API level 4 SDK_INT was not available, it was Build.VERSION.SDK, a string. There are very few devices around early than API level 4 so setting the minSdkVersion to 4 or later should not be an issue, however, a workaround is discussed later.

Detect Other Android API Levels

The above code is easily extended to detected other API levels. So to detect API level 8, Froyo, the code becomes: Continue reading