I have a problem and have hade with all gentoo-dev-soruces-2.6.10: the splash does not work like it should. It does not enter silent-mode until gentoo remounts the root-partition, and then it does not splash the verbose-part until the script /etc/init.d/splash tells it to. This is true when I uses genkernel to compile my kernel and uses the initrd generated by genkernel (genkernel all --install --udev --gensplash=emergence). But if I use a initrd created with splash_geninitramfs then my framebuffert is splashed from the point vesafb-ng changes my resolution. It did work like intended using genkernel with previous versions of gentoo-dev-sources (2.6.9 and below). genkernel-3.1.0c gentoo-dev-sources-2.6.10-r4 (since bare 2.6.10) splashutils-0.9_pre10
Two things that you might want to do first: upgrade to genkernel-3.1.0d, and splashutils-0.9_rc1. Once you have done that, try to compile the kernel again. If that doesn't help, check the size of usr/initramfs_data.cpio.gz in your kernel tree. If it's >1MB, then everything is OK. If it's small, no more than a few KBs, then the initramfs image with the theme is not getting compiled into the kernel. Also, make sure that you are using the correct video option for vesafb-tng (it's, for examaple, video=vesafb:1024x756-32@85, not video=vesafb-tng:adfadfadd). If you still can't find anything wrong with your config, post your full kernel command line parameters and the output of `fbset -i`.
I have the exact same problem and I do have genkernel-3.1.0d, and splashutils-0.9_rc1. The size of size of usr/initramfs_data.cpio.gz starts out > 1MB then gets much smaller later in the compile process.
usr # du -h initramfs_data.cpio.gz 4,0K initramfs_data.cpio.gz --- / # fbset -i mode "1280x1024-60" # D: 108.003 MHz, H: 63.983 kHz, V: 60.021 Hz geometry 1280 1024 1280 2048 32 timings 9259 248 48 38 1 112 3 hsync high vsync high rgba 8/16,8/8,8/0,8/24 endmode Frame buffer device information: Name : VESA VGA Address : 0xe0000000 Size : 10485760 Type : PACKED PIXELS Visual : TRUECOLOR XPanStep : 0 YPanStep : 1 YWrapStep : 1 LineLength : 5120 Accelerator : No --- /boot/grub/grub.conf: kernel /kernel-2.6.10-gentoo-r4 ro root=/dev/ram0 udev real_root=/dev/hdb2 init=/linuxrc video=vesafb:ywrap,mtrr,1280x1024-32@60 splash=silent
1) splash=silent is generally discouraged, if you're using the 'emergence' theme, this should be splash=silent,theme:emergence 2) initramfs_data.cpio.gz is far too small, so it is probably being overwritten by the kbuild system. Everyone with small initramfs_data.cpio.gz, please make sure you have unset 'Source directory of cpio_list' in 'Block devices' (CONFIG_INITRAMFS_SOURCE).
1) I had splash=silent,theme:emergence from the beginning (actually I had an home-made theme), but I removed it to be able to switch between themes with genkernel without having to edit grub.conf everytime while errorchecking this and it did no diffrense. 2) So how is that line supposed to look like? kernels # grep CONFIG_INITRAMFS_SOURCE * kernel-config-x86-2.6.10-gentoo-r4:CONFIG_INITRAMFS_SOURCE=""
I have the exact same problem with 2.6.10 kernels. I have tried both genkernel 3.1.0c and 3.1.0d and I get the same result. du -h /usr/src/linux-2.6.10-gentoo-r5/usr/initramfs_data.cpio.gz 4.0K /usr/src/linux-2.6.10-gentoo-r5/usr/initramfs_data.cpio.gz From my config file: CONFIG_INITRAMFS_SOURCE="" Should it be like this or should it be: CONFIG_INITRAMFS_SOURCE= Other ideas?
CONFIG_INITRAMFS_SOURCE="" is OK. I've got no further ideas for now, sorry :) Perhaps the genkernel maintainer would be able to shed some light on what could be causing the problems.
Have anyone compiling their own kernel experience this? Or what does genkernel do between they make their version of initramfs_data.cpio and the start of the compiling of the kernel? This is why I wounder: I removed the initramfs_data.cpio.gz and made a new one according to the HOWTO@gentoo-wiki and it ended up aorund 350K. running "genkernel all --install --udev --gensplash=MyTheme" removed this file and initramfs_data.cpio during "Running mrproper". Then the file initramfs_data.cpio returned in the size of 1.1M (the bigger size I think depends on me only generating the .gz with one resolution but genkernel does with them all) but became 4.0 along with initramfs_data.cpio.gz as soon as the kernel started to "Compile" (according to the stdout). So why does it seems to me like the customized initramfs_data.cpio becomes somehow removed during compiling with the 2.6.10-kernels but not with the ones before (e.g. 2.6.9)?
Well I couth some time now and it shows the following for me My comments are all inside of the (): lillen linux # make mrproper lillen linux # ls usr/ gen_init_cpio.c initramfs_data.S Makefile (so the file did "disappere") lillen linux # splash_geninitramfs -v -g /usr/src/linux/usr/initramfs_data.cpio.gz -r 1280x1024 FrozenBubble o Creating directory structure.. o Copying /sbin/splash_helper.. o Copying themes.. - FrozenBubble o Creating initramfs image.. lillen linux # du -h usr/initramfs_data.cpio.gz 328K usr/initramfs_data.cpio.gz (just like it should be) lillen linux # make gconfig (just to scheck and it did not change anything with the initramfs_data*) lillen linux # make ---cutted output--- HOSTCC usr/gen_init_cpio CHK usr/initramfs_list UPD usr/initramfs_list CPIO usr/initramfs_data.cpio GZIP usr/initramfs_data.cpio.gz AS usr/initramfs_data.o ---cutted output--- lillen linux # du -h usr/initramfs_data.cpio.gz 4,0K usr/initramfs_data.cpio.gz (during this my personalized initramfs_data.cpio.gz got replaced with something that is only 4.0K) I am about to try this kernel, but I have a strong feeling this would not work better then the genkernel-thing. What do you get of this? Anyway I can give more help?
Sorry for bouncing alot right now.... From the Changelog@kernel.org: --- <tharbaugh@lnxi.com> [PATCH] gen_init_cpio uses external file list This patch makes gen_init_cpio generate the initramfs_data.cpio from a file which contains a list of entries: file, dir, nod. I swapped the order of filename/location for the file arguments so that it would be more uniform with the dir and node tyes. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> --- It seems to be alot of patches about this cpio-list. Maybe that made this screw up? Right now I am emerging development-sources-2.6.10-r1 only for testing-purposes... Going to look at its handling of the cpio.gz-file (i.e. if the vanilla flavour roemovs the "hand-made" cpio.gz replacing with its own both with and without vesafb-tng and fbsplash patches) and becouse I don't know a thing about sources or anything more then how to configure it is going to be a experience and hopefully I will learn something to. If you like to know anything from my results or want me to test something specific just bounce you too...:-)
Ok, I have tracked down the origin of the problem: scripts/gen_initramfs_list.sh usr/Makefile usr/gen_init_cpio It seems like this is some files that have had some changes since 2.6.9 and their inpackt on the usr/initramfs_data.cpio.gz seems to rather drastical. If I read the usr/Makefile right it will make this file from scratch every time you hit "make" in the root of the kernel source directory. With files to be included decides by a list made up by scripts/gen_initramfs_list.sh and/or the kernel-option CONFIG_INITRAMFS_SOURCE. From this list then usr/gen_init_cpio generates the file usr/initramfs_data.cpio.gz during compiletime. The only workaround I could find was to make my own list for the kernel-option (how that file should look like is inside of the source usr/gen_init_cpio.c). I must say this things with the lists seems rather new, untested and undocumented so far and I have not found yet any other way to make the splash-things become placed inside of usr/initramfs_data.cpio.gz. By the way usr/gen_init_cpio plays with a list named usr/initramfs_list but this file becomes replaced during make by the scripts/gen_initramfs_list.sh so that does not seems to be a working approach... This is at least a quick workaround and maybe a direction for where to look for a fix. As said: I don't know much about this things, so...
The bug exists in 2.6.9 too - genkernel simply applies a sed on the Makefile and that fixes it. The sed no longer applies for 2.6.10 due to the cpio_list changes and hence things fail to work - so we just need to update it and things would work again...
Should be fixed in 3.1.0e; please reopen this bug if the problem still persists. Thanks!