Editing vmlinuz file in linux - linux

I'm new to linux.
I want to edit "This kernel requires an x86-64 CPU, but only detected an i686 CPU.Unable to boot - Please use a kernel appropriate for your CPU" from vmlinuz file(RHEL6.0)
If editing this message is possible Can anyone suggest a way to modify message.

The message is in /arch/.../boot/cpu.c in the linux kernel source. You can modify it, recompile the kernel and install the new kernel.

you can grep the kernel sources for this string, and replace it with whatever you want, and then recompile your kernel. Usually replacing a string directly inside a binary (though it is technically possible), especially for the kernel is a very bad idea

Related

How to get distro name and version from linux kernel code?

I am looking if there is any API through which we can get OS distribution name and version from a Linux kernel module?
For example, I am using SLES 12 service pack 4. This information is present in /etc/os-release file. I want to know if there is any way to get this information from kernel code.
linux:/ # cat /etc/os-release
NAME="SLES"
VERSION="12-SP4"
VERSION_ID="12.4"
PRETTY_NAME="SUSE Linux Enterprise Server 12 SP4"
ID="sles"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:12:sp4"
linux:/ #
There's no kernel API for detecting the current OS distribution, simply because it's not really needed. The Linux kernel itself is distribution-agnostic, and it couldn't care less which distribution is being run on top of it (having the kernel depend on what's being run on top of it wouldn't make much sense).
If you really want, you can open, read and parse the file yourself from kernel space. See more in this other post for an example, and in particular this answer for modern kernels. In any case, remember that filesystem interaction from kernel space is generally discouraged, and could easily lead to bugs and compromise the security of the kernel if done wrong, so be careful.
If you are developing a kernel module, I would suggest you to parse the /etc/os-release file from userspace when compiling/installing the module and use a set of #defines, or even module parameters. In any case, you should ask yourself why you need this information in kernel code in the first place, as you really shouldn't.

Can i use gcov for kernel modules without recompiling the whole kernel?

I have ubuntu OS and i installed gcov in it.
I am able to use gcov for my c-program which is in user space and i am getting the desired results.
When i want to use gcov for my .ko files(kernel space) i am getting an error.
I googled and from the below mentioned link i found that i will have to recompile my whole kernel by enabling CONFIG_DEBUG_FS, CONFIG_GCOV_KERNEL, CONFIG_GCOV_FORMAT_AUTODETECT and CONFIG_GCOV_PROFILE_ALL.
http://techvolve.blogspot.in/2014/03/how-to-gcovlcov-for-linux-kernel-modules.html
Do i have any other way to integrate gcov for my kernel loadable modules without recompiling kernel?
If more information is required from my end please let me know. I will update it.
Thank You
Without support from the Linux kernel core you cannot collect coverage from a kernel module. So, if you current kernel has no such support, you have to recompile it.
CONFIG_GCOV_PROFILE_ALL isn't needed for coverage from the kernel module, however other configuration options are needed:
CONFIG_GCOV_KERNEL - enables coverage counters in the kernel space,
CONFIG_DEBUG_FS - enables debugfs filesystem, the only way for extract those counters into the user space,
CONFIG_GCOV_FORMAT_AUTODETECT - describes the format of the collected coverage (you may chose configuration option which selects specific format instead of autodetecting).

Mac equivalent bless on Linux

Is there any equivalent mac "bless" command in Linux. I am specifically interested in the option "--bless-folder".
No. You'll need to configure things like grub to specify where it should find your kernel, and what arguments to pass to the kernel. Quite often the arguments to the kernel would include:
root=/dev/sda1 which means the filesystem can be found on a particular partition of a particular disk;
init=/sbin/init which is the very first file the kernel executes, which loads the whole of the rest of the OS.

How to run aout on linux?

The question is how to execute aout-format binary (I mean old format which for example used on FreeBSD before it has migrated to ELF) on Linux system. Is there a possibility to do so without extra coding (is there some existing solution)? Probably it should be in form of kernel module or patch for the Linux kernel. Another solution could be user-space launcher (may be even run-time linker). I have searched for something similar but was unable to found something. I have not yet checked difference in system calls interfaces, if you have some comments about that, you are welcome to provide them.
P.S. I know that writing user-space launcher for aout static binary is quite trivial but the question is about some existing solution.
Check for CONFIG_BINFMT_AOUT in your kernel config.
If your kernel has /proc/config.gz:
zgrep CONFIG_BINFMT_AOUT /proc/config.gz
On Ubuntu and the like:
grep CONFIG_BINFMT_AOUT /boot/config-$(uname -r)
Kernel option was CONFIG_BINFMT_AOUT, not sure if it's still around or necessary.

Arguments to kernel

Is there anything that the kernel need to get from the boot loader.Usually the kernel is capable of bringing up a system from scratch, so why does it require anything from boot-loader?
I have seen boot messages from kernel like this.
"Fetching vars from bootloader... OK"
So what exactly are the variables being passed?
Also how are the variables being passed from the boot-loader? Is it through stack?
The kernel accept so called command-line options, that are text based. This is very useful, because you can do a lot of thing without having to recompile your kernel. As for the argument passing, it is architecture dependent. On ARM it is done through a pointer to a location in memory, or a fixed location in memory.
Here is how it is done on ARM.
Usually a kernel is not capable of booting the machine from scratch. May be from the bios, but then it is not from scratch. It needs some initialisation, this is the job of the bootloader.
There are some parametres that the Linux kernel accepts from the bootloader, of which what I can remember now is the vga parametre. For example:
kernel /vmlinuz-2.6.30 root=/dev/disk/by-uuid/3999cb7d-8e1e-4daf-9cce-3f49a02b00f2 ro vga=0x318
Have a look at 10 boot time parameters you should know about the Linux kernel which explains some of the common parametres.
For the Linux kernel, there are several things the bootloader has to tell the kernel. It includes things like the kernel command line (as several other people already mentioned), where in the memory the initrd has been loaded and its size, if an initrd is being used (the kernel cannot load it by itself; often when using an initrd, the modules needed to acess storage devices are within the initrd, and it can also have to do some quite complex setup before being able to access the storage), and several assorted odds and ends.
See Documentation/x86/boot.txt (link to 2.6.30's version) for more detail for the traditional x86 architecture (both 32-bit and 64-bit), including how these variables are passed to the kernel setup code.
The bootloader doesn't use a stack to pass arguments to the kernel. At least in the case of Linux, there is a rather complex memory structure that the bootloader fills in that the kernel knows how to parse. This is how the bootloader points the kernel to its command line. See Documentaion/x86/boot.txt for more info.
Linux accepts variables from the boot loader to allow certain options to be used. I know that one of the things you can do is make it so that you don't have to log-in (recovery mode) and there are several other options. It mainly just allows fixes to be done if there's an issue with something or for password changing. This is how the Ubuntu Live-CD boots Linux if you select to use another option.
Normally the parameters called command line parameters, which is passed to kernel module from boot loader. Bootloader use many of the BIOS interrupts to detect,
memory
HDD
Processor
Keyboard
Screen
Mouse
ETC...
and all harwares details are going to be detected at boot time, that is in real mode, then pass this parameters to Kernel.

Resources