RFS fails at Kernel panic - not syncing: No init found. Try passing init= option to kernel.

[Rob Landley]

On Wednesday 04 November 2009 04:54:24 Vineeth wrote:
> Hi,
>
> We are porting linux 2.6.30 to a custom board with PPC440x5 processor.
>
> Specifications of our board:
>
> Processor : ppc440x5
> Memory    : SRAM 16MB
>
> We made our root file system using busybox-1.15.2.and trying to make a
> ramdisk .

Busybox should work fine, and I know this because 
http://impactlinux.com/code/firmware/downloads/binaries/ has a powerpc-440fp 
compiler, root filesystem, and system image.  (Note a new release is coming in 
the next day or two, so those binaries are going away to be replaced by new 
ones.)

> The kernel execution went well till it mount the RFS.After that it
> hangs with an error "Kernel panic - not syncing: No init found.  Try
> passing init= option to kernel.".

For a ramdisk or ramfs you need "rdinit=" instead.  The "init=" value is only 
used for the "skip or return from ramdisk, mount final root device" logic.

> we tried giving init=/sbin/init as
> bootarg which caused "Failed to execute /sbin/init.  Attempting
> defaults..."

Your ramdisk isn't triggering at all, it seems.

> i am attaching the boot log below. please let us know if
> we are missing smthing here. our ramdisk.image.gz was about 1.8Mb and
> the after extraction comes around 5Mb.

Feed in a statically linked hello world as your init program, and see if it 
prints out "hello world".  If that works, try dynamically linked hello world, 
and only _then_ worry about your init.

This is not a busybox issue, this is a system imaging issue.  I need to write 
up documentation for this someday.  I did a rambling and incoherent 
presentation about this at OLS back in 2006, which is still online at 
http://busybox.net/~landley/ols2006/ (presentation.txt is my "slides" and 
busybox-initramfs.mov is video of the talk).

Mark and I also did a long presentation about this sort of thing at Ohio 
LinuxFest last month, the PDF of which is at 
http://impactlinux.com/presentations.html (the system image troubleshooting 
advice starts on page 163, and I you can dig up the audio of the hideously 
rushed hour-long talk if you're that bored).

> Does it cause the issue , that
> we dont have enough memory to execute the RFS ?

RFS?  Too many TLAs.

> Is there any way to minimize the size of the RFS generated by the busybox ?

Busybox doesn't generate a root filesystem, let alone package it into a system 
image.  What _are_ you using to generate your system image?  (Personally I use 
Firmware Linux, the system image generator I wrote from scratch, but then I'm 
obviously biased there.)

The easy way to minimize the size of your system image is to use uClibc 
instead of glibc, and possibly to statically link busybox against uClibc.  If 
you look in the root-filesystem-powerpc-440fp.tar.bz2 linked above, it's got a 
ppc440 version of busybox dynamically linked against uClibc.  (If you wait 
until the next release in a day or two, I've switched to building busybox 
statically by default because it improves autoconf's speed under uClibc by 
about 20%.)

Doing that you should be able to get it down under 2 megs uncompressed, 
without even fiddling with the busybox or uClibc configs to strip out unneeded 
features.

> Boot log
> --------------------------------------------------
>
>
> Bootloader :Initialized the System
> Bootloader :Initialized the UART
> Bootloader :Copying Linux Image to RAM >
> Bootloader :!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> Bootloader :Copying Image Done
> Bootloader : Done - LINUX Entry
>
> zImage starting: loaded at 0x00400000 (sp: 0x006a3eb0)
> Allocating 0x1e4e40 bytes for kernel ...
> gunzipping (0x00000000 <- 0x0040c000:0x004dfed3)...done 0x1cd1cc bytes
> Attached initrd image at 0x004e0000-0x006a2b97
> initrd head: 0x1f8b0808
>
> Linux/PowerPC load: console=ttyS0 root=/dev/ram init=/sbin/init
> Finalizing device tree... flat tree at 0x6b0300
> Using PowerPC 44x Platform machine description
> Linux version 2.6.30 (root at rosebud) (gcc version 4.2.4) #19 PREEMPT

You managed to build a kernel with the right-ish toolchain (modulo floating 
point), managed to load it onto your device via jtag or tftp or some such, 
your bootloader handed off to this kernel ok, your kernel successfully 
decompressed itself, and you have a working serial console (at least without 
interrupts).  And in the case of powerpc that means the kernel is getting at 
least a semi-coherent device tree from the bootloader.

