[Udoobuntu Beta 2] The last few lines are Code: [ 3.125406] snvs_rtc snvs_rtc.0: setting system clock to 1970-01-01 03:58:05 UTC (14285) [ 3.134249] VFS: Cannot open root device "sda1" or unknown-block(0,0) [ 3.140706] Please append a correct "root=" boot option; here are the available partitions: [ 3.149077] b300 15351296 mmcblk0 driver: mmcblk [ 3.154410] b301 6803527 mmcblk0p1 00000000-0000-0000-0000-000000000000 [ 3.161917] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 3.170219] [<800475d4>] (unwind_backtrace+0x0/0xfc) from [<805c74b0>] (panic+0x74/0x19c) [ 3.178446] [<805c74b0>] (panic+0x74/0x19c) from [<80008cc4>] (mount_block_root+0x16c/0x220) [ 3.186895] [<80008cc4>] (mount_block_root+0x16c/0x220) from [<80008e50>] (mount_root+0xd8/0xf4) [ 3.195710] [<80008e50>] (mount_root+0xd8/0xf4) from [<80008f8c>] (prepare_namespace+0x120/0x184) [ 3.204606] [<80008f8c>] (prepare_namespace+0x120/0x184) from [<800083dc>] (kernel_init+0x108/0x144) any help would be great, thanks. Edit: it only happens with the one drive, but the same drive still works correctly for other operating systems.
same issue here with v1.0. I'm trying to boot from a Samsung EVO 120GB. I should add that sometimes I don't get a kernel panic but get this instead. Code: [ 2.974824] VFS: Cannot open root device "sda1" or unknown-block(0,0) [ 2.981283] Please append a correct "root=" boot option; here are the available partitions: and it just sits there. Followed by this on the next boot attempt (kernel panic) Code: [ 2.966306] snvs_rtc snvs_rtc.0: setting system clock to 1970-01-01 00:05:29 UTC (329) [ 2.974988] VFS: Cannot open root device "sda1" or unknown-block(0,0) [ 2.981452] Please append a correct "root=" boot option; here are the available partitions: [ 2.989824] b300 15558144 mmcblk0 driver: mmcblk [ 2.995158] b301 15550111 mmcblk0p1 00000000-0000-0000-0000-000000000000 [ 3.002665] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 3.011027] [<800475d4>] (unwind_backtrace+0x0/0xfc) from [<8065e690>] (panic+0x74/0x19c) [ 3.019226] [<8065e690>] (panic+0x74/0x19c) from [<80008cc4>] (mount_block_root+0x16c/0x220) [ 3.027681] [<80008cc4>] (mount_block_root+0x16c/0x220) from [<80008e50>] (mount_root+0xd8/0xf4) [ 3.036476] [<80008e50>] (mount_root+0xd8/0xf4) from [<80008f8c>] (prepare_namespace+0x120/0x184) [ 3.045363] [<80008f8c>] (prepare_namespace+0x120/0x184) from [<800083dc>] (kernel_init+0x108/0x144) [ 3.054515] [<800083dc>] (kernel_init+0x108/0x144) from [<80041080>] (kernel_thread_exit+0x0/0x8) [ 3.063401] CPU1: stopping [ 3.066132] [<800475d4>] (unwind_backtrace+0x0/0xfc) from [<8003a26c>] (do_IPI+0x120/0x14c) [ 3.074493] [<8003a26c>] (do_IPI+0x120/0x14c) from [<8003ffcc>] (__irq_svc+0x4c/0xe8) [ 3.082326] Exception stack(0xbffadf90 to 0xbffadfd8) [ 3.087381] df80: 80cbc280 20000093 00000001 00000000 [ 3.095563] dfa0: bffac000 80cb4d64 80663744 80c6141c 1000406a 412fc09a 00000000 00000000 [ 3.103744] dfc0: 00000000 bffadfd8 8004f37c 80041124 40000013 ffffffff [ 3.110366] [<8003ffcc>] (__irq_svc+0x4c/0xe8) from [<80041124>] (default_idle+0x24/0x28) [ 3.118551] [<80041124>] (default_idle+0x24/0x28) from [<800417e0>] (cpu_idle+0xc8/0x108) [ 3.126736] [<800417e0>] (cpu_idle+0xc8/0x108) from [<1065b774>] (0x1065b774) [ 3.133875] CPU3: stopping [ 3.136596] [<800475d4>] (unwind_backtrace+0x0/0xfc) from [<8003a26c>] (do_IPI+0x120/0x14c) [ 3.144956] [<8003a26c>] (do_IPI+0x120/0x14c) from [<8003ffcc>] (__irq_svc+0x4c/0xe8) [ 3.152788] Exception stack(0xbff01f90 to 0xbff01fd8) [ 3.157843] 1f80: 80cbc280 60000093 00000001 00000000 [ 3.166025] 1fa0: bff00000 80cb4d64 80663744 80c6141c 1000406a 412fc09a 00000000 00000000 [ 3.174206] 1fc0: 00000000 bff01fd8 8004f37c 80041124 40000013 ffffffff [ 3.180828] [<8003ffcc>] (__irq_svc+0x4c/0xe8) from [<80041124>] (default_idle+0x24/0x28) [ 3.189013] [<80041124>] (default_idle+0x24/0x28) from [<800417e0>] (cpu_idle+0xc8/0x108) [ 3.197195] [<800417e0>] (cpu_idle+0xc8/0x108) from [<1065b774>] (0x1065b774) [ 3.204333] CPU0: stopping [ 3.207054] [<800475d4>] (unwind_backtrace+0x0/0xfc) from [<8003a26c>] (do_IPI+0x120/0x14c) [ 3.215414] [<8003a26c>] (do_IPI+0x120/0x14c) from [<8003ffcc>] (__irq_svc+0x4c/0xe8) [ 3.223246] Exception stack(0x80c49f68 to 0x80c49fb0) [ 3.228302] 9f60: 80cbc280 60000093 00000001 00000000 80c48000 80cb4d64 [ 3.236484] 9f80: 80663744 80c6141c 1000406a 412fc09a 00000000 00000000 00000000 80c49fb0 [ 3.244664] 9fa0: 8004f37c 80041124 40000013 ffffffff [ 3.249722] [<8003ffcc>] (__irq_svc+0x4c/0xe8) from [<80041124>] (default_idle+0x24/0x28) [ 3.257907] [<80041124>] (default_idle+0x24/0x28) from [<800417e0>] (cpu_idle+0xc8/0x108) [ 3.266091] [<800417e0>] (cpu_idle+0xc8/0x108) from [<800088b0>] (start_kernel+0x254/0x294) [ 3.274447] [<800088b0>] (start_kernel+0x254/0x294) from [<1000803c>] (0x1000803c)
This happens because UDOO has SATA as default boot option, if present. So, use the UDOO Config Tool to set primary boot device to SD Card, and then reboot with SATA drive. This way you'll see the SATA drive as a second HD. If you boot with SATA attached with default settings, the system expects to find a boot partition on it.
Thanks. should have mentioned that I'm trying to boot off of it and have used dd to create an ext3 partition with the information on it. In fact if you look at the full log (I didn't post it all) you can see that it's pulling the kernel off of the data drive and booting up to the point that you see above. For some reason it kernel panics as soon as it goes to switch to the "root" device.
I'm under the impression you have to boot off the uSD card. Just the UBOOT stuff, then the SATA drive can continue.
I think this is how I could get it to work. I, too, saw the kernel panic. Sequence of events: 1. Plug in brand new SSD SATA drive and boot - no problem. Discovered there was no partition table on the drive, which is likely why I could boot. 2. Use gparted to add partition table / add two partitions (one for root and one for swap) 3. Reboot 4. Get kernel panic with a somewhat useful message indicating /dev/sda issue At this point, my issue was same as described - I made the mistake of rebooting before copying files over. But executing Code: run mmcboot from the boot loader and I could get back in even with the SSD SATA drive connected. Had brief flashbacks of configuring Sun/SGI workstations and working in the forth-like editors prior to boot... Note this is different than using dd to copy the image - it's just a copy of the files with cp -ra from the root filesystem on the flash card to the new SATA drive, with filesystem created / mounted properly. I made extensive customization to the OS with updates so did not want to start over with the raw image. I updated /etc/fstab on /dev/sda1, the soon-to-be root partition: Code: /dev/sda1 / ext4 defaults 0 1 /dev/sda2 none swap sw 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs defaults 0 0 reboot and that was all. The original fstab was empty so not sure how it all worked - but anyway, I updated just to be safe. I saw a number of web pages that provided bits and pieces of info... 1. Some say must boot kernel from flash card. I believe that is how this is working - booting my custom kernel from the flash disk and then mounting the SATA drive as root 2. Other pages listed many changes required in the u-boot config - I changed nothing.
