I am setting up my container creation pipeline and I need to be able to get the major AND minor version of the debian-slim build my container is built on.
I tried the following command:
docker run -it --rm -a stdout --entrypoint lsb_release MyContainer:1.0.0 -a
but that just returns:
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
No minor version listed.
I have also tried:
docker run -it --rm -a stdout --entrypoint cat MyContainer:1.0.0 "/etc/os-release"
but that only outputs:
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
again, no minor version.
Is there a way to get the minor version? Does the container OS even know its full version number?
In fact, in the old days on Debian9, you could use lsb_release -a to get the minor version as next:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.5 (stretch)
Release: 9.5
Codename: stretch
You may know, /usr/bin/lsb_release will finally call /usr/lib/python3/dist-packages/lsb_release.py, the realization diff for this script between debian9 & debian10 made the difference.
In debian9, it's next:
def get_distro_information():
lsbinfo = get_lsb_information()
# OS is only used inside guess_debian_release anyway
for key in ('ID', 'RELEASE', 'CODENAME', 'DESCRIPTION',):
if key not in lsbinfo:
distinfo = guess_debian_release()
distinfo.update(lsbinfo)
return distinfo
else:
return lsbinfo
get_lsb_release will fetch the contents of /etc/lsb-release, but there is no file in debian release, so it returns none. Then the procedure have to fallback to guess_debian_release which will fetch the contents from /etc/debian_version, so you get the minor version.
In debian10, it's next:
def get_distro_information():
lsbinfo = get_os_release()
# OS is only used inside guess_debian_release anyway
for key in ('ID', 'RELEASE', 'CODENAME', 'DESCRIPTION',):
if key not in lsbinfo:
distinfo = guess_debian_release()
distinfo.update(lsbinfo)
return distinfo
else:
return lsbinfo
get_os_release will fetch the contents of /usr/lib/os-release, the contens is next:
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
As it already get the version, so nolonger fallback to guess_debian_release, so you did not get the minor version. The advantage I guess is if not use guess_debian_release, it will use less IO operation, but in my opinion, really countless (Also maybe some hardcoding for guess).
Finally, as a workaround, on debian10, you could use next to get the same behavior as debian 9:
$ LSB_OS_RELEASE="" lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10.4 (buster)
Release: 10.4
Codename: buster
Should have looked a bit harder. (Found it right after posting)
Debian does it their own way by putting it in the custom, nonstandard, Debian specific file /etc/debian_version found only on Debian Linux:
docker run -it --rm -a stdout --entrypoint cat MyContainer:1.0.0 "/etc/debian_version"
<rant>Why do they not follow the standard of using lsb_release?</rant>
Related
Why can I not run lsb_release without -a parameter on ubuntu? Because When I run lsb_release command, I am taking message "No LSB modules are available".
Explanation: lsb_release command - prints you the linux distribution version on machine.
Solution: -v (version) is in default when no parameters are in. For watching linux distribution full information always use the -a flag or -r for release number.
examples:
$lsb_release -a
#output:
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.5 LTS
Release: 18.04
Codename: bionic
$lsb_release -r
#output:
Release: 18.04
Flags are:
-v, --version
Show the version of the LSB against which your current installation is compliant. The version is expressed as a colon separated list of LSB module descriptions.
-i, --id
Display the distributor's ID.
-d, --description
Display a description of the currently installed distribution.
-r, --release
Display the release number of the currently installed distribution.
-c, --codename
Display the code name of the currently installed distribution.
-a, --all
Display all of the above information.
-s, --short
Use the short output format for any information displayed. This format omits the leading header(s).
-h, --help
Show summary of options.
From the man page for lsb_release:
If no options are given, the -v option is assumed.
The -v option:
-v, --version
Show the version of the LSB against which your current installa‐
tion is compliant. The version is expressed as a colon sepa‐
rated list of LSB module descriptions.
If you don't have any lsb modules installed you'll get the message you describe. The -a switch shows all information available.
My OS is the following:
$ uname -v
1 SMP Debian 3.16.51-3 (2017-12-13)
Question: Are 3.16.51-3 and 3.16.51-3+deb8u1 considered the same? Or are they different?
Thanks.
Yes they are different.
the 3.16.51-3+deb8u1 is an newer/updated one. The version number in front of the "+" is the upstream-version and "+deb..." is the debian version like it's specified in
https://www.debian.org/doc/debian-policy/
No debian version means it's the initial debian version.
I work with a Linuxs server:
> cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.7 (Santiago)
(from wikipedia:
Red Hat Enterprise Linux 6 was forked from Fedora 12
6.7, also termed Update 7, 22 July 2015 (kernel 2.6.32-573)
6.8, also termed Update 8, 10 May 2016 (kernel 2.6.32-642))
The kernel
> uname -r
2.6.32-642.11.1.el6.x86_64
> uname -s
Linux
> uname -v
#1 SMP Tue Nov 15 22:57:18 EST 2016
> cat /proc/version
Linux version 2.6.32-642.11.1.el6.x86_64 (sandman#node3res7) (gcc version 4.4.7 20120313 (SuSE 4.4.7-17) (GCC) )
#1 SMP Tue Nov 15 22:57:18 EST 2016
gcc version
> gcc --version
gcc (GCC) 4.4.7 20120313 (SuSE 4.4.7-17)
when trying to install Tensdorflow, I have some issue with a missing library:
ImportError: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.19' not found (required by /opt/ccda/anaconda2/envs/tensorflow35/lib/python3.5/site-packages/tensorflow/python/_pywrap_tensorflow.so)
As you can see in my lib64/libstdc++.so.6 I don't have GLIBCXX_3.4.19
strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
....
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH
I look with the following command:
yum whatprovides */libstdc++.so.6
...
libstdc++-4.4.7-17.el6.x86_64 : GNU Standard C++ Library
Repo : installed
Matched from:
Filename : /usr/lib64/libstdc++.so.6
so my question where can I find the libstdc++-4.x.y-z.el6.x86_64 that contain GLIBCXX_3.4.19 and that I could install on my server RHEL 6 with my gcc version ?
I am a little bit confuse of which version to use from this page
https://www.rpmfind.net/linux/rpm2html/search.php?query=libstdc%2B%2B.so.6%28GLIBCXX_3.4.19%29&submit=Search+...&system=&arch=
I don't see a version for Fedora 12 or RHEL6
I need arch x86_64
I need I guess something gcc (GCC) 4.4.7
I guess I need 64bit
I the following a good macth ? I am quite confuse by the name and info:
libstdc++6-gcc48-32bit-4.8.5-21.1.x86_64.html The standard C++ shared library OpenSuSE leap updates for 42.1 libstdc++6-gcc48-32bit-4.8.5-21.1.x86_64.rpm
I don't have Internet access on the server so I need to download the file locally copy it on the server and do the intsallion.
Thanks for your help
Cheers
Fabien
ps: bonus question
SuSE 4.4.7-17 (GCC), I am confuse, I understood that Suse was a Linux distribution like Redhat!
I found a solution here:
https://www.linuxquestions.org/questions/red-hat-31/lib-libstdc-so-6-version-%60glibcxx_3-4-15'-not-found-4175419985/
Replacing libstdc++-so.6 with a later version that works in EL6:
Unpack libstdc++6_4.7.1-2_i386.deb
http://ftp.de.debian.org/debian/pool...7.1-2_i386.deb
with : ar -x libstdc++6_4.7.1-2_i386.deb && tar xvf data.tar.gz
Next : 1) su ; 2) cp libstdc++.so.6.0.17 /usr/lib/
3) cd /usr/lib/ && rm libstdc++.so.6
4) ln -s libstdc++.so.6.17 libstdc++.so.6
Reason for suggesting the Debian package :
It's a ( gcc ) libstdc++ version that's compiled with a glibc
old enough to be used in EL6 / CentOS 6.
Updated steps (because it seems the file has been moved):
curl -O http://ftp.de.debian.org/debian/pool/main/g/gcc-4.7/libstdc++6-4.7-dbg_4.7.2-5_i386.deb
tar -x libstdc++6-4.7-dbg_4.7.2-5_i386.deb && tar xvf data.tar.gz
mkdir backup
cp /usr/lib/libstdc++.so* backup/
cp ./usr/lib/i386-linux-gnu/debug/libstdc++.so.6.0.17 /usr/lib
ln -s libstdc++.so.6.0.17 libstdc++.so.6
Previous link is dead now as well, you can use this one
http://ftp.de.debian.org/debian/pool/main/g/gcc-4.8/libstdc++6-4.8-dbg_4.8.4-1_i386.deb
In previous comment from Serge, there's a cd missing
cd /usr/lib/
Or like in my case
cd /usr/lib64
For RHEL6, this is in the Software Collections.
I think (without citation) the devtoolsets are numbered according to what version gcc is included. devtoolset 8 will give you gcc 8. Much higher than 4.7 or 4.8.
subscription-manager repos --enable rhel-server-dts-6-rpms
yum install devtoolset-8-gcc-c++
source scl_source enable devtoolset-8
I am new to unix. I just want to check the flavour of my linux machine and tried the below commands
[root#ab-l13-i05 jetty-license]# uname -a
Linux ab-l13-i05 2.6.18-128.el5 #1 SMP Wed Jan 21 08:45:05 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
[root#ab-l13-i05 jetty-license]# lsb_release -a
LSB Version: :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: EnterpriseEnterpriseServer
Description: Enterprise Linux Enterprise Linux Server release 5.3 (Carthage)
Release: 5.3
Codename: Carthage
So from above the flavour of linux is 'Red Hat Enterprise Linux' or any other?
cat /etc/issue shows you the name of the OS installed.
Thanks & Regards,
Alok Thaker
I installed node.js(0.9.4) via nvm, which according to changelog has systemtap support.
I installed systemtap on my Fedora linux distro.
$ sudo yum install systemtap
I used this gist from Ben Noordhuis.
$ stap -l 'process("node")'
produces nothing.
$ sudo stap gc.stp -c 'node test.js'
semantic error: while resolving probe point: identifier 'process' at gc.stp:7:7
source: probe process("node").mark("gc__start")
^
semantic error: no match
semantic error: while resolving probe point: identifier 'process' at :12:7
source: probe process("node").mark("gc__done")
I have no experience at all with systemtap, but like to toy with it? What is possible with it? Can I see how much memory is consumed by code(http://stackoverflow.com/questions/13126808/whats-the-node-js-memory-breakdown)?
Update to answer comment.
$ readelf -n node
readelf: Error: 'node': No such file
$ which node
~/nvm/v0.9.4/bin/node
$ readelf -n ~/nvm/v0.9.4/bin/node
Notes at offset 0x0000021c with length 0x00000020:
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 2.6.32
Notes at offset 0x0000023c with length 0x00000024:
Owner Data size Description
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: 294da933883eaeaf7e848073dc3db6bff6762fb4
$ uname -a
[alfred#alfred81-AMILO-Pi-2515 gc-stap]$ uname -a
Linux alfred81-AMILO-Pi-2515.lan 3.6.3-1.fc17.x86_64 #1 SMP Mon Oct 22 15:32:35 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
$ stap -V
Systemtap translator/driver (version 2.0/0.154, rpm 2.0-1.fc17)
Copyright (C) 2005-2012 Red Hat, Inc. and others
This is free software; see the source for copying conditions.
enabled features: AVAHI LIBRPM LIBSQLITE3 NSS TR1_UNORDERED_MAP NLS
Your copy of node appears to be compiled without sys/sdt.h markers. If they were compiled in, readelf -n would show something like ...
stapsdt 0x00000040 NT_STAPSDT (SystemTap probe descriptors)
Provider: stap
Name: stap_system__spawn
Location: 0x000000000012e1b0, Base: 0x00000000001cb886, Semaphore: 0x0000000000000000
Arguments: -4#%ebx -4#%eax
Perhaps it was configured with --without-dtrace.