That's a huge amount of success so far. :)

> Wed Nov 4 14:39:26 IST 2009
> Found initrd at 0xc04e0000:0xc06a2b97
> console [udbg0] enabled
> setup_arch: bootmem
> arch: exit
> Zone PFN ranges:
>   DMA      0x00000000 -> 0x00001000
>   Normal   0x00001000 -> 0x00001000
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
>     0: 0x00000000 -> 0x00001000
> MMU: Allocated 1088 bytes of context maps for 255 contexts
> Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 4064
> Kernel command line: console=ttyS0 root=/dev/ram init=/sbin/init
> NR_IRQS:512
> UIC0 (32 IRQ sources) at DCR 0x1c0
> PID hash table entries: 64 (order: 6, 256 bytes)
> clocksource: timebase mult[a6aaaab] shift[22] registered
> Console: colour dummy device 80x25
> Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
> Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
> Memory: 12456k/16384k available (1724k kernel code, 3928k reserved,
> 96k data, 91k bss, 108k init)
> Kernel virtual memory layout:
>   * 0xffffe000..0xfffff000  : fixmap
>   * 0xfde00000..0xfe000000  : consistent mem
>   * 0xfddff000..0xfde00000  : early ioremap
>   * 0xd1000000..0xfddff000  : vmalloc & ioremap
> Calibrating delay loop... 46.84 BogoMIPS (lpj=93696)
> Mount-cache hash table entries: 512
>
> bio: create slab <bio-0> at 0
> Trying to unpack rootfs image as initramfs...
> rootfs image is not initramfs (no cpio magic); looks like an initrd

Why are you _not_ using initramfs, by the way?  Especially on a low memory 
device, rootfs is a _lot_ more space efficient than initrd.

Yes, I wrote an article series on _that_ once upon a time:

  http://landley.net/writing/rootfs-intro.html
  http://landley.net/writing/rootfs-howto.html
  http://landley.net/writing/rootfs-programming.html

> Freeing initrd memory: 1802k freed
> msgmni has been set to 27
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> ÿserial8250.0: ttyS0 at MMIO 0x2080000 (irq = 16) is a 16550A
> console handover: boot [udbg0] -> real [ttyS0]
> brd: module loaded
> mice: PS/2 mouse device common for all mice
> RAMDISK: gzip image found at block 0
> RAMDISK: incomplete write (1279 != 32768)
> write error

And your ramdisk is toast.

This is not a busybox problem, this is a "the kernel didn't decompress your 
ramdisk image properly" problem.  It doesn't matter what's _in_ your ramdisk 
if it can't extract the thing, let alone mount it.

> VFS: Mounted root (ext2 filesystem) readonly on device 1:0.
> Freeing unused kernel memory: 108k init
> attempt to access beyond end of device
> ram0: rw=0, want=8258, limit=8192
> Buffer I/O error on device ram0, logical block 4128

Fallout from the above.

At a guess, you've fallen off the end of physical memory.

> Kernel panic - not syncing: No init found.  Try passing init= option to
> kernel. Call Trace:
> [c0ff7f30] [c0005d44] show_stack+0x4c/0x16c (unreliable)
> [c0ff7f70] [c002f8a4] panic+0xa0/0x168
> [c0ff7fc0] [c00013fc] init_post+0xe8/0xf8
> [c0ff7fd0] [c01941f4] kernel_init+0xd8/0x100
> [c0ff7ff0] [c000d980] kernel_thread+0x4c/0x68
> Rebooting in 180 seconds..

This is meaningless.  It's complaining it couldn't launch init, which is 
because it couldn't _find_ init, which is because it couldn't mount the 
ramdisk, which is because it couldn't _decompress_ the ramdisk, most likely 
because it ran out of memory.  This is the bottom of the hill, avalanche 
started rather a ways up from here.

Note that your device tree and the device's physical memory locations might 
not match.  I once played with a repurposed mips router that had 64 megs of 
ram but had it mapped wrong so it couldn't only access the first 8 megs of it, 
and anything written after that would bus error.  (We got it to boot to a 
shell prompt just fine.  Trying to do much beyond "ls -l" caused kernel panics.  
Note that the kernel _thought_ it had 64 megs to play with.  Doesn't mean it 
was _there_...)

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds