According to "genkernel --help" adding an --initramfs is supposed to: "Builds initramfs before kernel and embeds it into the kernel." What seems to really happen is genkernel builds an _initrd_ in the form of an initramfs. What is the difference you ask? An initrd has to be loaded by your bootloader ( grub in most cases ). In the 2.6 series of kernels, the initrd can be either a file with a filesystem on it ( usually ext2 ) or a set of cpio archives. The later is what genkernel does. It compiles all the pieces of the initrd, snarfs them up as gzipped cpio archives and then joins them all together. An initramfs is actually a cpio archive jammed onto the end of the kernel image itself. This means no extra line in grub. There are also some differences in the name of the first program executed. In an initrd, it is linuxrc. While using initramfs it is actually init. genkernel already seems to account for this. I would like to know if initramfs in an initrd is the expected behavior? If it is, how open are you guys to a patch that actually creates an initramfs? If it is not, then what am I doing wrong in my genkernel commandline: genkernel --debuglevel=4 \ --debugfile=/var/tmp/genkernel.log \ --no-color \ --no-menuconfig \ --no-save-config \ --mrproper \ --no-bootsplash \ --no-gensplash \ --no-install \ --initramfs \ --kerneldir=/usr/src/linux-2.6.17.1 \ --kernel-config=/etc/kernels/kernel-config-pentium4-pxe-2.6.17.1 --no-mountboot \ --lvm2 \ --dmraid \ --disklabel \ all Thanks.
(In reply to comment #0) > An initrd has to be loaded by your bootloader ( grub in most cases ). In the > 2.6 series of kernels, the initrd can be either a file with a filesystem on it > ( usually ext2 ) or a set of cpio archives. The later is what genkernel does. > It compiles all the pieces of the initrd, snarfs them up as gzipped cpio > archives and then joins them all together. Correct; and we call this an initramfs... because there's nothing stopping you from taking the resultant .cpio.gz and jamming that onto a kernel image. > An initramfs is actually a cpio archive jammed onto the end of the kernel image > itself. This means no extra line in grub. There are also some differences in > the name of the first program executed. In an initrd, it is linuxrc. While > using initramfs it is actually init. genkernel already seems to account for > this. ... and this is basically where we jam it into the kernel for you; in either case, if the destination kernel is 2.6 the flavour is an initramfs (i.e. cpio style, not loopback style); the difference between having the flag and not is whether it ends up getting stuffed into your kernel image or not. > I would like to know if initramfs in an initrd is the expected behavior? If it > is, how open are you guys to a patch that actually creates an initramfs? If it > is not, then what am I doing wrong in my genkernel commandline: You mean something that stuffs it onto the kernel? That's what --initramfs should exactly do...
> You mean something that stuffs it onto the kernel? That's what --initramfs > should exactly do... Thats my point. Adding --initramfs does not jam the cpio archive onto the tail end of the kernel that is built even if it is a v2.6 kernel.
(In reply to comment #2) > > You mean something that stuffs it onto the kernel? That's what --initramfs > > should exactly do... > > Thats my point. Adding --initramfs does not jam the cpio archive onto the tail > end of the kernel that is built even if it is a v2.6 kernel. Try with genkernel-3.4.0_pre3; if it still doesn't do what it claims it should <TM> then it's a bug and we need to fix that :)
(In reply to comment #3) > Try with genkernel-3.4.0_pre3; if it still doesn't do what it claims it should > <TM> then it's a bug and we need to fix that :) Try with 3.4.0 now that it's out, reopen bug if issues persist. Thanks.
(In reply to comment #4) > (In reply to comment #3) > > Try with genkernel-3.4.0_pre3; if it still doesn't do what it claims it should > > <TM> then it's a bug and we need to fix that :) > > Try with 3.4.0 now that it's out, reopen bug if issues persist. Thanks. > I have now tryed with genkernel 3.4.0-r1 pixie genkernel # genkernel --version 3.4.0 pixie genkernel # emerge -pv genkernel These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-kernel/genkernel-3.4.0-r1 USE="-ibm" 0 kB with the following cmdline: genkernel --debuglevel=5 --debugfile=/var/tmp/genkernel.log --no-color --no-save-config --clean --mrproper --no-gensplash --no-install --no-devfs --initramfs --kerneldir=/usr/src/linux-2.6.17.6 --kernel-config=/etc/kernels/kernel-config-pentium4-pxe-2.6.17.6 --no-mountboot --lvm2 --slowusb --disklabel --kernname=test-pentium4-pxe --kerncache=/var/tmp/genkernel/test-kerncache-pentium4-pxe-2.6.17.6.tar.bz2 --initramfs-overlay=/var/tmp/genkernel/local-initramfs-overlay --linuxrc=/usr/share/genkernel/pxe-x86/linuxrc all Here are the things that it generated: pixie genkernel # du -sk *test* initramfs-2.6.17.6 881 System.map-test-pentium4-pxe-x86-2.6.17.6 1898 kernel-test-pentium4-pxe-x86-2.6.17.6 5521 test-kerncache-pentium4-pxe-2.6.17.6.tar.bz2 2783 initramfs-2.6.17.6 As you can see the initramfs is about 2.7M while the kernel is 1.9Mb. I don't think the initramfs is being jammed onto the end of the kernel. Is this the behavior that is expected?
My apologies on this sitting for so long. To answer your question, no. The initramfs is supposed to be appended to the kernel, just as you expect that it should.
There are a few problems with doing this. If you build the initramfs first and then modify the kconfig to point to it, so that it's includes in the built kernel, you can't put kernel modules in the initramfs (not without building the kernel twice). If you build the initramfs afterward, you have to modify the ELF headers of the resulting kernel binary, since the initramfs is appended to the DATA section of the binary (I believe). Both of these solutions are problematic. For what the OP wanted to do, you don't really want/need a combined image, anyway. PXE only supports loading up to a 1MB kernel (iirc), which isn't enough for even the kernel itself. That's why we use PXE loaders such as pxelinux and grub's PXE loader. AFAIK, both of these have the ability to load an initramfs separate (I know pxelinux does, because I do it regularly).
(In reply to comment #7) > If you build the initramfs first and then modify the kconfig to point to it, so > that it's includes in the built kernel, you can't put kernel modules in the > initramfs (not without building the kernel twice). Why? Would the modules not work just fine if CONFIG_MODVERSIONS is set? Is there something else causing an issue?
The problem is that the initramfs is built before the kernel (and the modules), so it's not physically (or chronologically) possible to include the modules built with the kernel in the initramfs. You can get around this with a bit of a kludge, though. First, you build the kernel and the modules. Then build the initramfs and include whatever modules you need. Then build the kernel a second time after modifying the kconfig to automatically include the initramfs, which contains the modules from the first run. The second kernel compile run shouldn't take very long, since you wouldn't have switched compilers and will still have all the .o files.
I must be missing something here. Why not build the modules first, then the kernel, with the same .config the whole way? It is exactly what we do on --genzimage and it was how I had thought that this worked, but I haven't looked at the code recently and could be wrong.
This is no longer an issue. I've just removed the --initramfs option in genkernel, and it's been replaced with the --integrated-initramfs option, which does what you expected --initramfs to do.
OK. This is resolved in genkernel 3.4.10, which is now in the tree and stable.
