Kernel always boots to recovery

[agherzan]

Hi guys,

Using the 2a02f645592dc8a4f230fdbb79b00cf5eaac1764 from 3.19 WIP, the kernel always boots in recovery.

Starting kernel ...

[    2.515815] bcove_thrm bcove_thrm: incorrect number of channels:8
[    2.521930] bcove_thrm bcove_thrm.0: platform data not found
[    2.529413] intel_powerclamp: Intel powerclamp does not run on family 6 model 74
[    3.076655] pmic_ccsm pmic_ccsm: Error reading battery profile from battid frmwrk
[    3.085004] pmic_ccsm pmic_ccsm: Battery Over heat exception
[    3.092173] pmic_ccsm pmic_ccsm: Battery0 temperature outside boundary
[    3.093342] pmic_ccsm pmic_ccsm.0: Error reading battery profile from battid frmwrk
[    3.106917] pmic_ccsm pmic_ccsm.0: Battery Over heat exception
[    3.107843] pmic_ccsm pmic_ccsm.0: Error creating debugfs entry!!
/init: line 20: syslogd: not found
starting version 225
mount: mounting /dev/loop0 on /update failed: Invalid argument
Missing recove�^H�Z�Y.KH�X]�,ZZ�$V���פ.ZY��
sh: can't access tty; job control turned off
/ # 
/ #

After a while of being in shell, the board freezes and reboots.

Here is a dmsg log: http://pastebin.com/AeABf9Z5

Regards, Andrei

[dennisjobrien]

Are you sure you have the latest wip-edison-3.19.5? The HEAD is 9097ab0ea160187c87b049c3cb92b87170f3bc24. We thought we had corrected the bcove_thrm issue... We will retest and get back to you on that.

As for booting in recovery, we have seen this if you are using the HEAD of the poky:jethro branch. The 'Yocto guys' confirmed that they broke things. They are looking for a fix and will push one when they find it. In the meantime, a workaround is to do a 'git checkout 8a3deca4a4dae430e5434c2f082a4b46bfd5188a' which is in the jethro branch, but not the HEAD. This should take care of the booting in recovery.

Cheers! Dennis

[agherzan]

Hi Dennis,

I'm using exactly that revision on wip-edison-3.19.5. The above output was indeed not from 9097ab0ea160187c87b049c3cb92b87170f3bc24 but from 2a02f645592dc8a4f230fdbb79b00cf5eaac1764 . But the following is from current HEAD (9097ab0ea160187c87b049c3cb92b87170f3bc24) .

And here are some additional findings. Even though I provide the correct PARTUUID

cat /proc/cmdline 
rootwait root=PARTUUID=012b3303-34ac-284d-99b4-34e03a2335f4 rootfstype=ext4 console=ttyMFD2 [...]

the boot fails.

[    2.921012] VFS: Cannot open root device "PARTUUID=" or unknown-block(0,0): error -6
[    2.921031] Please append a correct "root=" boot option; here are the available partitions:
[    2.921077] b300         3817472 mmcblk0  driver: mmcblk
[    2.921106]   b301            2048 mmcblk0p1 d117f98e-6f2c-d04b-a5b2-331a19f91cb2
[    2.921130]   b302            1024 mmcblk0p2 25718777-d0ad-7443-9e60-02cb591c9737
[    2.921153]   b303            2048 mmcblk0p3 8a4bb8b4-e304-ae48-8536-aff5c9c495b1
[    2.921175]   b304            1024 mmcblk0p4 08992135-13c6-084b-9322-3391ff571e19
[    2.921197]   b305            1024 mmcblk0p5 333a128e-d3e3-b94d-92f4-d3ebd9b3224f
[    2.921219]   b306           24576 mmcblk0p6 f20aa902-1c5d-294a-9177-97a513e3cae4
[    2.921242]   b307           32768 mmcblk0p7 db88503d-34a5-3e41-836d-c757cb682814
[    2.921264]   b308          262144 mmcblk0p8 012b3303-34ac-284d-99b4-34e03a2335f4
[    2.921286]   b309          262144 mmcblk0p9 faec2ecf-8544-e241-b19d-757e796da607
[    2.921308]   b30a           16384 mmcblk0p10 f13a0978-b1b5-1a4e-8821-39438e24b627
[    2.921331]   b30b         3211247 mmcblk0p11 b710eb04-45b9-e94a-8d0b-21458d596f54
[    2.921358] b360            4096 mmcblk0rpmb  (driver?)
[    2.921382] b340            4096 mmcblk0boot1  (driver?)
[    2.921404] b320            4096 mmcblk0boot0  (driver?)
[    2.921422] VFS: Unable to mount root fs on unknown-block(0,0)
[    2.921501] User configuration error - no valid root filesystem found
[    2.921571] Kernel panic - not syncing: Invalid configuration from end user prevents continuing
[    2.921650] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.10.17-yocto-standard #1
[    2.921709] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 466 2014.06.23:19.20.05
[    2.921776]  f6c45ed8 f6c45ed8 f6c45e8c c1958c77 f6c45eac c1952fd7 c1b74f74 c1dda400
[    2.921888]  00000000 f6c45ed8 00008001 f5db9000 f6c45f04 c1d25f0e c1b64150 f6c45ed8
[    2.921996]  f6c45ed8 fffffffa 00000000 00000000 ffffff9c f7ac9720 fffffffa 6e6b6e75
[    2.922104] Call Trace:
[    2.922155]  [<c1958c77>] dump_stack+0x16/0x18
[    2.922211]  [<c1952fd7>] panic+0x87/0x181
[    2.922267]  [<c1d25f0e>] mount_block_root+0x23a/0x23a
[    2.922330]  [<c132982d>] ? SyS_mknod+0x2d/0x30
[    2.922383]  [<c1d26068>] mount_root+0x5b/0x61
[    2.922435]  [<c1d261b7>] prepare_namespace+0x149/0x18d
[    2.922493]  [<c131a745>] ? SyS_access+0x25/0x30
[    2.922547]  [<c1d25c00>] kernel_init_freeable+0x1ef/0x1fc
[    2.922607]  [<c1d254e0>] ? do_early_param+0x78/0x78
[    2.922667]  [<c19455e0>] kernel_init+0x10/0x140
[    2.922721]  [<c19636b7>] ret_from_kernel_thread+0x1b/0x28
[    2.922779]  [<c19455d0>] ? rest_init+0x80/0x80
[    2.922837] emmc_ipanic: panic notified
[    2.922918] sdhci_pci_power_up_host: host controller power up is done

This output is from emmc_ipanic_console and above in that output I see clearly that the root comandline is completely ignored:

[ 0.000000] Kernel command line: rootwait root=PARTUUID= rootfstype=ext4 console=ttyMFD2 earlyprintk=ttyMFD2,keep loglevel=4 g_multi.ethernet_config= [...]

Andrei

[agherzan]

I will give a try using that poky revision but I really don't see how poky can break as with the above behavior. Will provide feedback.

Andrei

[agherzan]

Hi,

I confirm that 8a3deca4a4dae430e5434c2f082a4b46bfd5188a works fine. I did some investigation and the roots of the issue are in this commit http://patchwork.openembedded.org/patch/114217/ . Basically the ARCH was changed for iX86 from x86 to i386 . They handle this change correctly by mapping i386 to x86 src directory but the issue is that KERNEL_OUTPUT https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass?id=jethro-14.0.1#n96 does not have this mapping leaving it to point to i386 . The fix for this is easy and I will send it to git://sandbox.sakoman.com/meta-edison-bsp.git as soon as I figure out how to send the patches there.

Regards and thanks for hints, Andrei