Kernel panic - not syncing: No init found.

[wstupar]

Can someone tell me what it means, "unable to open an initial console"?
This is what I get when trying to boot up the Sheeva Plug:

EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem) on device 8:2.
Freeing init memory: 140K
Warning: unable to open an initial console.
Kernel panic - not syncing: No init found.  Try passing init= option to kernel.

Wes

[da1l6]

Hello

Assuming that you just copied your root FS to another device you propably forgot to create the basic dev nodes on it. in /dev you need at least these files, to get it booting until udev is loaded

Code:

crw------- 1 root root 5, 1 22. Jul 12:12 /dev/console
crw-rw-rw- 1 root root 1, 3  7. Jun 13:32 /dev/null
crw-rw-rw- 1 root root 1, 5  7. Jun 13:32 /dev/zero

you can create these dev nodes on another linux box with

Code:

mknod /dev/console c 5 1
mknod /dev/null c 1 3
mknod /dev/zero c 1 5

da1l6

[wstupar]

Hi, da1l6,

Thanks for the tip. Actually, I had no file system at all. I am booting from USB memory stick only, and I have a /dev/sda1, FAT16 (type 0xe), with uImage, and /dev/sda2, NTFS (type 0x86). Probably nobody else would be so ignorant, but I'll tell my problem just in case.

The uImage, of course is a single, binary file and shows up as such when you mount it on a separate Linux system. I also found in the distributed material a file called "rootfs", which I copied to the /dev/sda2. This was not recognized by the kernel as a file system.

In the installer package there is a rootfs.tar.gz that contains a suitable file system. I copied it to the /dev/sda2 and un-tared it there, then removed the tar source. Now I boot up to the Linux prompt.

Wes

[restamp]

First, congratulations on resolving your problem.

A couple comments:  I suspect that "/dev/sda2, NTFS (type 0x86)" describes how this particular partition is labeled, not its contents.  I believe the Linux kernel does not depend on the label info, but uses its own heuristics to determine, if it can, the type of file system that is on a partition, although for some less common FSs, (jffs2?) you still have to specify the FStype explicitly.  I have mounted NTFS filesystems under the alpha-6 installed OS (kernel 2.6.30-rc6), but it wouldn't surprise me to learn that the kernel would not support this FS type for its root FS, as I believe the ntfs-3g software requires some user level assists, at least for RW mounts.  (If someone knows definitively, let us know.)  Not sure what your rootfs file contained, but rootfs.tar.gz is what you need to populate the root FS, as you have already figured out.