Kernel Panic: Cannot open root device

[newbie_osdev]

Hi

When I try to boot kernel from u-boot prompt it panics:

My u-boot env for kernel args looks like this

bootargs= cros_legacy root=/dev/mmcblk0p7 rootwait rw mmcrootfstype=ext4 console=ttySAC3,115200 debug verbose earlyprintk daisy lsm.module_locking=0

I am pretty sure that there is no problem with the internal emcc itself and a valid root fs reside in the above partition.

Reason being am able to boot the very same kernel and rootfs with another version of u-boot. this u-boot is built from sources so I might be missing some configurations perhaps?

I suspect either I am missing additional env configuration or something outside the kernel itself possibly in the sources of u-boot if that is even possible?

output:

mmcblk0boot0 error-84 transferring data sector 4 nr 4.....
end request: I/O error...

...

..

VFS: Cannot open root device"mmcblk0p7" or unknown block 179, 7

Please append a correct root= boot option. here are the available partition

mmcblk0 driver mmcblk

mmcblk0boot1 driver?

mmcblk0boot0 driver?

Kernel panic not syncing unable to mount rootfs on unknown block 179,7

Any pointers highly appreciated.

Regards,

Arthy

[Mike Frysinger]

did you enable GPT partition parsing support in your kernel ?
-mike

> --
> --
> Chromium OS Developers mailing list: chromiu...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
>
>
>

[Sonny Rao]

On Sat, Apr 13, 2013 at 8:28 PM, newbie_osdev <arthys...@gmail.com> wrote:
> Hi
>
> When I try to boot kernel from u-boot prompt it panics:
>
> My u-boot env for kernel args looks like this
>
> bootargs= cros_legacy root=/dev/mmcblk0p7 rootwait rw mmcrootfstype=ext4
> console=ttySAC3,115200 debug verbose earlyprintk daisy lsm.module_locking=0
>
> I am pretty sure that there is no problem with the internal emcc itself and
> a valid root fs reside in the above partition.

What makes you say that? I see I/O errors in the tiny bit of log you
posted. Do you know why that is happening?

>
> Reason being am able to boot the very same kernel and rootfs with another
> version of u-boot. this u-boot is built from sources so I might be missing
> some configurations perhaps?
>
> I suspect either I am missing additional env configuration or something
> outside the kernel itself possibly in the sources of u-boot if that is even
> possible?
>
> output:
>
> mmcblk0boot0 error-84 transferring data sector 4 nr 4.....
> end request: I/O error...
> ...
> ..
> VFS: Cannot open root device"mmcblk0p7" or unknown block 179, 7
> Please append a correct root= boot option. here are the available partition
> mmcblk0 driver mmcblk
> mmcblk0boot1 driver?
> mmcblk0boot0 driver?
> Kernel panic not syncing unable to mount rootfs on unknown block 179,7
>
> Any pointers highly appreciated.
>
>
> Regards,
> Arthy
>

[Mike Frysinger]

On Sat, Apr 13, 2013 at 11:32 PM, Sonny Rao <sonn...@chromium.org> wrote:
> On Sat, Apr 13, 2013 at 8:28 PM, newbie_osdev <arthys...@gmail.com> wrote:
>> When I try to boot kernel from u-boot prompt it panics:
>>
>> My u-boot env for kernel args looks like this
>>
>> bootargs= cros_legacy root=/dev/mmcblk0p7 rootwait rw mmcrootfstype=ext4
>> console=ttySAC3,115200 debug verbose earlyprintk daisy lsm.module_locking=0
>>
>> I am pretty sure that there is no problem with the internal emcc itself and
>> a valid root fs reside in the above partition.
>
> What makes you say that? I see I/O errors in the tiny bit of log you
> posted. Do you know why that is happening?

i vaguely recall there being a emmc clock related bug with certain
firmware versions

Arthy: when you boot ChromeOS and run `crossystem`, what does it
report for firmware version ?
-mike

[newbie_osdev]

 Hi

> Reason being am able to boot the very same kernel and rootfs with another 
> version of u-boot. this u-boot is built from sources so I might be missing 
> some configurations perhaps? 

Once I revert the u-boot to the google's official prebuilt version my ubuntu boots fine.

No change was made to the kernel/partition/fs or anything.

Yes I see a lot of those IO buffer errors which doesn't happen when I go back to the old.

[newbie_osdev]

Hi

The u-boot is chainbooted (and resides in the KERN A of usb)

The active firmware id is Google_Snow.2695.114.0

On Saturday, April 13, 2013 11:28:48 PM UTC-4, newbie_osdev wrote:

[Grant Grundler]

On Sat, Apr 13, 2013 at 8:40 PM, Mike Frysinger <vap...@chromium.org> wrote:
...

> i vaguely recall there being a emmc clock related bug with certain
> firmware versions

http://crbug.com/221828
Daisy: kernel won't boot after abde7fecdb4aa9cdf11fc90c6bef5ddf8c193265


cheers,
grant

[Arthy Sundaram]

Hi 

I am not sure though.

As per my understanding..

firmware -> verified u-boot-> chainloaded u-boot from usb (prebuilt downloaded from google)-> custom kernel (mmcblk0p6) -> mount rootfs (mmcblk0p7)

The above succeeds always except when I replace the chainloaded u-boot with built from source in which case

firmware -> verified u-boot -> chainloaded u-boot (usb) ----> environment variable set -> custom kernel (mmcblk0p6) --X

The failure happens at the last leg isn't it?

[newbie_osdev]

Any pointers in this regard will be highly appreciated.
I can't make sense out of it. 
I am just wondering, If it is the firmware then how does it work with one version of nv-u-boot but not with the other

Regards,

[newbie_osdev]

The problem is resolved through workaround

For unknown reason, the set up do not work on the internal emcc

As soon as I moved the kernel and rootfs to an external sd card 

I could boot them from nv-uboot

Regards,

Arthy

On Saturday, April 13, 2013 11:28:48 PM UTC-4, newbie_osdev wrote:

[ggg]

On Saturday, April 20, 2013 5:06:00 PM UTC-7, newbie_osdev wrote:

The problem is resolved through workaround

For unknown reason, the set up do not work on the internal emcc

As soon as I moved the kernel and rootfs to an external sd card 

I could boot them from nv-uboot

Please read the bug report I posted:

    http://crbug.com/221828 

    Daisy: kernel won't boot after abde7fecdb4aa9cdf11fc90c6bef5ddf8c193265 

Workaround is to update either or both of the "BIOS" firmware:

   chromeos-firmwareupdate --mode=auto

(and if that doesn't work, look comment #18 in the bug for alternatives)

grant