Just synced up to latest Linux bpf-next repo (5.3.0) and trying to compile samples/bpf directory. The Linux kernel compiles fine. This is on a Linux host and the default config was taken from /boot/config-* and changed to define XDP param. I do have root access to the build machine.
This is what I get and no .o's are seen in the dir.
sudo make samples/bpf/
CALL scripts/checksyscalls.sh
CALL scripts/atomic/check-atomics.sh
DESCEND objtool
I have a checkout of the repo (5.2.0-rc*) in a ubuntu VM and the build succeeds fine there.
What am I missing? Any pointers appreciated.
Thanks!
Related
I followed the steps on https://redislabs.com/blog/redis-on-windows-10/ and have installed Ubuntu 18.04 and am successfully running Redis v4.09 on Windows. But, when following the steps on https://oss.redislabs.com/redisearch/Quick_Start/, I have some issues.
In the download and running binaries section, I don't understand what I'm supposed to replace /path/to/module/src/redisearch.so with. I've downloaded RediSearch for Ubuntu 18.04 and I've moved the files to a folder named RediSearch within my Downloads folder. Could someone help me with the pathing considering I'm using Ubuntu on Windows? I've also tried it with Building and Running with Source section but that just runs into an error every time I run make:
*** No rule to make target 'build'. Stop.
How can I run the module with Redis?
With WSL, you have access to C: through /mnt/c/ from Linux.
So, if you really want to have redisearch on a folder in Downloads you need to use something like:
/mnt/c/Users/<yourUser>/Downloads/yourFolder/src/redisearch.so
However, you probably should use a folder within Linux instead. You can use wget to download from Linux.
So I am having some issues with vagrant. I had initially tried to report this as an issue on the vagrant github issue boards, but they kept closing the issues without responding to them. I guess they decided I wasn't worth their time, or they were just behaving unprofessionally. Anyway, Here is the problem: I use vagrant with virtualbox, and a new version of virtualbox was recently released that is, unfortunately, not compatible with the latest vagrant installation.
However, the people at hashicorp have already updated the source code so that it is compatible with the new version of virtualbox, but you have to build the vagrant executable from the source repo (instructions here). So I followed the instructions and vagrant is working just like it used to.....when the only command I need to run is vagrant up. I should also mention ahead of time that, in order to run the vagrant dev build, the current working directory needs to be the root of the source code repo and the dev build can only be run using the following command with ruby:
bundle exec vagrant
With that being said, I needed to update one of my custom boxes, so I built a vm in the updated version of virtualbox and ran the below command
bundle exec vagrant package --base go --vagrantfile ../../vagrant/vagrantfile
After an extended period of time, vagrant spat back out the following error
The executable 'bsdtar' Vagrant is trying to run was not found in the %PATH% variable. This is an `error. Please verify this software is installed and on the path.`
I should also note that I use a windows machine and that this error never occurred when using the installed version of vagrant. At this point, I had posted the issue on github to get some input from the devs, but they (very unprofessionally) decided to ignore my requests for help and close the issues without providing any response. I used the GNUwin32 project to make numerous unix commands available to my Windows environment and added the folder to my PATH environment variable. I then run the same command again to create my new box and it works!! So then I upload it to the vagrant cloud and attempt to update the vagrant box that is stored on my system by running the following command:
bundle exec vagrant box update
Then, after waiting for a while, vagrant then spat this error out at me:
The box failed to unpackage properly. Please verify that the box
file you're trying to add is not corrupted and that enough disk space
is available and then try again.
The output from attempting to unpackage (if any):
C:\gnuwin32\bin/bsdtar.EXE: invalid option -- s
Usage:
List: bsdtar.EXE -tf <archive-filename>
Extract: bsdtar.EXE -xf <archive-filename>
Create: bsdtar.EXE -cf <archive-filename> [filenames...]
Help: bsdtar.EXE --help
Another error, and still involving this bsdtar tool. It does not appear that anyone else is reporting the issue I am running into because I think they are just waiting for hashicorp to release the new official installation, but, just to give you a look into their priorities, the version of virtualbox that was released which no longer worked with vagrant was released back on December 10. It has been over a month since and there is still no updated release.
So, I am hoping that someone out there might be able to find out why I keep running into these errors when trying to use vagrant's dev build and provide a solution. If not, then maybe if someone else is able to reproduce the issue and report it to hashicorp, maybe they will listen to someone else.
If you are on Ubuntu 20.04 then bsdtar was removed. Try to install libarchive-tools package.
$ sudo apt-get install libarchive-tools
I figured it out. My original hypothesis was correct: since vagrant is a tool that was built primarily to be run on linux machines, then vagrant runs in windows, the installation includes a mingw environment with all of the dependencies vagrant needs to function and which the installed vagrant executable imports into the console session when run. This why the dev build kept failing: because it was not importing this mingw environment. So, in order to fix the issue, I first cloned the vagrant source code repo from github and followed the instructions I linked to above to build the executable from the source repo. I then copied all of the files in the source repo into the following folder:
<hashicorp install folder root>\Vagrant\embedded\gems\2.2.6\gems\vagrant-<version num>
So, for me, the destination directory is C:\HashiCorp\Vagrant\embedded\gems\2.2.6\gems\vagrant-2.2.6
This directory is identical to the source code repo, and copying the source code repo to the above folder replaces the installation version of vagrant with the dev build. After I did this, running the vagrant commands which had failed previously normally (as in, without using ruby or bundle) worked. I hope this helps someone else out there who Hashicorp has decided is not worth their time.
I have inherited a cheffed OSX machine running chef-client 11.14.6. I am trying to lay my hands on the installer for 11.14.6, but it seems that Chef have pulled it from the downloads site ( https://downloads.chef.io/chef-client/mac/ ).
Does anyone know anything about this, or know where I can get "archived" version?
Much appreciated.
I don't see any copies in any repos so it's probably lost to the mists of time by now. You should be able to build a new one using this commit from omnibus-chef https://github.com/chef/omnibus-chef/tree/6d5001c588edacc98f6045e22c70195200111660
Yes. From my research, and the research of others. It seems as if it has been removed.
However, we (I can't take the credit - it was one of my colleagues :) ) managed to get it working. We had another machine with the correct version on it, so we grabbed it from there and zipped it up (using root as the base, and grabbing /opt/chef).
Once tarball (e.g. opt.chef-11.14.6.tar.gz) is transferred to new machine, these were the steps used:
install chef-client v11.10.4 using:
(echo "version=11.10.4"; curl -L https://www.opscode.com/chef/install.sh) | sudo bash
verify your chef-client version is currently reported as 11.10.4 with "chef-client -v"
extract the tarball as root into the root filesystem using:
cd / && tar xvfz /tmp/opt.chef-11.14.6.tar.gz
verify your chef-client version is now reported as 11.16.4 with "chef-client -v"
run your knife bootstrap command like normal, but don't include the --bootstrap-version parameter, it'll detect chef-client is already installed and use the one you have installed manually.
I did not try rebuilding it.
I searched about this topic and could not find anything so here I go with my question: I have Linux running in Vagrant as guest, Windows as host; I shared folders with rsync to speed up development with Rails (using NFS or SMB is extremely slow); some of my PHP dependencies get installed with Composer within my project, so when I run Composer via SSH from the guest it downloads and installs them, however, when I restart my VM I lost the dependencies downloaded and need to start over.
So is there anything I could do to run Composer remote or locally, and not loose my changes? so far I've tried changing the sync type to SMB, run Composer, and then go back to rsync, however, I need to switch on and off and I'd like something more automated...
Thank you for your help!
Carlos.
From the docs:
The rsync synced folder does a one-time one-way sync from the machine running to the machine being started by Vagrant.
So this is intentional: If you don't get the result of ANY changes (not just Composer) out of the vagrant machine onto your copy on Windows, it will always get lost inside the VM.
Use SMB or shared folders and bear the performance penalty. Or try and get a NFS server for Windows and install the files inside the VM via NFS.
I want to use Jenkins for creating RPM packages to deploy code and scripts onto a Linux redhat machine(s)
So the applications are a mix of technologies (no compiling needed) i just need to package up the applications deploy them to the correct location restart apache
Would anybody have some instructions on how to do these steps for a total Newbie:
Some questions:
Do i need to install jenkins on a local linux machine if im going to be creating RPM's that will be deployed on to linux redhat machine (i was hoping to install jenkins on windows)
Does anybody have a example of creating a package out of a local folder (no source control for the moment)
I want to just specify the directory of where to take the code from and specify where to deploy the code to on a machine the rpm is installed on
On the destination machine i want to run something like
yum -install mypackage-version12.rpm
and it will install the code/scripts to the specified directory and restart apache
i need an example of this also.
Thanks
You can install Jenkins on a different machine, but you generally must have a Jenkins "node", "slave", "agent" installed on a machine that can generate RPM packages.
Running each step of the RPM package setup is putting all the steps to build within Jenkins. It works much better if you extend your build system to build the RPM, and have Jenkins do what it does best, manage the build (schedule, etc), not micro-manage the build (do the steps).
Depending on what you currently have as your build system, this might include ant directives to setup the rpm build tree, copy in the .spec file, and a executable call to rpmbuild.
Jenkins can easily call a post-build task to do this, or you might want to configure a mini "fake" project that does the update, depending on tastes.
As an aside, for a yum command to work without using the --localinstall option, you will need to have a web server set up, the new RPM copied to the right folder on the web server, and the indexing files rebuilt (repobuild is the script to do so, if I recall correctly).
On the client machine (where the package will be installed), you will need to have a yum configuration that directs the client machine to include the web server as one of the known yum repositories.
Why not use an Docker images to build the RPM inside it though a dedicated stage ?
Your code needs to provide /rpm/SPEC files and inside the Docker (Jenkins) you can have a Jenkinsfile like :
mkdir -p ./rpm/BUILD && cd ./rpm/ && for f in ./SPECS/*; do rpmbuild --define \"_topdir \$(pwd)/\" --define \"_builddir \$(pwd)/BUILD\" -bb \$f;
And you are done.