Comment=
# 7
on bug 92858<=
/a>
from Darren D.
(In reply to Michel D=C3=A4nzer from comment #6)
> (In reply to Darren from comment #5)
> > Sadly, as of thus far, every kernel I've compiled panics at bootu=
p, with a
> > message like this, or similar: "kernel panic. vfs unable to =
mount root on
> > unknown block (0,0)".
>=20
> Sounds like there's a problem with the .config or maybe the root=3D[..=
.]
> parameter on the kernel command line. For .config, I'd recommend start=
ing
> with the original .config from 4.3-rc7 and then just running "make
> oldconfig".
>=20
>
And that helped--in a sense. It produced a kernel that would at least boot
partially instead of a kernel panic, but the boot froze on the distro splash
screen. It's progress, though! I edited grub.cfg (I've read not to do this,=
but
it was a temporary modification to test a theory) to use "nosplash&quo=
t; instead of
"splash" on the kernel command lin grub entry for the kernel I'd =
compiled, and
once I booted that kernal again, I noticied a 'could not locate modules:
template usr/lib/modules/$KERNELVERSION" type of error. Again, no way=
to
screenshot it as it was early in the boot process.
I'm guessing now I've discovered the problem: Renaming the
/usr/lib/modules/$KERNELVERSION directory to something different than what =
the
"make modules_install" command named it when it built the directo=
ry--and prior
to running the mkinitcpio command to build the initial ramdisk--is a bad id=
ea.
Live and learn.
I'm back on track now, and with any luck and free time between day job and
sleep, eventually I'll have a bootable kernel compiled soon so I can actual=
ly
start bisecting to locate the bad commit.