Bug's comment [1] report a problem with booting a qemu arm image. To keep issues separated, this bug reports just the booting part, not the building/patching part reported. [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=8486#c5 Copy & Paste log from [1]: ############# VFS: Cannot open root device "vda" or unknown-block(0,0): error -6 Please append a correct "root=" boot option; here are the available partitions: 0100 4096 ram0 (driver?) 0101 4096 ram1 (driver?) 0102 4096 ram2 (driver?) 0103 4096 ram3 (driver?) 0104 4096 ram4 (driver?) 0105 4096 ram5 (driver?) 0106 4096 ram6 (driver?) 0107 4096 ram7 (driver?) 0108 4096 ram8 (driver?) 0109 4096 ram9 (driver?) 010a 4096 ram10 (driver?) 010b 4096 ram11 (driver?) 010c 4096 ram12 (driver?) 010d 4096 ram13 (driver?) 010e 4096 ram14 (driver?) 010f 4096 ram15 (driver?) VFS: Unable to mount root fs on unknown-block(0,0) User configuration error - no valid root filesystem found Kernel panic - not syncing: Invalid configuration from end user prevents continuing CPU: 0 PID: 1 Comm: swapper Not tainted 4.1.8-yocto-standard #1 Hardware name: ARM-Versatile PB [<c0016c1c>] (unwind_backtrace) from [<c0013104>] (show_stack+0x20/0x24) [<c0013104>] (show_stack) from [<c0634744>] (dump_stack+0x20/0x28) [<c0634744>] (dump_stack) from [<c0630770>] (panic+0x94/0x1ec) [<c0630770>] (panic) from [<c0897448>] (mount_block_root+0x22c/0x280) [<c0897448>] (mount_block_root) from [<c089767c>] (mount_root+0xe8/0x110) [<c089767c>] (mount_root) from [<c089780c>] (prepare_namespace+0x168/0x1c8) [<c089780c>] (prepare_namespace) from [<c0896f4c>] (kernel_init_freeable+0x228/0x27c) [<c0896f4c>] (kernel_init_freeable) from [<c062fec4>] (kernel_init+0x18/0xf4) [<c062fec4>] (kernel_init) from [<c000f3c0>] (ret_from_fork+0x14/0x34) ---[ end Kernel panic - not syncing: Invalid configuration from end user prevents continuing random: nonblocking pool is initialized ###################
Yin, Can you do the testing again, this time including the patch [1] that try to solve [2] ? Patch is not accepted yet, but it solves [2] and with it, I did not see the booting problem reporting here. The only machine (MACHINE) I tested it was qemuarm. I was wondering how we can automate this test (creating the bsp, including into bblayers, adding a patch, adding configs, then build the kernel). Creating the bsp could be the tricky part, because it expects stdin input from user AFAIK. [1] http://lists.openembedded.org/pipermail/openembedded-core/2015-November/112208.html [2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=8486
Hi, I tested qemuarm again with latest jethro branch (fc45deac89ef63ca1c44e763c38ced7dfd72cbe1), I can not reproduce this issue. For the automate test, we have not enough time and resources to test every arch in one test cycle. So we use a script to choose a random arch to test each time.
(In reply to comment #2) > Hi, > I tested qemuarm again with latest jethro branch > (fc45deac89ef63ca1c44e763c38ced7dfd72cbe1), I can not reproduce this issue. > Thanks for testing it again. I will change the status to resolved (notabug) > For the automate test, we have not enough time and resources to test every > arch in one test cycle. So we use a script to choose a random arch to test > each time. Right, it is quite time consuming to do whole build for each arch.
Verified on master: fc45deac89ef63ca1c44e763c38ced7dfd72cbe1