[SOLVED] kernel panic on boot: unable to mount rootfs

[tsftd]

OK, so I was trying to set up bridging to get OpenVPN working (see https://forums.gentoo.org/viewtopic-p-7164404.html#7164404 for details), and suddenly the server won't boot (from my kernel). Using a netboot kernel works 100%.

I had literally just rebooted after "brctl addif br0 eth0" killed my connection, and tried:

in /etc/conf.d/net:
bridge_br0="eth0 tap0"
config_br0=( "[my server's ip] netmask 255.255.255.0" )
routes_br0=( "default gw [my server's default route]" )
config_eth0=( "null" )
rc_need_br0="net.eth0"
then add br0 link and start with /etc/init.d/net.br0

this also killed my connection. I attempted to reboot, and, unsurprisingly, it failed, so I went into rescue mode and undid those changes (reverted /etc/conf.d/net and removed the br0 link and rc-update entry). reboot again and... failure. I've now spent about 4 hours trying to fix this. I finally got a message from the hosting company that upon boot, it displays a kernel panic: "Unable to mount root fs on unknown-block(0,0) gentoo". being a good little monkey, I googled and discovered that this error is related to not being able to mount the root, likely due to lacking fs or controller support in the kernel. this surprised me, given that I had not done anything to either of those (or updated any programs) since the last reboot. nonetheless, I double checked my kernel settings (make menuconfig and searching .config for both controllers and fs support), remade the kernel, copied it to /boot/, re-did grub2 with "grub2-mkconfig -o /boot/grub2/grub.cfg" and "grub2-install --no-floppy /dev/sda", manually verified that the settings were correct, and rebooted. also, please note that I don't use any modules (in fact, module loading/unloading is disabled in the kernel), so it isn't an issue of the module being built but unloaded or needing it to be loaded prior to root.

same issue. surely the issue must lie with grub or the kernel since a netboot-supplied kernel works, but neither of them have changed in days, and i've rebooted multiple times since the last change. I have done no updates (haven't even synced), and have undone the only changes i made since the last successful reboot.

i'm at my wits' end, hopefully someone can help me straighten this out before i have to wipe it and start anew.

debugging information:
hdd is set up as /dev/sda1 (ext4): root, /dev/sda2 (xfs): /home/
old grub.cfg is here: http://pastebin.com/uyhvq0HH
new grub.cfg is here: http://pastebin.com/67TUZ3w3
lspci -k and fdisk -l are here: http://pastebin.com/EWJ3RFLh
kernel .config is here (version is 3.4.9, has never been updated): http://pastebin.com/mmiELLf0

[Thistled]

Hey tsftd

This partitioning looks weird to me.

Should

[tsftd]

i prefer to keep boot+root on the same partition, and I use no swap as the server doesn't even come close to maxing its ram.

[Thistled]

I'm still kind of learning Linux as I go along, and I thought /boot preferred to live on an ext2 partition.
_________________
Whatever you do, do it properly!

[_______0]

I don't know whether ur are booting with some virtual block device or what but you don't have disk support:

[_______0]

I don't know whether ur are booting with some virtual block device or what but you don't have disk support:

[Thistled]

I was going to point out this:

[tsftd]

yes, you're right -- you absolutely need SCSI Disk Support for SATA/PATA hdd's, USB hdd's -- just about any hard drives, really. I'm just confused how 1) it got turned off in my .config, when it's been enabled every time i've built kernels and I know not to remove it, and 2) the kernel which has worked perfectly fine for the last week or so, through multiple reboots, apparently got replaced by a new kernel which was compiled with this strange .config. and i also rolled back 1, 2, and 3 revisions of the kernel, which all had the same issue booting (and all had worked for long periods of time before). oh well, sometimes this stuff just happens i suppose.

either way, i'm recompiling now, but i'm fairly certain that was the problem and it will work now, so much appreciated. this falls into the category of things i wouldn't have thought to check (despite checking the actual hdd controller).

[Thistled]

Yay!
It looks like we have got to the bottom of the problem.
Sorry I didn't identify it sooner.
Although I must say I thought it was odd there was no SCSI set in the kernel config.
i just thought I needed it because I have an older motherboard.
_________________
Whatever you do, do it properly!