I have been given a server with OS installed. I want to check which Operating system is installed in it. I have used uname -a with ouput of
Linux ctl 2.6.32-573.3.1.el6.x86_64 #1 SMP Mon Aug 10 09:44:54 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux
Any suggestions ?
You could use the /etc/os-release file, which contains information on the os using the freedesktop spec.
Printing out just the OS name and version:
awk -F '=' '/PRETTY_NAME/ { print $2 }' /etc/os-release
Using os-release file available in Linux:
cat /etc/os-release
on many OS's, you can get the os via:
lsb_release -d
The el6 in the kernel version could indicate a RedHat (thus Fedora as well), Oracle, Centos, Scientific Linux. Potentially others as well.
At least on some of these systems (others as well) the distribution can be identified from the /etc/issue* files. For example:
> ls -la /etc/issue*
-rw-r--r-- 1 root root 57 Oct 22 2014 /etc/issue
-rw-r--r-- 1 root root 55 Oct 22 2014 /etc/issue.net
> cat /etc/issue
Welcome to openSUSE 13.2 "Harlequin" - Kernel \r (\l).
you can try this command to check all detail related to operating system version:
cat /etc/*elease
Related
I want to limit the CPU usage of the process through CGroup.After searching for some information on the Internet, I learned that it needed to be revised "cpu.cfs_period_us" and "cpu.cfs_quota_us",but now I can`t find these two files in cgroup.
My steps are as follows
The path "/sys/fs/cgroup" already exists in my Linux system, but there are no files in it.So I mount the cgroup/cpu/ file according to the reference standard steps:
cd /sys/fs/
mount -t tmpfs cgroup_root ./cgroup
mkdir cgroup/cpu
mount -t cgroup -ocpu cpu ./cgroup/cpu/
What puzzles me is that my ./cgroup/cpu/ directory doesn't have "cpu.cfs_period_us" and "cpu.cfs_quota_us"... What's the reason? Is it a kernel configuration problem?
I have these files in my ./cgroup/cpu path:
/sys/fs # ls ./cgroup/cpu/
cgroup.clone_children cpu.rt_period_us release_agent
cgroup.procs cpu.rt_runtime_us tasks
cgroup.sane_behavior haoel
cpu.notify_on_migrate notify_on_release
Other information
1)my linux system info
/ # cat /proc/version
Linux version 3.18.20 (gcc version 4.9.2 (GCC) ) #1 PREEMPT Tue Mar 9 03:52:45 CST 2021
/ # uname -a
Linux mdm9607-perf 3.18.20 #1 PREEMPT Tue Mar 9 03:52:45 CST 2021 armv7l GNU/Linux
2)Related kernel configuration
CONFIG_CGROUPS=y
CONFIG_CGROUP_DEBUG=y
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_DEVICE is not set
# CONFIG_CPUSETS is not set
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
# CONFIG_MEMCG is not set
# CONFIG_CGROUP_PERF is not set
CONFIG_CGROUP_SCHED=y
# CONFIG_FAIR_GROUP_SCHED is not set
CONFIG_RT_GROUP_SCHED=y
# CONFIG_BLK_CGROUP is not set
When I run
uname -r
I get 3.2.0-4-686-pae on my Debian7 and 4.4.26-gentoo on my Gentoo.
But what I can't find anywhere is what Linux kernel source versions do these distributions use. If I understand right all distributions take the kernel source code from here https://www.kernel.org. So how can I find out what Linux kernel versions from the site do use 4.4.26-gentoo or 3.2.0-4-686-pae, for example?
Try man uname and find -v for the kernel version used. ;)
So it is uname -v or uname -a if you just dont care about specifics and want to see it all. :p
$ uname -v
#1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)
$ uname -a
Linux Phobos 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux
Check out the difference between the uname -r part and the uname -v part in uname -a (the first version number in -a)
$ uname -r
3.16.0-4-amd64
you have some way to know linux kernel version :
good way
uname -r
bad way to see kernel version ( you should see version of vmlinu* initrd files if they have version number of kernel )
ls /boot | grep "vmlinu*"; ls /boot | grep "initrd*"
you can try this way to know all of kernel versions on your machine :
ls /lib/modules/
uname -r is the easiest way.
though there are utilities like screenfetch or neofetch that give you more information in a clear and pretty manner.
Just run screenfetch and it'll display details.
(screenfetch is usually pre-installed on most distros these days).
If it is not installed, just run sudo apt install screenfetch (on debian based distros like ubuntu) or sudo pacman -S screenfetch ( on Arch based distros.
If you are looking for original Linux kernel version that matches browse-able
https://elixir.bootlin.com/linux/vx.y.z/
or LINUX_KERNEL_CODE you check when developing kernel code, "uname" is not the right answer!
There are two methods (I use my Ubuntu 16.04 as example):
dmesg
dmesg | grep "Linux\ version"
[ 0.000000] Linux version 4.4.0-210-generic (buildd#lgw01-
amd64-009) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-
6ubuntu1~16.04.12) ) #242-Ubuntu SMP Fri Apr 16 09:57:56 UTC 2021
(Ubuntu 4.4.0-210.242-generic 4.4.262)
The original kernel version is 4.4.262! And 4.4.0-210-generic is Ubuntu's kernel number.
Install the kernel source use command like
sudo apt-get install linux-source
Look at the newly installed file ('uname -r' => 4.4.0-210-generic)
/lib/modules/4.4.0-210-generic/build/include/generated/uapi/linux/version.h
#define LINUX_VERSION_CODE 263423
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
That version code is 0x0404FF indicating 4.4.[>=255] (where FF is for when patch exceeds 255).
-------- interesting reading below--------
It is interesting to look at the file
/lib/modules/4.4.0-210-generic/build/include/generated/utsrelease.h
#define UTS_RELEASE "4.4.0-210-generic"
#define UTS_UBUNTU_RELEASE_ABI 210
Now we know where uname and /proc/version get their number.
On my Ubuntu 20.04 5.4.0-80-generic
dmesg | grep "Linux\ versin"
[ 0.000000] Linux version 5.4.0-80-generic (buildd#lcy01-
amd64-030) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04))
#90-Ubuntu SMP Fri Jul 9 22:49:44 UTC 2021
(Ubuntu 5.4.0-80.90-generic **5.4.124**)
and LINUX_KERNEL_CODE is
$ cat /lib/modules/5.4.0-80-generic/build/include/generated/uapi/linux/version.h
#define LINUX_VERSION_CODE 328828
where 328828 = 0x05047C, indicating 5.4.124.
This question already has answers here:
Executing 32 bit code under Ubundu 64 bit installation error- No such file or directory
(3 answers)
Closed 7 years ago.
I'm having a weird problem where I have an executable in a directory, but when I try to run it, bash says that it doesn't exist:
kiarashsadr#pandoras-box:~/Downloads/Tether/linux$ ls
adb run.sh
kiarashsadr#pandoras-box:~/Downloads/Tether/linux$ ls -l
total 1204
-rwxrwxr-x 1 kiarashsadr kiarashsadr 1226659 Mar 9 2013 adb
-rwxrwxr-x 1 kiarashsadr kiarashsadr 521 Oct 29 2012 run.sh
kiarashsadr#pandoras-box:~/Downloads/Tether/linux$ ./adb
bash: ./adb: No such file or directory
output from file:
kiarashsadr#pandoras-box:~/Downloads/Tether/linux$ file adb
adb: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped
wut??
You're trying to run a 32-bit executable on a 64-bit system. Bash doesn't differentiate between this case and "no such file or directory" case.
More about this topic: Executing 32 bit code under Ubundu 64 bit installation error- No such file or directory
More on how to run 32-bit executables on 64-bit systems: https://askubuntu.com/questions/454253/how-to-run-32-bit-app-in-ubuntu-64-bit
As stated by VOR73X, the reason in this case is that the file is a 32-bit executable on a 64-bit architecture. You can run it, but you need a compatibility layer to do so. If you have it:
mintaka:/home/lserni # file ansi
ansi: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.2.5, not stripped
mintaka:/home/lserni # uname -a
Linux mintaka 4.0.1-1-default #1 SMP Wed Apr 29 15:04:53 UTC 2015 (e3a374a) x86_64 x86_64 x86_64 GNU/Linux
mintaka:/home/lserni # ./ansi
Syntax: ansi [file|-]
...and otherwise you get 'no such file or directory'.
However, there might be other reasons to be unable to run a file that "seems" to be there (or even is).
Missing dynamic libraries would give a distinctive error (at least they do on my system, Linux OpenSuSE 13.2):
./test: error while loading shared libraries: libcap.so.2: cannot open shared object file: No such file or directory
Another possibility...
...is that the file is not named as you think it is. The file you asked for is really not there!
For example (using the same obsolete file as before)
mintaka:/home/lserni # mv ansi 'ansi '
mintaka:/home/lserni # ls -la ansi*
-rwxr-xr-x 1 root root 14268 Sep 17 23:29 ansi
The file seems to be there but its name now ends with a space, so as you would expect...
mintaka:/home/lserni # ./ansi
bash: ./ansi: No such file or directory
Of course if the file is called correctly, escaping the space...
mintaka:/home/lserni # ./ansi\
Syntax: ansi [file|-]
mintaka:/home/lserni #
Other tricks are possible (I did it to myself once by mistake and have seen some worm using this trick to hide from a casual 'ls'). For example UTF8 invisible characters.
Try
ls -la | hexdump -C
to verify that the name is indeed what it ought to be.
For linux why when providing stdin (input redirection) to logname it is not able to determine the user?
#> echo `logname`
<username>
#> echo `logname` < /dev/null
logname: no login name
#> echo `logname` < /dev/tty
logname: no login name
Moverover this does not seem to affect whoami.
#> echo `whoami`
<username>
#> echo `whoami` < /dev/null
<username>
Edit: Adding OS versions (tested it on multiple different Linux machines).
#> uname -a
Linux <machine1> 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
#> uname -a
Linux <machine2> 2.6.18-238.el5 #1 SMP Sun Dec 19 14:22:44 EST 2010 x86_64 x86_64 x86_64 GNU/Linux
#> uname -a
Linux <machine3> 3.0.13-0.27-default #1 SMP Wed Feb 15 13:33:49 UTC 2012 (d73692b) x86_64 x86_64 x86_64 GNU/Linux
On Unix/Linux systems, you can have multiple users logged in through different windows, ssh sessions etc. Each currently logged in user may or may not have a tty associated with the session. If there is a tty session allocated for a user, the association between tty and the user logged in on it is stored in the systems utmp file (the path may vary). logname wants to first see what tty you are on, then look up the associated record in the utmp file to see who you are. When you do logname < /dev/null, logname is disassociated from your tty, and so fails to find out which record it needs to lookup, which is why it reports "no login name".
When I run uname -a, I get:
Linux 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
and I understand that x86_64 is supposed to imply 64-bit kernel, but why does this number appear 3 times? What does each instance signify?
Uname has separate commands to print "machine, processor and hardware platform" -- all of these are all the same in your case. The following outputs, respectively, may make it clear:
~$ uname -m # print machine
x86_64
~$ uname -p # print processor
x86_64
~$ uname -i # print hw platform
x86_64
use uname -m command to display only name of the kernel.
in your case
uname -m
x86_64
means 64-bit
uname -a
will give you all details about your system. It includes machine hardware name, processor type & hardware platform too.
So,
x86_64 is machine name.
x86_64 is processor type.
x86_64 is hardware platform.
Use:
uname --help
to get more idea about its options.