I followed the Handbook instructions for installing Gentoo 2004.0 and configuring the GRUB bootloader using Code Listing 5: -------------- Code Listing 5: grub.conf for non-genkernel users # Which listing to boot as default. 0 is the first, 1 the second etc. default 0 # How many seconds to wait before the default listing is booted. timeout 30 # Nice, fat splash-image to spice things up :) splashimage=(hd0,0)/grub/splash.xpm.gz title=Gentoo Linux 2.4.24 # Partition where the kernel image (or operating system) is located root (hd0,0) kernel /kernel-2.4.24 root=/dev/hda3 # The next three lines are only if you dualboot with a Windows system. # In this case, Windows is hosted on /dev/hda6. title=Windows XP root (hd0,5) chainloader +1 ------------- The problem was with the following line: kernel /kernel-2.4.24 root=/dev/hda3 I modified the line to point to my ReiserFS root partition on /dev/hda7: kernel /kernel-2.4.24 root=/dev/hda7 and was unable to boot correctly until I changed the line to remove the "root=/dev/hda7" parameter entirely. After removing the parameter, I was able to boot perfectly normally. Reproducible: Always Steps to Reproduce: 1. Follow the GRUB configuration instructions in Code listing 5 of http://www.gentoo.org/doc/en/handbook/handbook.xml?part=1&chap=9#doc_chap2 2. Adjust the kernel root parameter to point to my real root. 3. Reboot. Actual Results: After loading the kernel, I received the following kernel panic following the loading of the kernel, just at the point when the kernel would normally mount the root partition: <some error about being unable to find a ReiserFS partition> VFS: unable to mount root partition at 03:05 Before you ask, yes, ReiserFS was compiled into my kernel and I had emerged the reiserfstools before rebooting. Expected Results: The kernel should have found the root partition, mounted it, and continued booting. This is the only machine on which I have installed Gentoo successfully, so I don't know whether this is a problem with the kernel root parameter and vanilla-sources-2.4.25, with ReiserFS, or a hardware issue -- but it's worth noting that a search on VFS: kernel panic turns up many cases where this might be the real issue but nobody has suggested simply removing the root=/dev/XXXX parameter. Argh. Posting from Windows at the moment (still working on configuring my wireless LAN). I'll try to add this as a comment or attachment later today.
emerge info: Portage 2.0.50-r1 (default-x86-2004.0, gcc-3.3.2, glibc-2.3.2-r9, 2.4.25) ================================================================= System uname: 2.4.25 i686 Intel(R) Pentium(R) III Mobile CPU 800MHz Gentoo Base System version 1.4.3.13 Autoconf: sys-devel/autoconf-2.58-r1 Automake: sys-devel/automake-1.7.7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium3 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium3 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://adelie.polymtl.ca/ ftp://mirrors.tds.net/gentoo ftp://ftp.ussg.iu.edu/pub/linux/gentoo http://gentoo.mirrors.pair.com/ ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X alsa apm arts avi berkdb crypt cups dvd encode esd foomaticdb gdbm gif gnome gpm gtk gtk2 imlib java jpeg kde ldap libg++ libwww mad mikmod motif mpeg mysql ncurses nls oggvorbis opengl oss pam pdflib perl png python qt quicktime readline sdl slang spell ssl svga tcltk tcpd truetype x86 xml2 xmms xv zlib"
I have a somewhat similar setup: /dev/hda1 = WinXP Partition /dev/hda2 = /boot (ext2) /dev/hda3 = swap /dev/hda4 = / (reiserfs) I did my grub file from the old school method: == title=Gentoo GNU/Linux [love-sources-2.6.4-r2] root (hd0,1) kernel (hd0,1)/kernel-love root=/dev/hda4 == I created a config set as follows: === title=Test kernel line root (hd0,1) kernel /kernel-love root=/dev/hda4 === The system booted fine. I removed the "root=" part from the kernel statement and it still booted successfully. When I was running under vmware, I had some problems getting the SCSI drivers to play nice with the drive. At a certain point, it'd die with a kernel load error. I fixed it by tweaking the grub.conf about a dozen times until it started. I don't have a fix or a diagnosis for the problem. I'm just including my comment that the document stated method works for me.
You can always leave out the root (...) line, but then the /boot partition doesn't get checked by grub. Does rootnoverify (...) work?
From what I understand, rootnoverify wouldn't affect the Linux root (/) partition because Grub isn't responsible for mounting it; Grub just has to mount /boot, and since that's an ext2 partition that shouldn't be an issue for Grub. But I'll give it a shot and see what happens.
Hmm. How about I eat a little bit of humble pie... My ReiserFS partition is actually on /dev/hda8, not /dev/hda7, so I had the wrong root= parameter. So, major duh for me. However, if the root= parameter actually isn't necessary in most cases, doesn't it make sense to remove that parameter from the default case and remove one more potential for error? We could then add "If your system experiences difficulty loading the root partition, add the root= parameter to the kernel line of your Grub configuration file." to take care of the non-standard cases. http://www.ibiblio.org/mdw/HOWTO/BootPrompt-HOWTO-3.html says of the root= parameter: <begin> This argument tells the kernel what device is to be used as the root filesystem while booting. The default of this setting is the value of the root device of the system that the kernel was built on. For example, if the kernel in question was built on a system that used `/dev/hda1' as the root partition, then the default root device would be `/dev/hda1'. To override this default value, and select the second floppy drive as the root device, one would use `root=/dev/fd1'. </end> Given that most kernels built during install will be built on the same partition as the root partition, we could even qualify the advice for using the root= parameter to only require it for installations that have not followed the default partitioning scheme.
It does have the disadvantage that it enlarges the instructions once more, while the current situation is just working fine (even though it has some redundancy :)
Okay, it's good (and common) practice to add a root= line to the kernel. I'm marking this as WONTFIX.
