Since some time I seem not to be able to use gensplash anymore when compiling a new kernel. Even when using a tested kernelconfig, patch and patch method (patch -p1<$source). The only thing that I can think of that has changed is binutils-config. The most odd thing is that when I use a old kernel, like 2.6.12-rc6 it does work. Only removing the initrd boot option makes me able to boot the kernel. As far as I can remember nothing else trivial (like I know exactly what would be) is changed. Reproducible: Always Steps to Reproduce: 0. patch kernel to use fbsplash and vesafb-tng 1. build kernel 2. reboot Actual Results: Kernel output when removing the 'quiet' bootoption: Using IPI Shortcut mode VFS: Cannot open root device "hda3" of unknown-block(0,0) Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Expected Results: Booting with gensplash Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r0, 2.6.13-rc1 i686) ================================================================= System uname: 2.6.13-rc1 i686 AMD Athlon(tm) XP 1800+ Gentoo Base System version 1.6.12 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Apr 27 2005, 15:44:14)] dev-lang/python: 2.3.5 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.9.5, 1.5, 1.7.9-r1, 1.6.3, 1.4_p6, 1.8.5-r3 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.surfnet.nl/pub/os/Linux/distr/gentoo/ ftp://ftp.nluug.nl/pub/os/Linux/distr/gentoo/ gentoo.nedlinux.nl/" LANG="en_US.utf8" LC_ALL="en_US.utf8" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 3dnow X aalib acpi alsa avi berkdb bitmap-fonts cap cddb cdparanoia cdr cjk crypt cups curl directfb dvd dvdr dvdread emboss encode esd fam fbcon flac foomaticdb fortran gdbm gif gnome gpm gstreamer gtk gtk2 imagemagick imlib ipv6 java jpeg libg++ libwww mad mikmod mmx mmxext motif mozilla moznomail mp3 mpeg ncurses nls nptl nptlonly nvidia offensive ogg oggvorbis opengl pam pdflib perl png python quicktime readline samba sdl slang spell sse ssl svga tcpd tiff truetype truetype-fonts type1-fonts unicode vorbis win32codecs xine xml xml2 xmms xprint xv xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LDFLAGS, LINGUAS
what are your bootflags? did you omit ide support, or is it built in modular?
title=Gentoo GNU/Linux 2.6.13-rc1 kernel=(hd0,0)/kernel-2.6.13-rc1 root=/dev/hda3 video=vesafb:ywrap,mtrr splash=silent,theme:default quiet CONSOLE=/dev/tty1 initrd=(hd0,0)/initrd-1280x1024 The IDE support is compiled in. But as you can read above that does not matter, since the kernel only boots when I remove the 'initrd=' line.
hmmm, does the initrd image have the needed /dev/ entries. You can gunzip and loopback mount the image and check
Can you be more specific? Because if I mount the initrd image or the gunzipped image, the target stays empty; might be the idea. But that probably won't explain why a previous compiled kernel can boot with one. All the /dev entries that 'strings $gunzipped_initrd' comes up with do exist, if that is what you mean.
Has anyone got an idea what I can try out to see where the problem might be?
Since this is most likely a splashutils/fbsplash-related issue, I'll take it from here (reassigning from kernel@g.o to myself). Could you please try running with the 'quiet' option and in the silent mode. When your system stops booting, try switching to the first tty1 (press Ctrl+Alt+F1) and see whether there are any error messages there.
I have tested three situations: ------------------------------------ 1) in-kernel resolution config on "1280x1024@75". The kernel immediately changes to the silent TTY (black), without the standard second of kernelinfo, and shows the last line in the mentioned kernel panic message in the first post. 2) in-kernel resolution config on "1280x1024@70". The kernel just hits TTY1 (I think it did, don't want to test again; god it is hot in here). 1) and 2) kernel message on TTY1: Uncompressing Linux... Ok, booting the kernel. No 8bpp verbose picture specified in the config. Couldn't load font file Couldn't load 14pt font from (null) FBIOSPLASH_SETPIC failed, error code 22 Hint: are you calling 'setpic' for current virtual console? No 8bpp silent picture specified in the theme config Couldn't load font file Couldn't load 14pt font from (null) ------------------------------------ 3) This one is with a old kernel (2.6.12-rc6). Standard kernel and initrd info shows up, the errors below are shown and then the init kicks in. Couldn't load font file Couldn't load 14pt font from (null) Couldn't load font file Couldn't load 14pt font from (null) ------------------------------------ With the two 2.6.11.11 kernel builds I regenerated the initrd, just to be on the safe side; should not make a difference I think. The odd thing that I notice now is that with the latest test kernels I don't see the kernelinfo before the video/monitor changes modes.
As a possible workaround, please try using 1280x1024-16@70 or 1280x1024-32@70 as the in-kernel resolution.
Oke, that seems to work. So is there a small explination of what went instantly wrong after all that time? Anyway, thanks for taking a look and keep up the good work.
What went wrong? Well, the current version of splashutils has a bug, which causes it to segfault when it can't find 8bpp pics (and since you were running in a 8bpp mode, it required 8bpp pics). Apparently, for some strange reason, this segfault affects the kernel and prevents it from mounting the rootfs correctly. The workaround was using a different bit depth (-16, -32). The real fix will be included in the next version of splashutils -- it will no longer segfault :)
