While installing a linux distro (say centos), the following messages appear on console:
Loading vmlinuz....
Loading initrd.imag .......
These files (vmlinuz and initrd.imag) are located under isolinux/ directory inside the ISO.
It is clear that "Loading initrd.img" is expanding the given file system with required (small-set of) drivers.
I would like to know what happens exactly (in theory and possibly pointer to what kernel code does it) when "loading vmlinuz" while installing ?
Is there any relation (at code level) when we see the message (Uncompressing kernel...) while booting up (as boot loader comes here after installation completed)?
Thank you.
Sri
Related
I've just compiled BPF examples from kernel tools/testing/selftests/bpf and tried to load as explained in http://cilium.readthedocs.io/en/v0.10/bpf/:
% tc filter add dev enp0s1 ingress bpf \
object-file ./net-next.git/tools/testing/selftests/bpf/sockmap_parse_prog.o \
section sk_skb1 verbose
Program section 'sk_skb1' not found in ELF file!
Error fetching program/map!
This happens on Ubuntu 16.04.3 LTS with kernel 4.4.0-98, llvm and clang of version 3.8 installed from packages, iproute2 is the latest from github.
I suspect I'm running into some toolchain/kernel version/features mismatch.
What am I doing wrong?
I do not know why tc complains. On my setup, with a similar command, the program loads. Still, here are some hints:
I think the problem might come, as you suggest, from some incompatibility between kernel headers version and iproute2, and that some relocation fails to occur, although on a quick investigation I did not find exactly why it refuses to load the section. On my side I'm using clang-3.8, latest iproute2, but also the latest kernel (some commit close to 4.14).
If you manage to load the section somehow, I believe you would still encounter problems when trying to attach the program in the kernel. The feature called “direct packet access” is only present on kernels 4.7 and higher. This is what makes you able to use skb->data and skb->data_end in your programs.
Then as a side note, this program sockmap_parse_prog.c is not meant to be used with tc. It is supposed to be attached directly to a socket (search for SOCKMAP_PARSE_PROG in file test_maps.c in the same directory to see how it is loaded there). Technically this does not prevent one to attach the program as a tc filter, but it will probably not work as expected. In particular, the value returned from the program will probably not have a meaning that tc classifier hook will understand.
So I would advise to try with a recent kernel, and to see if you have more success. Alternatively, try compiling and running the examples that you can find in your own kernel sources. Good luck!
I am trying to compile the kernel from downloaded source. I made the kernel image using sources from kernel.org.
I have successfully loaded it into grub, but when I try to run the loaded module it gives error message: "invalid magic number". I am not getting what I need to fix to get the things done.
Steps that I've followed:
make xconfig,
make bzImage
make modules
make modules_install
I also changed the name of image from bzImage (in /boot folder), then created initrd image from:
# dracut /boot/initramfs-3.1.6-1.fc16.x86_64.img 3.1.6-1.fc16.x86_64 (command copied from net)
Every time you compile a kernel, you must re-compile also the kernel module that you need to use within that kernel. For example, you cannot load a module compiled for kernel 2.6.39 on kernel 3.7. You must recompile it for kernel 3.7.
More details --> better answer
Actually I doubt this has anything to do with kernel modules. As it seems the kernel itself is being refered to as a module. It is possible the kernel got built incorrectly or is being loaded incorrectly possibly from the grub commandline.
http://forums.gentoo.org/viewtopic-t-932358-start-0.html try that.
It is possible that some file in the kernel build didn't get cleaned up properly an so has incorrect data in it since any changes you made in a previous attempt at building it.
Also do note that the x86 images will end up at arch/x86_64/boot/bzImage or arch/x86/boot/bzImage inside the kernel source make sure you actually have copied the kernel itself and not some other incorrect file.
If that fails try grub 1.x as its simpler to use than grub 2.x just note that alot of things are different and you should read tutorials for the correct version of grub. Often grub 1.x will be in a grub-legacy or similar package depending on the distro.
Edit: If you are building your kernel for your hardware only... do not use an initramfs its overkill. There are places you would want to do this is if your system is incapable of loading a kernel large enough for essential drivers (sparc for instance is very limited in kernel image size). another being booting over network possibly but by and large it isn't needed. If you must use an initramfs get your kernel build working without it first.
Also personally I build my kernel with essential drivers included (disk and filesystem basically) and build it with.
make mrproper (save/backup your .config first) ;
make menuconfig ;
make -j8 ;
make modules_install ;
cp arch/x86_64/boot/bzImage /boot/linux-3.7.1 ;
(modify grub to boot the new kernel) and im done and ready to reboot.
Any chance you could attach a screenshot of the failure?
I am not getting your question 100% clearly. Anyway, you downloaded some kernel tree from kernel.org and successfully booted with new Image.
Then you are trying to load a LKM i.e kernel module using insmod or modprobe.
so you are getting "Invalid magic number".
Solution
Need to re-compile the kernel module in new kernel, then try to insert.
Process Monitor and Explorer are supplied an EXE file.
But they include a driver. -Where is it.
By Windows Internals,
Process Monitor works by extracting a file system filter device driver from its executable
image (Procmon.exe) the first time you run it after a boot, installing the driver in memory, and then deleting the driver image from disk.
I would like to know the detail mechanism.
Are there some codes about that? Where can I find them.
Or could you explain me this.
Thanks.
Last time I looked it was just embedded into the executable as a resource. You can use something like Resource Hacker to see it. I guess when the process starts it extracts the driver from the resource section and installs it.
Executable file in Windows may contain among other things "resource" section. It may contain any binary data, which executable may access at run-time.
The trick is to put the whole other executable (the SYS file of the driver for instance) inside an EXE during the link time. Then at runtime the EXE extract this into a SYS file.
Then this driver may be loaded on-the-fly (using SC-manager)
I am currently trying to build an application, that will talk to the super IO chip using port IO. As part of that, I am trying to develop a kernel-mode windows driver that I can contact, and which will do the IO for me. I have therefore downloaded the Windows Driver Kit v7.1.0, build 7600.16385.1, and I am trying to compile and install the sample portio driver, which is provided by WDK, since it seems to be quite close to what I need.
I have compiled the driver in both free and checked x86 XP build environments. This works fine, but when I try to install the resulting driver, using the provided instructions - which basically just amount to using the Add Hardware Wizard, and then supplying the files manually - I get the following error:
-The following hardware was installed: Sample PortIO Driver (KMDF)
-The software for this device is now installed, but may not work correctly
-Windows cannot load the driver for this hardware. The driver may be corrupted or missing. (Code 39)
So, I see two explanations: corrupted or missing. Missing, as far as I can tell, given my environment variables and .inf file, would mean that the generated .sys file is not in c:\windows\system32\drivers, but when I look there, the file is there.
So that would mean that the file is corrupted. Given that I haven't touched the driver code, and that I have found others with the same problem, it doesn't seem to be a problem with my compilation, but rather with the code itself, or some common combination of machine type and code. But I may be wrong.
Does anybody have any suggestions on how to solve this?
I would recommend enabling SetupAPI logging as described in the following document from Microsoft:
http://www.microsoft.com/whdc/archive/setupapilog.mspx
For Windows 7, the log files are split up as described here:
http://support.microsoft.com/kb/927521
You may be able to isolate the problem with the additional information in the SetupAPI logs.
I installed openembedded and tried building a couple of images for Zaurus SL-6000 "Tosa", basically, helloworld-image and console-image. And I ended up with an angstrom-dev/deploy/glibc/images/tosa directory that contains files like this (slightly truncated from a forum post I made elsewhere):
Angstrom-helloworld-image-glibc-ipk-2009.X-test-20090529-tosa-installkit.tgz
Angstrom-helloworld-image-glibc-ipk-2009.X-test-20090529-tosa.rootfs.jffs2
Angstrom-helloworld-image-glibc-ipk-2009.X-test-20090529-tosa.rootfs.tar.bz2
Angstrom-helloworld-image-glibc-ipk-2009.X-test-20090529-tosa.rootfs.tar.gz
helloworld-image-tosa.tar.bz2
helloworld-image-tosa.tar.gz
initramfs-kexecboot-image-tosa.cpio.gz
initramfs-kexecboot-image-tosa.jffs2
initramfs-kexecboot-image-tosa.tar.bz2
initramfs-kexecboot-image-tosa.tar.gz
modules-2.6.29-r0-tosa.tgz
updater.sh.tosa
zImage-2.6.29-r0-tosa.bin
zImage-kexecboot-2.6.24-r0-tosa.bin
zImage-kexecboot-tosa.bin
zImage-tosa.bin
I have no idea what all these do or how to install them properly. What I did try is various combinations of flashing a zImage.bin and initrd.bin using option 4 of the maintenance menu (as specified per earlier instructions). The flashing usually works alright but then when it boots, it loads a bootloader that cannot find any bootable devices. On a hunch, I tried unpacking one of the tar.gz images to an ext2 formatted SD card and tried booting with that plugged in and it was detected by the bootloader. Booting it sort of worked but it quickly exited back to the bootloader (I assume that was just a problem with the image I unpacked).
My questions are:
What is the correct usage for all of these file types, i.e. should the .jffs2 files be renamed initrd.bin and included in the flashing process? What am I supposed to do with the bz2 and gz files? Are they only for unpacking to external media?
How do I install to the internal flash? It used to work with the stable Angstrom 2007-12 build and instructions.
Is there a newer version of updater.sh (that one was not built by oe and I added it myself having picked it up from elsewhere)? The reason I ask is that when trying to flash zImage-2.6.29-r0-tosa.bin it fails during the update program with the error that the file is too big. That kernel is approximately 1.3mb while the others are 1.2mb. Is this a constraint of the SL-6000 itself? I thought it has 32mb of internal memory.
Unfortunately, none of the available documentation that I could find online talks about installing these files. I did find a small entry in the "Angstrom Manual" which talks about what they are but not how to use them as they are all device specific. Unfortunately the tosa documentation only talks about copying the files from an installkit and flashing the device from the maintenance menu.
Okay, "ant" over at OE forums was able to answer my questions ^^ Just recording the answer here for posterity.
installkit-tosa.tar.gz, contains updater.sh and zImage (the kexecboot-kernel). This kexecboot-kernel can be and is likely different from the kernel you will have on the rootfs after the machine boots. Unpack the installkit on a formatted card and follow the flashing procedure for the device.
Regarding the also be various image-rootfs.tar.gz, .bz2, and .jffs2 files. These are the root file systems that will be be booted by kexecboot. The tar.gz or .bz2 archive should be unpacked onto an ext2 (or possibly ext3) formatted SD or CF card. It will be detected by kexecboot at boot time and appear in the kexecboot menu.
If you want a rootfs in nand (installed internally), rename your-image-rootfs.jffs2 to initrd.bin and copy it on the card with updater.sh (then flash).