I want to rebuild the Linux kernel with changing the time frequency to 1000 Hz. Can anyone provide me a reference or the instruction to do so.
the current Linux kernel version is (using ubuntu):
4.4.0-83-generic
It's easy enough to download sources. You can actually, on ubuntu, run:
apt-get source linux-image-amd64-4.4.0-83-generic
apt-get build-dep linux-image-amd64-4.4.0-83-generic
The first command will download the source for that kernel (to the current directory); the second will install all packages needed to build it. When that's done, enter the linux-image folder, and
zcat /proc/config.gz > .config
This will get the currently-running kernel config into this build area. Finally, make menuconfig
will open a text-based menu system. Press / to search, and find HZ. Browse to the setting, press <Enter> to open it, and select 1000. Exit out, saving the config, then make bzImage modules -j9 to build the kernel (replacing 9 with one more than your CPU core/thread count for speed).
make install will put the kernel and modules into /boot and /lib/modules/kernel_name_and_version respectively.
Related
I want to use the writeprotect mode of the userfaultfd feature, but it is implemented only from Linux 5.11.
I have ubuntu 20 with kernel 5.4 so I installed version 5.11 of Linux from sources, but when I reboot on the installed version, and try to use the writeprotect mode in a c user program the macros (e.g., UFFDIO_WRITEPROTECT) still appear not to be defined. And I verified that userfaultfd is not a module (doing lsmod).
In the other hand, if I make a modification for example in the scheduler just for a test (let's say in kernel/sched/core.c:context_switch) the modification are taken into account because this is in-core, but modifications for user space are not, I'm confused.
The userfaultfd.c file is in the fs/ directory of the kernel.
So please is it something that I'm missing in the compilation process (make menuconfig, make, make modules_install, make) ?
I was wrongly interpreting the error I had.
The modifications are indeed taken into account when I boot on the newly compiled kernel.
But while searching an understanding of what happens when booting on a compiled kernel, I got this:
When booting on a kernel compiled from sources, the libraries in /usr/include are not modified on the disk
If you want to overwrite them by the one modified, you should do this:
make deb-pkg //from the kernel sources directory
cd ..
sudo dpkg -i *.deb
This will install the new kernel and overwrite the headers
I'm trying to install a linux-Kernel version 4.9.228 in my ubuntu 20.04.
The kernel compiled successfully, without any errors. I also executed the command:
sudo make modules_install install
When I rebooted my system, to check whether it made correct entry, I checked the files under the /boot/ directory:
System.map-4.9.228
vmlinuz-4.9.228
initrd.img-4.9.228
config-4.9.228
I don't know why but when I ran uname -r. It hasn't updated my version. It still says 5.4.0-37-generic.
Please guide me if I am missing something.
Note: The sole purpose of doing all this, is to learn how to add a system call and how to compile a kernel. I'm open to suggestions, if you got any. Thanks.
You might have successfully installed a different kernel version, but in order to boot into it, you need to tell the bootloader to do so.
I'm going to assume that you are using GRUB2 as bootloader, since it's standard on most distributions including Ubuntu. In order to boot the new kernel, you have multiple options.
Option 1
This is the safest and recommended option.
Edit the GRUB configuration file /etc/default/grub (you need to be root, so use something like sudo vi or sudo nano) and make sure that you have GRUB_TIMEOUT=N where N is a number of seconds. If you don't, then just add it in a new line. You want N to be at least 5 or 10 so that you have time to select the correct kernel version when GRUB starts.
Additionally, make sure that you do not have any of the following lines (you shouldn't have them, but if you do, remove or comment them):
GRUB_DISABLE_RECOVERY="true"
GRUB_DISABLE_SUBMENU=y
GRUB_HIDDEN_TIMEOUT=N
GRUB_TIMEOUT_STYLE=hidden
Save the changes to /etc/default/grub and run sudo update-grub. This will detect currently installed kernels and add them to the bootable list when you start the computer and enter GRUB.
Reboot your PC, when GRUB starts you will see a list of options. If you don't do anything, your default kernel will boot, otherwise you can use the arrow keys and the ENTER key to navigate to "Advanced options for Ubuntu", where you will find the list of available kernels and you will be able to select the one you prefer.
It should look something like this:
Option 2
Use only as fallback if option 1 does not work (it should, but you never know). This is not as clean as option 1 because it changes the default kernel, and changes are also probably going to be overridden by an upgrade of your current kernel (which technically does exactly this to update the default version).
Make the kernel you want the default one by changing the two symlinks /initrd.img and /vmilunuz to point to the right versions of the kernel and initrd image. This can be done either manually or through the linux-update-symlinks command.
$ linux-version list --paths
... grab the correct VERSION and PATH ...
$ sudo linux-update-symlinks install VERSION PATH
Run sudo update-grub to let GRUB detect the changes.
Reboot your PC.
Option 3
Manually boot into the kernel you want from the GRUB command line. This is an advanced option and I'm listing it only as a last resort, you should never need to do this unless you have completely broken your system configuration.
Reboot the PC into GRUB, and as soon as you see it, press C to enter the GRUB command line.
Follow this answer from now on.
In any case, remember that playing around with kernel development on your own machine is not a good idea if you are not sure what you are doing. I recommend you use a virtual machine to experiment with the kernel, that way if anything goes wrong you can just throw it away and create a new one.
I know that on the internet I can find same information about "adding one driver to linux kernel" but I can not get it working.
I need to compile an ADV7800driver. It is based on adv7180 driver code.
I put my driver file (adv7800.c) into /linux_source_folder/drivers/media/platform/mxc/capture folder. I also add
adv7800_converter-objs := adv7800.o
obj-$(CONFIG_MXC_ADV7800_CONVERTER)+=adv7800_converter.o
in makefile in the same folder and add information in Kconfigfile.
Then I go back to /linux_source_folder and do sudo make menuconfig and set adv7800 as a module and save config. Then sudo make defconfig, then sudo make -j4 modules (now waiting about 2 hours) and then sudo make modules install.
As a result I can see every module which I configure in menuconfig but I can not see my own module (only .c file exists).
How can I do this correctly and how can I build only this one module without building others (to same much time) ?
I do not remember exactly what happens in terms of instructions executed, but the idea of defconfig is to set a default configuration for a given architecture/platform.
If, as you said, you run sudo make defconfig after you configure your module to be compiled, most likely you loose your configuration. The defconfig should be executed first (once) and then you customize the configuration.
Regarding the compilation of a single module, I point you to an old answer
How to "make" existing Linux kernel module driver after modifying the driver source code.
One note: you should not use sudo to compile
I need to compile an old kernel 2.6.23 (downloaded from linuxkernels.com) in order to use it with a real time patch (it's a long story...), I installed ubuntu 10.04 which has a kernel 2.6.32-43-generic-pae.
I decided to simple copy ubuntu configuration:
cp cp /boot/config-2.6.32-43-generic-pae /usr/src/linux-2.6.23/.config
I recompile the kernel:
make menuconfig
make
make install
make modules_install
mkinitramfs -o /boot/initrd.img-2.6.23-MYVER 2.6.23-MYVER
note that in the config I make this edit: I remove the module versioning support under loadable modules section. (this step is required by the patch).
At start, I get the title error:
cpufreq: no nforce2 chipset error
how it possible, since I copied a working configuration? Maybe is because of that only flag I disable?
Not sure, but when I copy an existing .config, I run "make oldconfig" first to make sure I'm all sync'd up. Then I run make menuconfig if I want to interactively review/change any settings.
Is there a way to get a list of filenames/paths that make install copies to the filesystem? Some packages come with a MANIFEST file, but not the ones that I am working with.
I was just investigating this myself while compiling a custom version of QEMU. I used the following method to work out what was installed and where (as well as using it as a basis for a .deb file):
mkdir /tmp/installer
./configure --target-list=i386-softmmu
make
sudo make install DESTDIR=/tmp/installer
cd /tmp/installer
tree .
Tree is a utility that recursively displays the contents of a directory in a visually appealing manner - sudo apt-get install tree for Debian / Ubuntu users
Hope that helps someone... it took me a bit of poking around to nut it out, but I found it quite a useful way of visualising what was going on.
The most fool-proof way is to use chroot: have "make install" run inside a chroot jail; compute a list of the files that you had before the installation, and compare that to the list of files after the installation.
Many installations will support either a --prefix configuration option, and/or a DESTDIR environment variable. You can use those for a lighter-wait version of chroot (trusting that the installation will fail if it tries to write to a location outside these if you run installation as a fairly unprivileged user).
Another approach is to replace the install program. Many packages support an INSTALL environment variable that, well, is the install program to use; there are tracing versions of install around.
make uninstall might show the files as it removes them if the author of the compiling instructions provides the information to allow an uninstall (it has been awhile since I have done one so I can't say for sure).
Also make -n install will do a "dry run" of the install process and it may be reasonable to extract the information from its results.
It differs for every project that you run 'make install' on. The files which are installed are controlled by the install target in the Makefile being used. Your best bet is to open the Makefile and search for 'install:' - from there you can see what files will be copied out to your system.
Take a snapshot of the contents of the install location before installing
Install
Compare the current contents with the old contents.
Example:
./configure --prefix /usr/local
make -j`nproc`
find /usr/local | sort -u > /tmp/snapshot1
make install
find /usr/local | sort -u > /tmp/snapshot2
comm -3 /tmp/snapshot{1,2} # this prints the files added by `make install` to stdout
If the install program you're using doesn't support DESTDIR or --prefix (or an equivalent), I have found that it may be possible to identify new files as follows:
Start with as clean a system as possible (a fresh VM image is preferable)
Compile the software, wait a few minutes.
Install the software package.
Find files modified within the past 5 minutes: sudo find / -mmin -5 -type f (the find command has a ton of parameters for querying based on file modification / creation times, but this worked pretty well for me; you just need to narrow the time span so that you pick up the files created by the installer but nothing else).