building the kernel 2.6.29-r2 with the .config file of the 2.6.29-r1 one should boot without errors, because it's not a real kernel update, but just a revision. Reproducible: Always Steps to Reproduce: 1.copy .config from gentoo-sources-2.6.29-r1 to gentoo-sources-2.6.29-r2 2.build the new gentoo-sources-2.6.29-r2 3.Put it in place ans try to boot Actual Results: kernel doesn't boot, it stop just after the grub menu: the screen is all black, with just a blinking cursor Expected Results: the new kernel should boot without problem.
Created attachment 189973 [details] My .config file This my .config file used with gentoo-sources-2.6.29-r1 which should work for gentoo-sources-2.6.29-r2
did you use 'make oldconfig' after you copied the old config file to the new sources?
Same problem here, there is a post about this on the forums and apparently it seems to have something to do with the initrd because if you disable it on your grub boot entry, the kernel will boot.
I was the one, who created the forum post, and if I might add to this bug one extra bit of information: If you boot with splash option set to verbose you get exactly one line before the system stops booting. This line is "console: switching to colour frame buffer device 128x64".
(In reply to comment #2) > did you use 'make oldconfig' after you copied the old config file to the new > sources? > Yes, I did it. ------------------- Thanks for pointing out the problem cames from the initrd file: I have solved the problem by simply rebuilding my initrd file: "splash_geninitramfs -g /boot/fbsplash-livecd-2007.0-1280x800 -r 1280x800 -v livecd-2007.0" Best regards.
Florian GYS, I am not sure what exactly you did to fix it. I used genkernel and issued genkernel --menuconfig --install --splash=natural_gentoo all. It didn't work!!
(In reply to comment #6) > Florian GYS, I am not sure what exactly you did to fix it. I used genkernel > and issued genkernel --menuconfig --install --splash=natural_gentoo all. It > didn't work!! > Sorry to hear that: But I have never used the genkernel method, so don't really know how to help you. In fact, I have just issued this command: "splash_geninitramfs -g /boot/fbsplash-livecd-2007.0-1280x800 -r 1280x800 -v livecd-2007.0" which only rebuild the initrd file. Looking at the genkernel method, the command "genkernel --no-clean --splash=NAME initrd" should be enough. However, perhaps some more glitches have been introduced with these kernel revision so I don't know if my method is valid for all of us. It is quiet strange to have these initrd problems, because gentoo-sources-2.6.29-r2 should only add some ext4 tweaks to the -r1 revision. Do you use uvesafb, like me? Best regards.
I have the same problem. It's fixed after I turn off fbcondecor in kernel.I think it may be about fbcondecor patch.
Can you boot successfully with fbcondecor enabled in the kernel, but with `splash=off` on the kernel command line?
*** Bug 268062 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > Can you boot successfully with fbcondecor enabled in the kernel, but with > `splash=off` on the kernel command line? > I have done what you say, the problem is still there.
(In reply to comment #11) > (In reply to comment #9) > > Can you boot successfully with fbcondecor enabled in the kernel, but with > > `splash=off` on the kernel command line? > > > > I have done what you say, the problem is still there. > I have the same issue. I use Genkernel also, but I attempted to manually recreate the initrd, and still no luck.
Check this forum post and the following entries: http://forums.gentoo.org/viewtopic-p-5697437-highlight-.html#5697437 Don't know if the solution works or not, but two others claim it does. I'll be trying it later today.
Replacing 2.6.29.2 fbmem.c with 2.6.29.1 fbmem.c and recompiling solves the issue. IMHO, this is an upstream kernel bug. cp -a /usr/src/linux-2.6.29-r1/drivers/video/fbmem.c /usr/src/linux-2.6.29-r2/drivers/video/fbmem.c Probably more elegant if a patch was made and used to install future 2.6.29-gentoo-sources-r2 ebuilds.
Same here. Copying fbmem.c from 2.6.29-gentoo-r1 solved it.
I have just released a fixed version of the fbcondecor patch: http://dev.gentoo.org/~spock/projects/fbcondecor/archive/fbcondecor-0.9.6-2.6.29.2.patch The whole problem was caused by a series of mutex-related fbdev fixes that are included in 2.6.29.2. The changes in the locking mechanism cause a deadlock when the 0.9.6-2.6.29 fbcondecor patch is used.
Thanks, Spock. I put this in svn and released a new genpatches. We should have a new gentoo-sources today which will include this patch.
Released in gentoo-sources-2.6.29-r3
