I have CentOS 6.3 installed.
cat /etc/redhat-release
CentOS release 6.3 (Final)
uname -mrs
Linux 2.6.32-279.el6.x86_64 x86_64
I am following the steps outlined in the following links to fetch and build the kernel (to enable certain features):
http://wiki.centos.org/HowTos/I_need_the_Kernel_Source
http://wiki.centos.org/HowTos/Custom_Kernel
In the CentOS 6.3 vault (http://vault.centos.org/6.3/updates/Source/SPackages/), following kernel source rpms are listed:
kernel-2.6.32-279.1.1.el6.src.rpm
kernel-2.6.32-279.2.1.el6.src.rpm
kernel-2.6.32-279.5.1.el6.src.rpm
kernel-2.6.32-279.5.2.el6.src.rpm
kernel-2.6.32-279.9.1.el6.src.rpm
kernel-2.6.32-279.11.1.el6.src.rpm
kernel-2.6.32-279.14.1.el6.src.rpm
kernel-2.6.32-279.19.1.el6.src.rpm
kernel-2.6.32-279.22.1.el6.src.rpm
I am trying to find out, which of the above source rpm corresponds to kernel version 2.6.32-279.el6 (output of "uname -r" which does not contain the additional 2 digits of the version number in the list above). Any help would be very appreciated.
Thank you,
Ahmed.
After much wrecking my head and tons of googling (which did not shed any light), I finally figured out the answer to my question. I will state my answer using CentOS 6.3 as a example, same logic applies to CentOS 6.4. If one has a fresh install of CentOS 6.3, look for the kernel source file at the following site:
http://vault.centos.org/6.3/os/Source/SPackages/
The above site contains only one kernel source rpm (for kernel with the version number that does not contain the two additional digits in the version number). Not confusion there.
However, if one has applied a patch to the stock 6.3 release, then depending on the patch level, the kernel version is extended (with the two digits) for which the corresponding kernel source is available at the following site:
http://vault.centos.org/6.3/updates/Source/SPackages/
--Ahmed.
Related
I am in need of working with a specific version of the text editor Lyx, the 1.3.3, on a CentOS 7 environment. I found the .rpm package and some sort of source code, but as it's a very old software, many library are obsolete and cannot be found when installing from the rpm file and for some reasons no c++ compiler I used seems to be good to compile the source code.
Now my question: I do have a CentOS virtual machine with this specific version of Lyx installed properly. Is there a way to "clone" or somehow copy it into my CentOS main partition? Or, if this is too barbaric, how can I extract/install from the VM CentOS the libraries I need?
I apologize if my question doesn't make much sense, I am by no means an expert of Linux distros and I might have some misconceptions brought over from Windows.
I'm attempting to build an image with the phytec bsp 18.2 from here: https://wiki.phytec.com/productinfo/phycore-i-mx7/bsp-yocto-fsl-imx7/
I require a newer version of systemd (> 234) and so am substituting the systemd recipe for version 234 from rocko, found here: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/systemd?h=rocko by putting this in a custom layer. However, during the do_rootfs step, I receive an error that "No package provides libsystemd.so.0(LIBSYSTEMD_219). I've tried a work-around recommended here: Smart can't install...no package provides shared object file and it didn't solve the issue. I've tried echoing libsystemd.so.0, LIBSYSTEMD_219, and libsystemd.so.0(LIBSYSTEMD_219) to both ${rootfs}/etc/rpm/sysinfo/Providename and ${rootfs}/var/lib/rpm/Providename and had no luck. Does anyone have an idea on how to fix this? I'd appreciate any help that could be offered, and please let me know if I can offer any more information.
I don't know about the yocto wrapper, etc, but in standard RPM-land, this error:
Computing transaction...error: Can't install python3-systemd-234-r0.0#cortexa7hf_neon: no package provides libsystemd.so.0(LIBSYSTEMD_219)
means that there is a .so or executable in the RPM named python3-systemd-234-r0.0 that was compiled with a specific version of libsystemd.so.0 that had the flag LIBSYSTEMD_219. That flag is the "ELF Symbol Versioning" and it's seen most with GLIBC_XX when you try to install an RPM that's too new for a target system (e.g. CentOS 7 RPM on CentOS 6).
The systemd on your target machine is too old, so it only defines the versions it is compatible with, e.g. libsystemd.so.0(LIBSYSTEMD_210) or similar.
What you need to do is build your python3-systemd-234-r0.0 on a machine with the same version of systemd as the target (or cross-compile appropriately), or create a systemd RPM that includes the functionality you're attempting.
So you need to figure out how to apply one of these solutions to your build system; sorry I don't know enough about yocto to help there.
I'm trying to use VSCode Remote extension to connect to a remote host that runs on RHEL/CentOS 6, but it fails to connect since CentOS 6 ships with GLIBC 2.12 and GLIBCXX 3.4.1. As mentioned in this post, in order to get the extension to work, the workaround is to install GLIBC>=2.17 and GLIBCXX>=3.4.18.
Unfortunately, I don't have sudo access for the server, so I won't be able to update these libraries using the bash script provided in the link. Also, in this SO post, the author says not to update the system GLIBC since it can break down system applications. That being said, I've tried something different -- I extracted those rpm packages, as described in this blog, inside my home folder. I've then updated the env variables PATH and LD_LIBRARY_PATH in ~/.bash_profile to point to these new locations. But the node binary (in VS Code Remote) still can't find these libraries.
Is there a way to let the node binary know where to look for these libraries? More precisely, can someone explain how I can make this extension work without sudo access?
I've got it to work by installing gcc and glibc using Linuxbrew. See this post for more details: https://github.com/microsoft/vscode-remote-release/issues/103#issuecomment-546551293.
Couple of things to take note of:
Node binary versions in VS Code Server may vary between commits. In the GitHub comment above, the author uses node#10 -- you may replace it with node#12; everything would still work.
Make sure glibc and gcc are properly installed using linuxbrew. This step is key.
I'm an unexperienced linux and rtems user trying to build and configure rtems 4.11 environment on a Linux Mint host. I want this environment to compile a RTEMS application for an ERC32 chipset. I'm following the instructions given by the 4.11 version of the RTEMS Source Builder Manual. I've done the suggested steps but when it comes to the building command:
../source-builder/sb-set-builder --log=l-sparc.txt \ <1>
--prefix=$HOME/development/rtems/4.11 \ <2>
4.11/rtems-sparc
it fails and returns:
"Rtems Source Builder - Set Builder, 5 (35c533f545c8) Build set:
4.11/rtems-sparc error: no build set file found: 4.11/rtems-sparc.bset Build FAILED"
I used the command:
../source-builder/sb-set-builder --list-bset
in the list appears:
5/rtems-sparc.bset 6/rtems-sparc.b
set
So I found another question related to this:
no build set file found 4.11/rtems-sparc on rtems (VB)
The answer says to use the following command:
../source-builder/sb-set-builder \
--log=1-sparc.txt \
--prefix=${HOME}/rtems-4.11-work/tools 5/rtems-sparc
note that the 4.11 was replaced by 5. I used this command and the build
worked, however all executables now are like "sparc-rtems5-something".
I tried to compile a hello_world.c example with "sparc-rtems5-gcc" but it
is missing rtems.h
I thought that after the building steps everything including dependencies
would be in their proper directories and the compiler would recognize it.
Also, I've searched for the rtems.h file and I haven't found it in any part of
the system.
After all the history, I have some questions:
1) Is it good or technically appropriate to replace 4.11 by 5 in that
step ? Given that a supposedly I have a 4.11 environment.
2) What is that 5 and 6 directories with each one a sparc bset ?
Why two sparc bsets ?
3) Have been the 4.11 git directories changed over years ? Even
though it is old.
4) Could someone explain how to build properly the rtems 4.11 system
or at least recommend some guide?
It is worth noting that I found the documentation too confusing for a beginner. There are three different explanations of the environment, two in the user guide (quick start and installation sections) and one in the Source Builder docs. Also they differ in instructions. So I don't know which one or which part of each one to follow.
My uname -a command output:
Linux michel-COM 4.15.0-45-generic #48~16.04.1-Ubuntu SMP Tue Jan 29
18:03:48 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Short answer first: If you want to build a RTEMS 4.11 toolchain, you have to check out the 4.11 branch of the source builder. Try git checkout -t origin/4.11 in the rtems source builder directory. After that, a ../source-builder/sb-set-builder --list-bsets should list the 4.11/rtems-sparc.bset.
Now for the four questions:
1) Is it good or technically appropriate to replace 4.11 by 5 in that step ? Given that a supposedly I have a 4.11 environment.
If you want a 4.11 toolchain, you should not replace 4.11 by 5. Instead use the 4.11 release branches.
2) What is that 5 and 6 directories with each one a sparc bset ?
Why two sparc bsets ?
The current development version of RTEMS is 5. I would recommend to use RTEMS 5 for most new developments. In general the development version works quite stable and most active projects that I know of use a snapshot of that version. It's also the one with the best community support.
6 is a experimental version of the toolchain only. While 5 uses gcc releases (most of the time), 6 is updated automatically to snapshots. See https://lists.rtems.org/pipermail/devel/2018-December/023954.html for details how that one was created.
3) Have been the 4.11 git directories changed over years ? Even though it is old.
4.11 has been moved to branches.
4) Could someone explain how to build properly the rtems 4.11 system or at least recommend some guide?
You should be able to follow the documentation with the difference, that you have to use the 4.11 branches of all repositories.
It is worth noting that I found the documentation too confusing for a beginner. There are three different explanations of the environment, two in the user guide (quick start and installation sections) and one in the Source Builder docs. Also they differ in instructions. So I don't know which one or which part of each one to follow.
I have to be honest: I haven't started my RTEMS work with the documentation. So I'm not really sure about it's quality. I know that at least some of the points have been addressed in the current (version 5) documentation. For example, the source builder manual has been eliminated.
Trying to install swift on my Ubuntu 14.04.3 server. Followed the guide on Swift.org.
download the install package
fetched the gpg keys
verified the .sig file
extracted the file and added the usr/bin subdir to my PATH
However when I try running swift I get "No such file or directory"
Swift seems to be found:
icanzilb#underplot:~/public$ which swift
/home/icanzilb/swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a-ubuntu14.04/usr/bin/swift
Path is correct:
icanzilb#underplot:~/swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a-ubuntu14.04/usr/bin$ echo $PATH
/home/icanzilb/swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a-ubuntu14.04/usr/bin:...
But can't run it:
icanzilb#underplot:~/swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a-ubuntu14.04/usr/bin$ swift
-bash: /home/icanzilb/swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a-ubuntu14.04/usr/bin/swift: No such file or directory
=====
Update 1: I tried the development and stable builds of Swift from swift.org and the .sig checks out but still getting the same error.
Both the swift executable and my Ubuntu are 64 bit.
It really looks like this is a problem of an architecture mismatch, as indicated by one of the commenters, or a corrupted download. The swift executable is in the path and is picked up by which. Judging from the name of the directory where it is located, it is indeed for Ubuntu 14.04. I would try the following:
file `which swift`
This should tell you it is an ELF 64-bit executable, dynamically linked, etc. If that is not the case, you have a corrupted binary somehow.
Then do
uname -a
which should identify your system as Ubuntu 14, x86_64 among other things. If that is the case, you probably have a corrupted binary. Unpack the downloaded package again and retry. If your system is not x86_64, then you are on a wrong architecture.
Update 2/4/2016:
Based on the additional info you provided about the binary and the architecture, I tend to believe this is a platform mismatch. The output of uname doesn't show it is an Ubuntu box. Besides, the Linux kernel is 4.4.0, and the binary is for 2.6.24. I can successfully run the same binary on an Ubuntu 14.04 installation with a 3.19.0 kernel. The kernel version difference is not necessarily a problem in itself, but an indicator that the platform may not be a standard Ubuntu 14.04 install.
As another check, could you please do cat /etc/os-release and cat /etc/lsb-release? Those files should indicate if the platform is indeed Ubuntu. If it is, then I'm wondering how you ended up with this late kernel version. It is possible some other components of the OS are also too recent and incompatible with the Swift binary. This may be some strange custom Linode image... If you have a machine you can use, virtual or physical, try downloading and installing a standard Ubuntu 14.04.