The only source code related to perf I could find is in the kernel source, so am not sure what I need to do to get the latest perf.
If I upgrade the kernel version (leavin the rest of my distro unchanged), will I now get the latest version of perf or is there a user space library that I also need to rebuild?
Edit -
I see that the perf source is not actually in the kernel source but in a separate tools directory and I can just build this directory.
In deb based distribution perf is usually provided by a package with a name starting with linux-tools and yes, the version X of perf it's not designed to run on the kernel number Y, it's a program that is strictly tied to the kernel.
For example on Debian/Ubuntu you can write
sudo apt-get install linux-tools-$(uname -r)
Related
I got a binary kernel module provided by 3rd party, which expects version magic 5.4.0-81-generic SMP mod_unload modversions aarch64 of the kernel. It means that I need to grab the exact source tree to build the kernel for using the .ko, on my own customized SoC platform.
Now I have serveral questions for this task:
5.4.0-81-generic: 5.4.0 seems refer to the official kernel version 5.4; what is 81? Is this a patch level (or abi number)?
Can I obtain the exact source tree by patching the official kernel version 5.4? If so, where can I find the corresponding patch file for patch level 81?
I can do apt install linux-source-5.4.0, but there is no patch level on the linux-source pkg name. However, to install the headers, there are patch level on the pkg name, e.g. apt install linux-header-5.4.0-81? Why the difference?
Thanks!
Ubuntu collects its own patched sources into a source package which you can download.
The version number includes a build version; the upstream sources (the Linux kernel) does not have an Ubuntu build, but each released build has a specific version with a number after the dash and you want exactly the right one.
apt-get install linux-headers-$(uname -r)
If you want the full sources,
apt source linux-generic
though in practice you want to read the instruction it prints and download the sources from Github.
Perhaps see also https://ubuntu.com/kernel and https://linuxhint.com/install-linux-kernel-ubuntu/
I'm running an old version of my linux distro (fedora, but this is not very relevant) and for reasons which are completely irrelevant I'm not in a position to update it. However I do need a newer version of gcc and some other libraries than those supplied by my old distro.
I could compile a newer gcc and all the other libraries of course but I thought the simplest way would be to install a minimal set of packages from the latest distro version to a directory and then just chroot there. This way I'd take advantage of the binary packages present in the newest distro and all the infrastructure around it (like dependency installation, etc.) and I wouldn't need to compile everything from source.
My question is this: if I only would like to be able to compile with the most recent gcc and run those programs, what is the minimal set of packages I need? Since we are talking about fedora, what is the minimal set of rpms (beyond glibc and gcc)? Note that I don't need any X environment, networking, or anything like that, only the most basic terminal tools.
The minimal set varies depending on your user needs and what you're linking with. What I do when making a chroot environment is have a look at the distro I want to chroot and see if they have a base rpm/deb package that kickstarts everything. Then I install that in the chroot. From there I add libraries and applications as needed.
For an example where I create a chroot for RHEL on Arch see http://www.zenskg.net/wordpress/?p=267
I need to add new functionality to a chinese Linux-based time attendance clock. More specifically I need to make It SNMP capable, which is not available by factory default.
After some research I found a login:password which worked for the TelNet login and managed to get inside the system with root privileges.
The first thing I did was to figure out which Linux distro was It running:
cat /etc/issue throws this:
"PXA Linux Preview Kit
Kernel 2.6.29 on armv5tejl"
I did a quick google search and found that
"PXA Linux is a port of the Linux kernel for PXA based processor based devices and machines."
I dont understand why It's running a PXA Linux Preview Kit on an armv5tejl.
I gave no importance to this fact, and got to the next step: finding which package manager has this system:
I tried several commands:
apt-get, aptitude, rpm, dpkg, yum, slapt-get, ipkg, and several others. None of them worked.
I found that the system had Busybox installed. More specifically BusyBox 1.15.3. In this BusyBox I couldnt find any of those commands. I found that BusyBox does implement rpm and dpkg but this version doesnt have them.
The only command which seems to be "software installation related" I found was the command "install". From BusyBox docs:
"install [-cdDsp] [-o USER] [-g GRP] [-m MODE] [source] dest|directory
Copy files and set attributes"
But probably it doesnt replace the package manager tool. I think that I need to get a way to install dpkg or rpm, and then use them to install the SNMP packages I want. As I read, the lowest level package installation tool is dpkg so I don't have a clue on where to begin.
Can someone give me some advice on how to approach this issue? How can I install a package with no package manager possiblities at all?
You won't be able to install additional software to that system via a package manager. Such devices aren't designed like that. The firmware that was shipped with the device is all there is. What would be the incentive of the device manufacturer to maintain a package repository with general purpose linux software?
But not all hope is lost. You can of course try to compile the needed software yourself (and by that extend the firmware). For that to work you will need a suitable ARM cross compiler (GCC). Via static linking your SNMP package won't have any dependencies to the library versions already on the device (so you don't need a sysroot matching the libraries on the device).
I am working on linux on ubuntu. I am modifying the source code of linux 2.6.25 by adding a system call while my operating system has some other version of linux installed. To test my modified code, do I need to install an emulator or can I test it on the terminal window itself?
If I can build and compile my linux 2.6.25 on the terminal, how should I do it?
You can test your modified kernel by installing that kernel in your current Ubuntu system.
Please follow following steps to install kernel in your system.
1) compile your modified linux kernel
make
2) Install that kernel using following command
make modules_install install
3) update initramfs as per the changes made in kernel using following command
update-initramfs -u -k 3.0.0
4) Finally, Update the grub loader to add the entry of your kernel in boot loader using following command.
update-grub
5) Reboot the system and execute the uname -r command to verify that you have updated your kernel or not.
reboot
uname -r
You can find your updated kernel with your existing kernel on next reboot and check your updated kernel which you have modified with that kernel.
Please let me know if you need any more information,
You can use User Mode Linux.
Using UML, you can even use gdb to debug it.
http://user-mode-linux.sourceforge.net/
http://user-mode-linux.sourceforge.net/hacking.html
Although the document is rather old, it still works in recent kernel.
I've installed a RPM (MySQL Shared glibc Library). After that I couldn't boot my fedora Linux box (Because of some crash with kernel glibc). I boot via LiveDVD and renamed the RPM's copied files, but it can't solved.
How can I uninstall my RPM (not only files) through other Linux or Live CD?
If you boot from a live cd you can remove rpm packages from the installed system by running
rpm --erase --root /mnt/your_system_mount_point the-package-you-want-to-remove
Another alternatively is boot the system by editing the boot loader kernel command line to contain init=/bin/bash and try to run rpm --erase the-package-you-want-to-remove from there. If the problem is with glibc you might have trouble getting bash executed (as well as rpm), but you might want to try this option as well just to see how far the startup is progressing without problems. Thinking of it, busybox usually comes with a statically linked binary that could be used as init shell, you might have better success using that.