Bug 10189 - Cannot install images Genericx86, Genericx86_64, Genericx86_64-lsb from USB, panic message is displayed
Summary: Cannot install images Genericx86, Genericx86_64, Genericx86_64-lsb from USB, ...
Status: RESOLVED FIXED
Alias: None
Product: BSPs
Classification: Build System, Metadata & Runtime
Component: bsps-runtime (show other bugs)
Version: 2.2
Hardware: All Multiple
: Medium+ normal
Target Milestone: 2.2 M4
Assignee: Alejandro Hernandez
QA Contact: Francisco Pedraza
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2016-08-25 21:39 UTC by David Rodriguez
Modified: 2017-06-13 23:19 UTC (History)
5 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Don't know

Attachments
NUC-USB-HDD (2.51 MB, image/jpeg)
2016-08-25 21:39 UTC, David Rodriguez 		no flags Details
MMAX64-USB-HDD (2.27 MB, image/jpeg)
2016-08-25 21:40 UTC, David Rodriguez 		no flags Details
MMAX32-USB-SD (2.34 MB, image/jpeg)
2016-08-25 21:42 UTC, David Rodriguez 		no flags Details
MMAX32-USB-HDD (2.26 MB, image/jpeg)
2016-08-25 21:42 UTC, David Rodriguez 		no flags Details
bisect log (1.96 KB, text/plain)
2016-08-30 01:56 UTC, California Sullivan 		no flags Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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.