As documented in bug 1163550 and specifically bug 1163550 comment 42, sometimes, init_sh project (to boot into recovery mode) gets in the way of the boot process and nothing boots at all.

Dave, do you have any idea or time to look into this?

The only think I can think of is to check the local build directory. ls -l out/target/product/aries/root/init should look like: > lrwxrwxrwx 1 dhylands 12 Jun 3 14:25 init -> sbin/init.sh and ls -l out/target/product/aries/root/sbin should have these files in it: > drwxrwxr-x 2 dhylands 4096 Jul 21 16:35 ./ > drwxrwxr-x 9 dhylands 4096 Jun 3 14:25 ../ > -rwxrwxr-x 1 dhylands 166188 Jun 25 16:37 adbd* > -rwxrwxr-x 1 dhylands 665916 Jun 3 14:24 busybox* > -rwxrwxr-x 1 dhylands 198428 Jun 3 14:24 extract_elf_ramdisk* > -rwxrwxr-x 1 dhylands 120724 Jun 3 14:25 healthd* > -rw-rw-r-- 1 dhylands 2382 Jun 3 14:25 init.sh > lrwxrwxrwx 1 dhylands 7 Jul 21 16:35 sh -> busybox* > -rw-r--r-- 1 dhylands 87588 Jun 3 14:24 tad_static > lrwxrwxrwx 1 dhylands 7 Jun 3 14:25 ueventd -> ../init > -rw-r--r-- 1 dhylands 71204 Jun 3 14:24 wait4tad_static > lrwxrwxrwx 1 dhylands 7 Jun 3 14:25 watchdogd -> ../init I've seen cases where init winds up being a weird symlink rather than pointing to sbin/init.sh which would cause every boot to fail.

So I also have a case where device boots fine, can do wipe in recovery but does not show recovery menu.

And a case where nothing boots as expected! That's on Scorpion (Z3 Tablet Compact) > alex@portable-alex:~/codaz/Mozilla/b2g/devices/XperiaZ3c/B2G.L$ ll out/target/product/scorpion/root/init out/target/product/scorpion/root/sbin/ > lrwxrwxrwx 1 alex alex 12 juil. 28 16:02 out/target/product/scorpion/root/init -> sbin/init.sh > > out/target/product/scorpion/root/sbin/: > total 1,5M > drwxrwxr-x 2 alex alex 4,0K juil. 28 16:02 . > drwxrwxr-x 9 alex alex 4,0K juil. 28 16:02 .. > -rwxrwxr-x 1 alex alex 307K juil. 9 14:37 adbd > -rwxrwxr-x 1 alex alex 651K juil. 28 16:02 busybox > -rwxrwxr-x 1 alex alex 194K juil. 28 16:02 extract_elf_ramdisk > -rwxrwxr-x 1 alex alex 322K juil. 9 14:37 healthd > -rw-rw-r-- 1 alex alex 2,4K juil. 28 16:02 init.sh > lrwxrwxrwx 1 alex alex 7 juil. 28 16:02 sh -> busybox > lrwxrwxrwx 1 alex alex 7 juil. 28 16:02 ueventd -> ../init > lrwxrwxrwx 1 alex alex 7 juil. 28 16:02 watchdogd -> ../init

Does the Scorpion ever boot? The way I tested init.sh was to NOT use it, and then run it from a root shell. I'd normally put an exit just before the umount of /proc and see whether it unpacked things properly or not. Some of the other commands like the mknod/mount throughout the script probably also need to be commented out. can you get into an adb shell? If so there is a log stored in /boot.txt It's possible that /dev/input/event2 file descriptor needs to be different for the tablet. It's possible that the LEDs have a different path.

(In reply to Dave Hylands [:dhylands] from comment #6) > Does the Scorpion ever boot? Yep :) > > The way I tested init.sh was to NOT use it, and then run it from a root > shell. I'd normally put an exit just before the umount of /proc and see > whether it unpacked things properly or not. Some of the other commands like > the mknod/mount throughout the script probably also need to be commented out. Scorpion is Shinano, so it should not be different than Aries/Leo. > > can you get into an adb shell? If so there is a log stored in /boot.txt I'll try to look into this. > > It's possible that /dev/input/event2 file descriptor needs to be different > for the tablet. > It's possible that the LEDs have a different path. The LED was properly changing color.

The reason is probably because the KEY_EVENT is hard coded to "KEY_EVENT=/dev/input/event2", but on sirius-l I will need event3, and the yukon devices have others. easy check: "adb shell getevent" then press the VOLUP button. CM dealt with this with a device specific file that has all the variables like event#, LED path, partition# etc. However CM recently added a 'keycheck' program that removes the need for event# variables. https://github.com/CyanogenMod/android_device_sony_common/tree/cm-12.1/keycheck https://github.com/CyanogenMod/android_device_sony_msm8974-common/commit/3e22bab104c8f6081c83c5349c04423cc142e5ae

Another bug: init.sh is not used when doing "build.sh bootimage" after removing /out directory.

(In reply to Adam Farden from comment #9) > Another bug: init.sh is not used when doing "build.sh bootimage" after > removing /out directory. Nice finding, that is probably the root cause of this bug, since all my testing was mostly done on Z3c so the key event should not be the problem. Would it just be a bad make target dependency ?

And then maybe bug 1154956 is just a dupe ?

It seems the keyevent was buggy and somehow getting stuck. Since I removed it I haven't hit this issue, plus boot is no longer 3 seconds delayed.

Phew, I finally found the root cause. The key events we are checking should be null, but at boot this is briefly not null, causing init.sh to always detect a (phantom) key press, and so always boot to recovery. We can work around this by checking for a key press greater than the phantom key press. This is fine as the phantom key press is size 32 (at least, on sirius-l), while 2-3 key presses while the amber LED is lit will give a size in the several hundreds. Alex pointed out that we use the same branch of init.sh for both KK and L builds. This should probably be tested on both builds for devices that have both available, in case we need to increase the value for a specific device / build. You may need bug 1199675 on L builds.

Comment on attachment 8654122 [details] Dependency fix PR I made some comments on PR for bug 119675 and didn't realize the overlap with this bug, so my comments for bug 119675 really apply here. r=me with minor issues addressed.

All minor issues addressed.

So far it seems to be working properly on KK device: - build is fine after killing out/product/target/aries/ - adb reboot recovery boots to recovery - pressing (once) VolUp during boot time (when LED is orange) boots to recovery

So all the tests I could run on my Z3 Compact running KK and L builds shows that this fixed all the L-related issues we could have so far, and nothing regressed on KK port. I'm flagging you just in case we start having issues after landing this: - device not booting at all - device constantly booting to recovery - non working recovery

Thanks for the heads up!

For some reason the build I made didn't have system apps on the system partition; had to force it via : B2G_SYSTEM_APPS=1 ie: B2G_SYSTEM_APPS=1 variant=eng MOZILLA_OFFICIAL=1 ./build.sh

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #20) > For some reason the build I made didn't have system apps on the system > partition; had to force it via : > B2G_SYSTEM_APPS=1 > > ie: > B2G_SYSTEM_APPS=1 variant=eng MOZILLA_OFFICIAL=1 ./build.sh eng builds put the apps in the data partition by default, unless you override it like you did. user and userdebug builds put the apps in the system partition by default.