Re: [PLUG] Panic (kernel that is)

On Wed, Feb 20, 2013 at 10:15 AM, Rich Freeman <r-plug@thefreemanclan.net> wrote:

On Wed, Feb 20, 2013 at 8:57 AM, Eric Lucas <eric@lucii.org> wrote:
> When booting the system from that disk the kernel panics. It says:
>
> "No filesystem could mount root, tried: ext3 ext2 vfat msdos iso9660 udf
> xfs"
>
> The system has the usual /dev/sda and /dev/sdb with all the partitions of
> type Linux raid autodetect.
> At first I thought it was a problem with the kernel detecting the RAID
> drives but now I'm thinking it's having trouble accessing the ram disk.
> That's because on the iso in the isolinux.cfg file there is this:
>
> label expert
> kernel /vmlinuz
> append initrd=/initrd.img root=/dev/ram0 rw ramdisk_size=151552
> expert devfs=nomount noresume selinux=0 barrier=off udevtimeout=10
>
> Ah ha! root is /dev/ram0
> So how do I tell if a kernel has built-in support for ramdisk?

I don't think it is possible to build a kernel which doesn't have
support for a ramfs. Note that this is the old-style initrd syntax
which you might not be as familiar with.

When you boot with an initrd or initramfs the ram disk is the initial
root filesystem. Newer kernels using an initramfs ignore the root=
parameter, and so most modern distro versions just point root= at your
final root filesystem. The kernel ignores this and mounts the
initramfs as root, and then a script in the initramfs reads the root=
parameter and mounts that as the new root.

Older-style syntax (which, btw, is used by Gentoo with the default
genkernel initramfs but not with the newer dracut initramfs) was to
set root=/dev/ram0 which is where the initrd got mounted and then use
some other parameter to communicate to the initrd where to find the
real root filesystem (Gentoo genkernel uses real_root= for this).

Since there is no other root device mentioned on the config line there
is either some error in setting up grub, or the initrd has some other
logic for finding your root filesystem (it could just be hard-coded in
the initrd).

So, now let's try to parse your error. Something is triggering a
panic because root couldn't be found. I don't know if an initrd can
trigger a panic when it tries to pivot to a new root (maybe it can).
If not, then perhaps the kernel can't load the initrd in the first
place. The initrd has to be a filesystem image readable by the kernel
- usually squashfs (but the kernel has to support squashfs for that to
work), and of course the path to the initrd has to be right. An
initramfs is in cpio format, but it doesn't seem likely that you're
using the newer initramfs format.

Try running file on the /initrd.img file and see what it outputs. It
should identify what kind of format it is in. Then make sure your
kernel has BUILT-IN support for that filesystem. You can compile
support for your real root filesystem as a module, but the filesystem
used by the initrd has to be built-in, as the modules are stored
inside that.

I'm not very familiar with Mondo in particular - everything above is
just based on how the linux boot process works in general. Some of
the specifics will vary if you're talking about initramfs vs initrd.
Also, once that initrd is mounted as root it can do anything it wants
to - it doesn't even have to mount some other device as a new root
even if that is how most distros use an initrd/initramfs. All the
kernel does is mount the initrd/initramfs on a root device, find init
on that device, and runs it. Everything else after that is all
userspace (init could be anything - it doesn't have to be sysvinit and
it often is just a bash script).

Rich

That's great info Rich.

I extracted the initrd as you describe and I see it's a small file system Cool.

What I don't see is a file called init. There is a soft link for init that points to sbin/init but that's broken - the target does not exist. So how does it know what to do?

Based on the messages I see on the frozen screen the problem is with trying to mount the RAID drives. There are a lot of messages that go by before the panic and I have to believe that it must be running from the ram disk at that point. Even so, this system should continue to run out of the ram disk - it's a rescue disk after all. In my normal scenario I expect there to be two blank hard drives in there.

Still investigating...

Thanks,

Eric