I am new to VyOS development. I have written a code, which will fetch info from VyOS kernel module and write it on a netlink socket.But the problem is I am not sure whether
Can I edit the kernel module code directly to call my defined function or I have to write the patch.
If I have to make a patch file for it then where to place it in kernel source code. I have already made a patch file using diff command.
I have searched a lot about this problem but couldn't find the satisfactory solution.
Thanks.
After a long search I solved the problem I was facing. Here is conclusions in case any of you gets stuck in same problem.
Yes, you can edit the kernel module code in VyOS Development. But this method is not much appreciated.
Yes, you can write patch for kernel modules too. and it should be in GIT formate as described in How to write VyOS Patch. Soon I will update, where to place .patch file in VyOS kernel code.
To check the debugging output using dmesg, use KERN_DEBUG option. As I am not sure about others.
printk(KERN_DEBUG "%s: Debuging info \n", __FUNCTION__);
Moreover to check modification in VyOS kernel you don't need to make a complete ISO file all the time. You just need to run following commands.
*Note each path is
described everytime from the main iso building directory to avoid path problems.
cd build-iso/
sudo make clean-linux-image
sudo make linux-image
Then
cd buil-iso/pkgs/
Here you will find these debian packages.
buil-iso/pkgs/linux-image-3.13.11-1-amd64-vyos_999.dev_amd64.deb
buil-iso/pkgs/linux-libc-dev_999.dev_amd64.deb
buil-iso/pkgs/linux-vyatta-kbuild_999.dev_amd64.deb
Copy these files to an already installed VyOS Sytem and install them over there.
dpkg -i linux-image-3.13.11-1-amd64-vyos_999.dev_amd64.deb
dpkg -i linux-libc-dev_999.dev_amd64.deb
dpkg -i linux-vyatta-kbuild_999.dev_amd64.deb
reboot the system and check you modifications using dmesg.
Related
Sure, I've "chosen the wrong OS," Fedora instead of RHEL or CentOS, but I am where I am and there's no rtmp module in the standard distribution of nginx for Fedora since both RHEL and CentOS DO have the rtmp module available as a standard package.
So, I downloaded the source and did a build. While the call make install does the build (and I didn't see any errors in the 817 lines of output), it DOES NOT do the installation?!
At first I went down the wrong garden path, which is not totally wrong (see below as "Part II") but while writing "Part II" for this posting, I realized that I can't even find ANY evidence that it compiled ANY of the source for the rtmp module?! I followed the directions in the module's github readme file.
Of course, I kept a log of the run - too long to post here.
Having decades of coding experience I knew to check for a Makefile for that code and didn't find any?! STRANGE, right?
If anyone asks for info from that log, I have it and will provide it, but IDK what you may want to see from it.
Part II
I figured the installation didn't happen because the source code is written generically and doesn't pay any attention to the OS it's being installed on, and that's what "packaging" is all about and what package maintainers have to deal with...
I don't really have time to learn ALL the ins and outs of these packages, but I do know that the standard nginx packages provide these modules:
usr/lib64/nginx/modules/ngx_http_perl_module.so
usr/lib64/nginx/modules/ngx_http_image_filter_module.so
usr/lib64/nginx/modules/ngx_mail_module.so
usr/lib64/nginx/modules/ngx_http_naxsi_module.so
usr/lib64/nginx/modules/ngx_stream_module.so
usr/lib64/nginx/modules/ngx_http_xslt_filter_module.so
usr/lib64/nginx/modules/ngx_http_vhost_traffic_status_module.so
However, I don't see the compilation creating ANY .so files, much less moving them where they go on Fedora (the default is apparently /etc/nginx/modules). Further, the log output directed me to look to /usr/local/nginx, and there no .o or .so files at all but rather a single binary. That's fine, but doesn't help me, I presume, unless I want to screw around with moving files from where they're "expected" from the OS vs nginx point's of view and that sounds to me like a time-sink of massive proportions.
However, this IS a one-off installation at the moment and I'd rather not have a lot of pain whenever this box (and likely others to follow if this works) needs an upgrade. So, I found this gem of a blog posting. It touches on this problem but also seems rather involved as I don't fully grock it yet.
If I could simply learn how to build the correct file, which I presume is intended to be (once installed):
/usr/lib64/nginx/modules/ngx_rtmp_module.so
...from the .c source files, then I'm pretty sure I could "figure it out from there."
(Another possibility might be to find a way to prove from some sort of analysis that the GetPageSpeed people didn't alter the source when providing their package. Or, perhaps I could convince the package maintainer to include the rtmp package in with the standard packages available for Fedora, but, well, at best that's a long wait.)
It turns out that the build from source skips the .o and .so file stages and just builds an executable.
It's not set up for running in the normal, modern Fedora environment, however, as already noted above.
Not finding another answer and wanting to move on to other things, I simply got this from-source version working and it wasn't that hard. Note that this presumes you've installed the standard nginx package(s), which in this case hook in your man pages, systemd interfaces and so on so you can manage it as usual. In your favorite shell, as root:
# First, for my own sanity:
#
cd /etc
mv nginx nginx.from_FC_distro
ln -s /usr/local/nginx
cd /usr/local/nginx/logs
mv error.log error.log.orig
ln -s /var/log/nginx/error.log
#
# Now, get it to run and STAY running:
#
cd /usr/sbin
mv nginx nginx.from_FC_Distro
# Then EITHER this:
cp -p /usr/local/nginx/sbin/nginx /usr/sbin/nginx.from_src
ln -s nginx.from_src nginx
# OR this:
ln -s /usr/local/nginx/sbin/nginx
# Either vi or the echo works:
# vi /etc/nginx/conf/nginx.conf
echo "pid /run/nginx.pid;" >> /etc/nginx/conf/nginx.conf
#
# Finally:
systemctl enable nginx.service
systemctl start nginx.service
And now you have a running installation of the nginx server with whatever config you set up in the config file WITH the rtmp service! AND, you can manage it as usual. Upgrades aren't so hard, either, just don't bother with upgrading the nginx package the usual way. I'm sure the script-kiddies can figure out how to script it based on this article.
I have the following problem , i need to run installation process using DPKG but on all CPU cores , all i can find are ways to compress the files using pixz after dpkg source code modification but absolutly nothing about decompression instalation it self.
Do anyone did sth like that ? or is there some more detailed description/documentation of dpkg source code ?
Thanks in advance.
This was due to missing multi-threaded support in liblzma upstream, but this has landed there already. A release of liblzma has also been made, it just needs to be uploaded to Debian. Once that's done, I've already got the code to make dpkg use the multi-threaded decompression support for xz. It should not be too long now I guess. But that will only hit Debian unstable/testing until the next stable release happens.
I have configured and compiled the FFmpeg library using this link:
https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
Now, I am trying to build example C codes provided by FFmpeg from here:
https://github.com/FFmpeg/FFmpeg/tree/master/doc/examples
However, when I run make install-examples or make install (suggested by /example/README), I receive this kind of message:
make: *** No rule to make target '/doc/examples/README', needed by
'install-examples'. Stop.
I thought this may be due to the rules not being in the correct MakeFile format (I am not sure why they refers to README). How should I go about in fixing this and compiling the example codes? I have tried to find solutions about this, but there doesn't seem to be much information online.
Thank you.
Run ./configure && make -j4 examples in the FFmpeg source directory, then look in doc/examples for the compiled examples.
Requires make and pkg-config.
To remove the compiled examples use make examplesclean in the FFmpeg source directory.
nasm/yasm not found or too old. Use --disable-x86asm for a crippled build. If you think to configure made a mistake, make sure you are using the latest version from Git. If the latest version fails, report the problem to theffmpeg-user#ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net.Include the log file "ffbuild/config.log" produced by configure as this will help solve the problem.
If you see this when you execute the above command then do this
macOS:
brew install yasm
Ubuntu:
sudo apt-get install yasm
I installed simgrid according to instruction in INSTALL file:
cmake -DCMAKE_INSTALL_PREFIX=~/SimGrid -Denable_maintainer_mode=off -Denable_java=on -Denable_scala=off -Denable_lua=off -Denable_smpi=on -Denable_model-checking=off
make
sudo make install
But I can't find msg.h file in include directory:
What did I make incorrectly?
you are definitely not using a 3.13 version of SimGrid but at most a 3.11. I'm certain because the file you are using (msg/msg.h) does not work anymore since then. Plus, 3.13 introduces many files that should appear on that screenshot.
Could you please fix your question, or close it ?
I am using ubuntu, but the question is for linux in general.
I installed a module/driver by compiling my linux kernel and install the new compiled kernel. It works fine.
In order to make this driver work in another machine without installing the new kernel, I copy the .ko file to the new machine under /lib/modules/<version>/... and then run sudo depmod -a. Then run sudo modprobe <drivername>. The module can be loaded without a problem. but the device is not working well with this .ko module.
The two machines are not identical to hardwares, BUT they are identical to kernel version and ubuntu release version. Normally, copying .ko file should work for the same linux release and the same kernel.
More information about the driver. it's a hid pen tablet driver. All patch files:
one .c file in drivers/hid/
add one line in drivers/hid/Makefile
add a few lines to drivers/hid/usbhid/Kconfig
add a few lines to drivers/hid/hid-ids.h
add a few lines to drivers/hid/usbhid/hid-quirks.c's hid_blacklist struct before { 0, 0 }
That's all.
I even tried to copy the entire drivers/hid/ directory includig all the .ko files from the first machine to the second one. but no luck. The pen tablet can be recognized in the second machine, I am able to do mouse left click event with the pen, but the pen can not move the cursor.
Hopefully, I provided enough details. My goal is to only install the module to identical linux release (kernel) without reinstalling the kernel. I am not sure how to achieve that or if it's possible.
Thanks a lot.
PS:
The dmesg output in 1st machine which works: http://paste.ubuntu.com/6419301/
The dmesg output in 2nd machine: http://paste.ubuntu.com/6419302/
In 1st machine, before plugging in the tablet, lsmod doesn't show the module. after plugging in, the module can be loaded automatically. I can see lsmod shows the module.
In 2nd mahcine, the module can not be loaded automatically by plugging in the device. I have to do sudo modprobe <module> manually.
Since I will have to install the module to many machines in my company, it's easier to install the module without reinstalling the kernel. I tried to install the kernel .deb packages which built in the 1st machine to the 2nd machine, it works fine in 2nd machine. but I don't feel good to reinstall the kernel to many machines. Thanks.
It seems the kernel you built isn't a 1:1 match. Also, generally there's no need to compile a new kernel.
The simplest way to deal with an out-of-tree driver deployment is to use DKMS.
What you need to provide is just a dkms.conf file specifying the package name, version, and driver names and destinations (within /lib/modules/{kernel}).
In the following examples, things within braces need to be replaced with the real thing, e.g. if version is 1.0.0, then {version} with 1.0.0, obviously.
Example dkms.conf:
PACKAGE_NAME="{mydriver}"
PACKAGE_VERSION="{version}"
BUILT_MODULE_NAME[0]="{mydriver}"
BUILT_MODULE_LOCATION[0]="/{mycompany?}"
AUTOINSTALL="yes"
Then you just need to install the sources to /usr/src/{mydriver}-{version}, and run dkms:
dkms add -m {mydriver} -v {version}
dkms build -m {mydriver} -v {version}
dkms install -m {mydriver} -v {version}
You should take a look at what other people have done in this area, there's a great deal of automation you can apply to testing and release processes. Bluecherry's solo6x10 out-of-tree version provides some useful make targets (disclosure: I'm the one who wrote that).
Also, you definitely want to build and distribute packages, you can use solo6x10/debian as a template, and you can read about repositories in the Debian wiki.
You can add the module to /etc/modules so it's loaded at boot time.