Bug#809611: d-i fails to boot on HP mv2120

[Geert Stappers <stappers@stappers.nl>]

> 
> Output from the serial console is below:
> 
> ------------------------------------------------------------------------------------
>          __  __                      _ _
>         |  \/  | __ _ _ ____   _____| | |
>         | |\/| |/ _` | '__\ \ / / _ \ | |
>         | |  | | (_| | |   \ V /  __/ | |
>         |_|  |_|\__,_|_|    \_/ \___|_|_|
>  _   _     ____              _
> | | | |   | __ )  ___   ___ | |_
> | | | |___|  _ \ / _ \ / _ \| __|
> | |_| |___| |_) | (_) | (_) | |_
>  \___/    |____/ \___/ \___/ \__|  ** Forcing LOADER mode only **
>  ** MARVELL BOARD: RD-88F5182-NAS-P2 LE
> 
> U-Boot 1.1.4 (Oct 12 2007 - 12:30:28) Marvell version:
> 2.3.11_HP_1_3_1_Built@HP
> 
> U-Boot code: 00200000 -> 0026FFF0  BSS: -> 0027FDBC
   <snip/> 
> Booting the image (@ 0x400000) with RamDisk (@ 0x600000)...
> ## Booting image at 00400000 ...
>    Image Name:   Debian kernel
>    Created:      2015-12-31   0:09:38 UTC
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    1988600 Bytes =  1.9 MB
>    Load Address: 01000000
>    Entry Point:  01000000
>    Verifying Checksum ... OK
> OK
> ## Loading Ramdisk Image at 00600000 ...
>    Image Name:   Debian installer
>    Created:      2015-12-31   0:09:38 UTC
>    Image Type:   ARM Linux RAMDisk Image (uncompressed)
>    Data Size:    6286998 Bytes =  6 MB
>    Load Address: 00000000
>    Entry Point:  00000000
>    Verifying Checksum ... OK
> 
> Starting kernel ...
> 
> Uncompressing Linux... done, booting the kernel.
    <snip/>
> [    0.000000] Kernel command line: console=ttyS0,115200

Only 'console=...'

    <snip/>
> [    0.000000] Virtual kernel memory layout:
> [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> [    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
> [    0.000000]     vmalloc : 0xc8800000 - 0xff000000   ( 872 MB)
> [    0.000000]     lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
> [    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
> [    0.000000]       .text : 0xc0008000 - 0xc055abf0   (5451 kB)
> [    0.000000]       .init : 0xc055b000 - 0xc05a6000   ( 300 kB)
> [    0.000000]       .data : 0xc05a6000 - 0xc060fa60   ( 423 kB)
> [    0.000000]        .bss : 0xc060fa60 - 0xc065632c   ( 283 kB)
> [    0.000000] NR_IRQS:65
> [    0.000025] sched_clock: 32 bits at 166MHz, resolution 6ns, wraps every 12884901885ns

12884901885ns
12884901us (micro)
12884ms
12s

those twelve secondes _might_ explain twelve seconds.

but from 12 seconds to almost 15 seconds, still lacks three seconds.

I wonder what happens between '[    0.000025]' and '[   14.996063]'
It is out of curiosity. The gap in logging is not the reason for te boot failure.


> [   14.996063] clocksource: orion_clocksource: mask: 0xffffffff max_cycles: > 0xffffffff, max_idle_ns: 11467562657 ns
         <snip/>
> [   15.957087] rtc-pcf8563 0-0051: setting system clock to 2015-12-31 21:08:49 UTC (1451596129)
> [   15.966823] List of all partitions:
> [   15.970423] 1f00             512 mtdblock0  (driver?)
> [   15.975526] No filesystem could mount root, tried:
> [   15.980464] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
         <snip/>
> ------------------------------------------------------------------------------------
> Hopefully it's something easy to diagnose.

My diagnose: 'No filesystem could mount root'.
My _guess_: uboot and kernel+initrd don't understand each other.

Thing I would try: adding a root= parameter to uboot to hand over to kernel+initrd.


Groeten
Geert Stappers
-- 
Leven en laten leven