Bug 10189

Summary: Cannot install images Genericx86, Genericx86_64, Genericx86_64-lsb from USB, panic message is displayed
Product: [Build System, Metadata & Runtime] BSPs Reporter: David Rodriguez <david.israelx.rodriguez.castellanos>
Component: bsps-runtimeAssignee: Alejandro Hernandez <alejandro.hernandez>
Status: RESOLVED FIXED QA Contact: Francisco Pedraza <francisco.j.pedraza.gonzalez>
Severity: normal    
Priority: Medium+ CC: california.l.sullivan, davidx.lopez.barriba, jose.perez.carranza, yp.kernel.watcher, yp.watcher
Version: 2.2   
Target Milestone: 2.2 M4   
Hardware: All   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: Don't know
Attachments:
Description Flags
NUC-USB-HDD
none
MMAX64-USB-HDD
none
MMAX32-USB-SD
none
MMAX32-USB-HDD
none
bisect log none

Description David Rodriguez 2016-08-25 21:39:39 UTC 
Created attachment 3386 [details]
NUC-USB-HDD

STATUS: FAILED
BUILD: master: f038f069977170e323c9c6884c69e0b9e1cf1c6f
ENVIRONMENTS: genericx86-64 on NUC, MMAX32, AND MMAX64

STEPS TO REPRODUCE: 
1. plugin usb which contains live image burned
2. configure device BIOS to firstly boot from USB if necessary
3. boot the device and select option "Install"  from boot menu
4. proceed through default install process
5. Remove USB, and reboot into new installed system.  

EXPECTED OUTCOME: 
1. User can choose install system from USB stick onto hard disk from boot menu or command line option
2. Installed system can boot up

ACTUAL RESULT: 
Image cannot be installed in any device. 
Installation process not completed, consequently neither boot process completed. 
Panic message is displayed "sh can't access tty; job control turned off ",
for detail see attached files.


Notes: Tried with below scenarios
        MMAX32 AND MMAX64   Firmware version 0.93
        NUC                 Firmware version  SYSKLi35.86A.0044


        -USB-SD cARD MMAX32
        -USB-HDD MMAX32 and MMAX64 (1Tb)  
        -USB-internal HDD NUC6I5SYH

More Notes: 1.similar to bug 4229
            2. System can boot successfully from USB
Comment 1 David Rodriguez 2016-08-25 21:40:56 UTC 
Created attachment 3387 [details]
MMAX64-USB-HDD
Comment 2 David Rodriguez 2016-08-25 21:42:16 UTC 
Created attachment 3388 [details]
MMAX32-USB-SD
Comment 3 David Rodriguez 2016-08-25 21:42:59 UTC 
Created attachment 3389 [details]
MMAX32-USB-HDD
Comment 4 David Rodriguez 2016-08-29 15:36:52 UTC 
Tested also in
MMAX32 AND MMAX64   Firmware version 0.92

-USB drive-SD cARD 
-USB drive-HDD(1Tb)
-USB drive-USB drive

Same results.
Comment 5 California Sullivan 2016-08-29 22:46:37 UTC 
I am also seeing this on intel-corei7-64 with the following commit hashes:

poky		f078ccf1ac60488169853724c35126cc056f975d
meta-intel	678db6436e4b118e1a888a3b93551e98b25c77cc
Comment 6 California Sullivan 2016-08-30 01:56:30 UTC 
Created attachment 3394 [details]
bisect log

Commit 993bfb "init-install*: only pick root mmc devices" seems to be the culprit.
Comment 7 Alejandro Hernandez 2016-08-30 03:05:36 UTC 
(In reply to comment #6)
> Created attachment 3394 [details]
> bisect log
> 
> Commit 993bfb "init-install*: only pick root mmc devices" seems to be the
> culprit.

Yes, it sure looks like that commit is the guilty one.

After some debugging I found the line thats actually causing the problem, it is the following:

mmc_devices=`ls /sys/block/ | grep "mmcblk[0-9]\{1,\}$"`

after which the install script fails, the previous line:

devices=`ls /sys/block/ | grep -v mmcblk`

reports fine, finding the block devices which are not mmcblk.
Comment 8 Alejandro Hernandez 2016-08-30 03:55:19 UTC 
Maybe busybox's grep has limited REGEX capabilities?
Comment 9 Alejandro Hernandez 2016-08-30 04:45:55 UTC 
Whats happening is that when trying to do:

mmc_devices=`ls /sys/block/ | grep "mmcblk[0-9]\{1,\}$"`

the grep command does not find any matching lines coming from the pipe (when not using an mmc device).

This causes grep to exit with a non-zero status, now this usually wouldn't cause an issue.

BUT, since when calling the script were doing:

#!/bin/sh -e

This causes the script to have the same behavior as doing something like "set -e" , which makes the script exit immediately if any command or pipeline returns a non-zero status.

Now this is obviously desired behavior since we are installing on a new device, we want to exit the installation if an error is found, so a workaround must be implemented.
Comment 10 Alejandro Hernandez 2016-08-30 05:16:49 UTC 
Looking at 993bfb, it seems that this affects other devices as well, not only the ones using the EFI installation.

Patch sent.