hana: recovery images fail to boot |
|||||
Issue description
Chrome OS Version:
R60-9468.0.0 <= Black screen
R60-9463.0.0 <= OK
Chrome OS Platform: Hana
Steps To Reproduce:
(1) cros flash usb:// xbuddy://remote/rowan/${VER}/recovery
(2) Hold Esc+Refresh & tap power to enter recovery
(3) Insert USB from (1)
Expected Result:
Recovery UI is shown and recovery starts.
Actual Result:
Black screen. After ~1 minute device reboots.
How frequently does this problem reproduce? (Always, sometimes, hard to
reproduce?)
Always, as of R60-9468.0.0
What is the impact to the user, and is there a workaround? If so, what is
it?
Cannot recover.
Please provide any additional information below. Attach a screen shot or
log if possible.
I suspect this might have something to do with recent changes to
,
Apr 18 2017
A manually built recovery image w/ serial enabled shows the following error: + . /lib/init.sh + USB_MNT=/usb + REAL_USB_DEV= + DM_NAME= + STATEFUL_MNT=/stateful + STATE_DEV= + LOG_DEV= + LOG_DIR=/log + LOG_FILE=/log/recovery.log + TAIL_PID= + TPM_B_LOCKED= + TPM_PP_LOCKED= + REAL_KERN_B_HASH= + BASE_MOUNTS=/sys /proc /dev + UNOFFICIAL_ROOT=0 + USE_FRECON=0 + . /lib/completion_settings.sh + INTERACTIVE_COMPLETE=true + . /lib/messages.sh + SCREENS=/etc/screens + LANGDIR= + . /etc/screens/constants.sh + BACKGROUND=fefefe + MESSAGE_BOX_WIDTH=1000 + MESSAGE_BOX_HEIGHT=115 + ICON_INSET_LEFT=-471 + ICON_INSET_TOP=-47 + PROGRESS_BAR_LEFT=-297[ 3.645154] usb 2-1: New USB device found, idVendor=2109, idProduct=0813 [ 3.652686] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 3.659768] usb 2-1: Product: USB3.0 Hub [ 3.664781] usb 2-1: Manufacturer: VIA Labs, Inc. + PROGRESS_BAR[ 3.671037] hub 2-1:1.0: USB hub found _TOP=-16 + PROG[ 3.675727] hub 2-1:1.0: 4 ports detected RESS_INCREMENT=3 + PROGRESS_INCREMENT_LEFT=-445 + PROGRESS_INCREMENT_TOP=-16 + INSTRUCTION_BOX_TOP=-115 + PROGRESS_BOX_TOP=0 + DEVMODE_BOX_TOP=115 + . /lib/defaults.sh + TTY_CONSOLE=/dev/tty1 + TTY_LOG=/dev/tty2 + TTY_DEBUG=/dev/tty3 + . /lib/recovery_init.sh + . /usr/sbin/write_gpt.sh + . /usr/share/misc/chromeos-common.sh + PARTITION_NUM_STATE=1 + PARTITION_NUM_KERN_A=2 + PARTITION_NUM_ROOT_A=3 + PARTITION_NUM_KERN_B=4 + PARTITION_NUM_ROOT_B=5 + PARTITION_NUM_KERN_C=6 + PARTITION_NUM_ROOT_C=7 + PARTITION_NUM_OEM=8 + PARTITION_NUM_RWFW=11 + PARTITION_NUM_EFI_SYSTEM=12 + GPT= + locate_gpt + [ -z ] + [ -x /usr/bin/cgpt ] + GPT=/usr/bin/cgpt + ROOTFS_PARTITION_SIZE=2147483648 + FW_VER_MIN=0x10001 + KERNEL_VER_MIN=0x10001 + FW_VER_TPM_NV_SPACE=0x1007 + KERNEL_VER_TPM_NV_SPACE=0x1008 + LOCKBOX_TPM_NV_SPACE=0x20000004 + REC_VER_MAX=0 + LOG_HARDWARE_DIAGNOSTICS=hardware_diagnostics.log + DST_DEV_BASE= + DST= + ERR_INVALID_INSTALL_KERNEL=2 + ERR_DEV_MODE_BLOCKED=3 + [ -f /lib/board_recovery.sh ] + [ /init = /init ] + main cros_secure cros_recovery [ 3.776229] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 [ 3.776229] [ 3.785299] CPU: 4 PID: 1 Comm: init Not tainted 4.4.52 #111 [ 3.790910] Hardware name: Mediatek Rowan board (DT) [ 3.795832] Call trace: [ 3.796216] usb 1-1: new high-speed USB device number 2 using xhci-mtk [ 3.804736] [<ffffffc000208860>] dump_backtrace+0x0/0x160 [ 3.810090] [<ffffffc000208af0>] show_stack+0x20/0x28 [ 3.815101] [<ffffffc0004cf92c>] dump_stack+0x90/0xb0 [ 3.820111] [<ffffffc0003001f8>] panic+0x100/0x248 [ 3.824862] [<ffffffc000222560>] do_exit+0x540/0x8f8 [ 3.829784] [<ffffffc000223a54>] do_group_exit+0x50/0xb0 [ 3.835050] [<ffffffc000223ad4>] __wake_up_parent+0x0/0x3c [ 3.840489] [<ffffffc000203e34>] el0_svc_naked+0x24/0x28 [ 3.845760] CPU1: stopping [ 3.848457] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.52 #111 [ 3.854505] Hardware name: Mediatek Rowan board (DT) [ 3.859431] Call trace: [ 3.861861] [<ffffffc000208860>] dump_backtrace+0x0/0x160 [ 3.867222] [<ffffffc000208af0>] show_stack+0x20/0x28 [ 3.872236] [<ffffffc0004cf92c>] dump_stack+0x90/0xb0 [ 3.877251] [<ffffffc00020e34c>] handle_IPI+0x194/0x2d0 [ 3.882437] [<ffffffc000200600>] gic_handle_irq+0xa8/0xd0 [ 3.887795] Exception stack(0xffffffc0fb1dfd90 to 0xffffffc0fb1dfec0) [ 3.894189] fd80: 00000000e3c8a3c1 0000008000000000 [ 3.901967] fda0: ffffffc0fb1dfef0 ffffffc000764b78 0000000060000145 0000000000000000 [ 3.909744] fdc0: ffffffc0fff3b480 00000000ffffffff 00000000febf5000 0000000000000018 [ 3.917521] fde0: 002d98f940040b28 0000000691cd0366 00000000000010d2 0000000000000000 [ 3.925299] fe00: ffffffc0fb1dff34 0000000000000000 00000000000008e0 0000000000000000 [ 3.933076] fe20: 0000000000000001 0000000000000001 0000000000000000 0000000000000000 [ 3.940854] fe40: ffffffc000361208 0000000000000000 0000000000000000 00000000e3c8a3c1 [ 3.948630] fe60: 0000000000000000 ffffffc0014242e8 ffffffc0bb7ba800 0000000000000001 [ 3.956407] fe80: 0000000000000000 00000000d7696adc ffffffc0014242e8 ffffffc000200c70 [ 3.964185] fea0: 0000000000000000 ffffffc0fb1dfef0 ffffffc000764b44 ffffffc0fb1dfef0 [ 3.971961] [<ffffffc000203700>] el1_irq+0x80/0xf8 [ 3.976718] [<ffffffc000764c68>] cpuidle_enter+0x34/0x40 [ 3.981993] [<ffffffc000267bc0>] cpu_startup_entry+0x378/0x3e0 [ 3.987782] [<ffffffc00020de0c>] secondary_start_kernel+0x148/0x154 [ 3.994004] [<0000000040200c5c>] 0x40200c5c [ 3.998154] CPU5: stopping [ 4.000840] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 4.4.52 #111 [ 4.006882] Hardware name: Mediatek Rowan board (DT) [ 4.011803] Call trace: [ 4.014226] [<ffffffc000208860>] dump_backtrace+0x0/0x160 [ 4.019580] [<ffffffc000208af0>] show_stack+0x20/0x28 [ 4.024588] [<ffffffc0004cf92c>] dump_stack+0x90/0xb0 [ 4.029596] [<ffffffc00020e34c>] handle_IPI+0x194/0x2d0 [ 4.034776] [<ffffffc000200600>] gic_handle_irq+0xa8/0xd0 [ 4.040128] Exception stack(0xffffffc0fb1efd90 to 0xffffffc0fb1efec0) [ 4.046515] fd80: 00000000e3c9a290 0000008000000000 [ 4.054283] fda0: ffffffc0fb1efef0 ffffffc000764b78 0000000060000045 0000000000000001 [ 4.062053] fdc0: 0000000000000000 ffffffc0fb1ec000 ffffffc00078961c 0000000000000018 [ 4.069821] fde0: 003093e9c004ce78 0000000691d6ee76 00000000000010d4 0000000000000019 [ 4.077591] fe00: 00000034b5193519 ffffffc000202800 0000000000001000 0000000000000000 [ 4.085360] fe20: 0000000034d5d91d 0000000000000000 0000000000000000 0000000000000000 [ 4.093129] fe40: 0000000000000000 0000000000000000 0000000000000000 00000000e3c9a290 [ 4.100898] fe60: 0000000000000001 ffffffc0014242e8 ffffffc0bb7bb000 0000000000000005 [ 4.108667] fe80: 0000000000000001 00000000da11ed33 ffffffc0014242e8 ffffffc000200c70 [ 4.116436] fea0: 0000000000000000 ffffffc0fb1efef0 ffffffc000764b74 ffffffc0fb1efef0 [ 4.124205] [<ffffffc000203700>] el1_irq+0x80/0xf8 [ 4.128955] [<ffffffc000764c68>] cpuidle_enter+0x34/0x40 [ 4.134222] [<ffffffc000267bc0>] cpu_startup_entry+0x378/0x3e0 [ 4.140006] [<ffffffc00020de0c>] secondary_start_kernel+0x148/0x154 [ 4.146221] [<0000000040200c5c>] 0x40200c5c [ 4.150368] CPU2: stopping [ 4.153058] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.4.52 #111 [ 4.159106] Hardware name: Mediatek Rowan board (DT) [ 4.164032] Call trace: [ 4.166460] [<ffffffc000208860>] dump_backtrace+0x0/0x160 [ 4.171819] [<ffffffc000208af0>] show_stack+0x20/0x28 [ 4.176833] [<ffffffc0004cf92c>] dump_stack+0x90/0xb0 [ 4.181846] [<ffffffc00020e34c>] handle_IPI+0x194/0x2d0 [ 4.187031] [<ffffffc000200600>] gic_handle_irq+0xa8/0xd0 [ 4.192389] Exception stack(0xffffffc0fb1e3d90 to 0xffffffc0fb1e3ec0) [ 4.198782] 3d80: 00000000e3c95ea8 0000008000000000 [ 4.206560] 3da0: ffffffc0fb1e3ef0 ffffffc000764b78 0000000060000045 0000000000000001 [ 4.214338] 3dc0: 0000000000000000 ffffffc0fb1e0000 ffffffc00078961c 0000000000000018 [ 4.222115] 3de0: 003093e9c004ce78 0000000691d6ee76 00000000000010d4 0000000000000019 [ 4.229893] 3e00: 00000032b5193519 ffffffc000202800 0000000000001000 0000000000000000 [ 4.237669] 3e20: 0000000034d5d91d 0000000000000000 0000000000000000 0000000000000000 [ 4.245445] 3e40: 0000000000000000 0000000000000000 0000000000000000 00000000e3c95ea8 [ 4.253224] 3e60: 0000000000000001 ffffffc0014242e8 ffffffc0bb7baa00 0000000000000002 [ 4.261002] 3e80: 0000000000000001 00000000dc5e4d99 ffffffc0014242e8 ffffffc000200c70 [ 4.268780] 3ea0: 0000000000000000 ffffffc0fb1e3ef0 ffffffc000764b74 ffffffc0fb1e3ef0 [ 4.276557] [<ffffffc000203700>] el1_irq+0x80/0xf8 [ 4.281312] [<ffffffc000764c68>] cpuidle_enter+0x34/0x40 [ 4.286585] [<ffffffc000267bc0>] cpu_startup_entry+0x378/0x3e0 [ 4.292376] [<ffffffc00020de0c>] secondary_start_kernel+0x148/0x154 [ 4.298596] [<0000000040200c5c>] 0x40200c5c [ 4.302746] CPU0: stopping [ 4.305432] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.52 #111 [ 4.311479] Hardware name: Mediatek Rowan board (DT) [ 4.316405] Call trace: [ 4.318832] [<ffffffc000208860>] dump_backtrace+0x0/0x160 [ 4.324192] [<ffffffc000208af0>] show_stack+0x20/0x28 [ 4.329205] [<ffffffc0004cf92c>] dump_stack+0x90/0xb0 [ 4.334218] [<ffffffc00020e34c>] handle_IPI+0x194/0x2d0 [ 4.339404] [<ffffffc000200600>] gic_handle_irq+0xa8/0xd0 [ 4.344762] Exception stack(0xffffffc00135fd30 to 0xffffffc00135fe60) [ 4.351154] fd20: 00000000e3c933b0 0000008000000000 [ 4.358932] fd40: ffffffc00135fe90 ffffffc000764b78 0000000060000145 0000000000000001 [ 4.366710] fd60: 0000000000000000 ffffffc00135c000 ffffffc00078961c 0000000000000018 [ 4.374487] fd80: 003093e9c004ce78 0000000691d6ee76 00000000000010d4 0000000000000019 [ 4.382265] fda0: 00000032b5193519 ffffffc000202800 0000000000001000 0000000000000000 [ 4.390042] fdc0: 0000000034d5d91d 0000000000000000 0000000000000000 0000000000000000 [ 4.397819] fde0: 0000000000000000 0000000000000000 0000000000000000 00000000e3c933b0 [ 4.405597] fe00: 0000000000000001 ffffffc0014242e8 ffffffc0bb7ba600 0000000000000000 [ 4.413374] fe20: 0000000000000001 00000000e0d8c47d ffffffc0014242e8 ffffffc000081198 [ 4.421152] fe40: 0000000004000000 ffffffc00135fe90 ffffffc000764b74 ffffffc00135fe90 [ 4.428929] [<ffffffc000203700>] el1_irq+0x80/0xf8 [ 4.433684] [<ffffffc000764c68>] cpuidle_enter+0x34/0x40 [ 4.438955] [<ffffffc000267bc0>] cpu_startup_entry+0x378/0x3e0 [ 4.444747] [<ffffffc00094ae6c>] rest_init+0x8c/0x94 [ 4.449677] [<ffffffc000e00990>] start_kernel+0x3b4/0x40c [ 4.455036] [<0000000040951000>] 0x40951000 [ 4.459186] CPU3: stopping [ 4.461872] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.52 #111 [ 4.467919] Hardware name: Mediatek Rowan board (DT) [ 4.472845] Call trace: [ 4.475273] [<ffffffc000208860>] dump_backtrace+0x0/0x160 [ 4.480632] [<ffffffc000208af0>] show_stack+0x20/0x28 [ 4.485645] [<ffffffc0004cf92c>] dump_stack+0x90/0xb0 [ 4.490658] [<ffffffc00020e34c>] handle_IPI+0x194/0x2d0 [ 4.495844] [<ffffffc000200600>] gic_handle_irq+0xa8/0xd0 [ 4.501202] Exception stack(0xffffffc0fb1e7d90 to 0xffffffc0fb1e7ec0) [ 4.507596] 7d80: 00000000e3c98b20 0000008000000000 [ 4.515374] 7da0: ffffffc0fb1e7ef0 ffffffc000764b78 0000000060000145 0000000000000001 [ 4.523152] 7dc0: 0000000000000000 ffffffc0fb1e4000 ffffffc00078961c 0000000000000018 [ 4.530929] 7de0: 003093e9c004ce78 0000000691d6ee76 00000000000010d4 0000000000000019 [ 4.538707] 7e00: 00000032b5193519 ffffffc000202800 0000000000001000 0000000000000000 [ 4.546485] 7e20: 0000000034d5d91d 0000000000000000 0000000000000000 0000000000000000 [ 4.554261] 7e40: 0000000000000000 0000000000000000 0000000000000000 00000000e3c98b20 [ 4.562039] 7e60: 0000000000000001 ffffffc0014242e8 ffffffc0bb7bac00 0000000000000003 [ 4.569817] 7e80: 0000000000000001 00000000d955a4c7 ffffffc0014242e8 ffffffc000200c70 [ 4.577594] 7ea0: 0000000000000000 ffffffc0fb1e7ef0 ffffffc000764b74 ffffffc0fb1e7ef0 [ 4.585372] [<ffffffc000203700>] el1_irq+0x80/0xf8 [ 4.590126] [<ffffffc000764c68>] cpuidle_enter+0x34/0x40 [ 4.595400] [<ffffffc000267bc0>] cpu_startup_entry+0x378/0x3e0 [ 4.601190] [<ffffffc00020de0c>] secondary_start_kernel+0x148/0x154 [ 4.607410] [<0000000040200c5c>] 0x40200c5c [ 4.614320] Rebooting in 60 seconds..[DL] 00000000 00000000 010701
,
Apr 18 2017
Commenting out "exec >"${LOG_FILE}" 2>&1" in initramfs/recovery/init keeps all recovery output directed at stdout/stderr.
This shows the actual errors are related to unexecutable shell functions:
+ initialize
+ init_check_clock
+ date +%Y
sh: can't execute 'date': No such file or directory
+ [ -lt 1970 ]
sh: 1970: unknown operand
+ init_mounts
+ mount -n -t proc -o nodev,noexec,nosuid proc /proc
sh: can't execute 'mount': No such file or directory
+ mount -n -t sysfs -o nodev,noexec,nosuid sysfs /sys
sh: can't execute 'mount': No such file or directory
+ mount -t devtmpfs -o mode=0755,nosuid devtmpfs /dev
sh: can't execute 'mount': No such file or directory
... yeah, they are all busybox functions: [date, mount, sed, tail, tee, ...]
,
Apr 18 2017
Issue 712462 has been merged into this issue.
,
Apr 18 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/overlays/portage-stable/+/e8af21c3ce5bf6aba2d5b91469b117e0c9d76df7 commit e8af21c3ce5bf6aba2d5b91469b117e0c9d76df7 Author: Daniel Kurtz <djkurtz@chromium.org> Date: Tue Apr 18 14:13:11 2017 Revert "busybox: upgraded package to upstream" This reverts commit 33a875fc251ce6fb7202d44ecc0be3fe5d2b410f. The above commit breaks recovery images because they cannot find any busybox provided functions: + date +%Y sh: can't execute 'date': No such file or directory + [ -lt 1970 ] sh: 1970: unknown operand + init_mounts + mount -n -t proc -o nodev,noexec,nosuid proc /proc sh: can't execute 'mount': No such file or directory BUG= 712564 TEST=build rowan recovery image => Recovery image boots and performs recovery Change-Id: Ie3e85dcbbfc3c7fcd48da909e01e62c4ba9e4305 Reviewed-on: https://chromium-review.googlesource.com/479594 Commit-Ready: Daniel Kurtz <djkurtz@chromium.org> Tested-by: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> [modify] https://crrev.com/e8af21c3ce5bf6aba2d5b91469b117e0c9d76df7/sys-apps/busybox/files/klogd.initd [delete] https://crrev.com/cbf7777f414cdc54f729982cc0886f83b26e9578/sys-apps/busybox/files/mdev.initd [add] https://crrev.com/e8af21c3ce5bf6aba2d5b91469b117e0c9d76df7/sys-apps/busybox/files/busybox-1.23.1-modprobe-small.patch [modify] https://crrev.com/e8af21c3ce5bf6aba2d5b91469b117e0c9d76df7/sys-apps/busybox/files/watchdog.initd [add] https://crrev.com/e8af21c3ce5bf6aba2d5b91469b117e0c9d76df7/sys-apps/busybox/files/busybox-1.23.1-trylink-flags.patch [rename] https://crrev.com/e8af21c3ce5bf6aba2d5b91469b117e0c9d76df7/sys-apps/busybox/busybox-1.23.1-r1.ebuild [modify] https://crrev.com/e8af21c3ce5bf6aba2d5b91469b117e0c9d76df7/sys-apps/busybox/files/ntpd.initd [delete] https://crrev.com/cbf7777f414cdc54f729982cc0886f83b26e9578/sys-apps/busybox/files/busybox-1.26.2-bb.patch [add] https://crrev.com/e8af21c3ce5bf6aba2d5b91469b117e0c9d76df7/sys-apps/busybox/files/mdev.rc.1 [delete] https://crrev.com/cbf7777f414cdc54f729982cc0886f83b26e9578/metadata/md5-cache/sys-apps/busybox-1.26.2 [modify] https://crrev.com/e8af21c3ce5bf6aba2d5b91469b117e0c9d76df7/sys-apps/busybox/files/syslogd.initd [add] https://crrev.com/e8af21c3ce5bf6aba2d5b91469b117e0c9d76df7/metadata/md5-cache/sys-apps/busybox-1.23.1-r1 [modify] https://crrev.com/e8af21c3ce5bf6aba2d5b91469b117e0c9d76df7/sys-apps/busybox/files/mdev/usbdisk_link [modify] https://crrev.com/e8af21c3ce5bf6aba2d5b91469b117e0c9d76df7/sys-apps/busybox/files/ginit.c [modify] https://crrev.com/e8af21c3ce5bf6aba2d5b91469b117e0c9d76df7/sys-apps/busybox/Manifest [modify] https://crrev.com/e8af21c3ce5bf6aba2d5b91469b117e0c9d76df7/sys-apps/busybox/metadata.xml [add] https://crrev.com/e8af21c3ce5bf6aba2d5b91469b117e0c9d76df7/sys-apps/busybox/files/busybox-1.19.0-bb.patch
,
Apr 18 2017
Well, this is interesting. We don't have tests on recovery images? I'm manually building and deploying a recovery image to see if I can figure out what's wrong. I'll continue that work on https://bugs.chromium.org/p/chromium/issues/detail?id=710074 .
,
Apr 18 2017
> Well, this is interesting. We don't have tests on recovery images? Recovery images are hard to test automatically. While better coverage would be nice (and isn't _impossible_), historically, bugs like this have been too rare to motivate the time and effort needed for testing to find them earlier in the process. :-(
,
Apr 18 2017
Recovery images are tested on some platforms (as part of AUTest I believe), but they haven't been running very reliably in recent times if I look at waterfall now.
,
Apr 18 2017
> Recovery images are tested on some platforms (as part > of AUTest I believe), but they haven't been running > very reliably in recent times if I look at waterfall now. I'm not sure what you're looking at: TTBOMK, there's no automated coverage for recovery images beyond building them. In particular, AU tests don't cover recovery; they cover updates. The lack of reliability of the AU tests is unrelated to any problems with recovery images.
,
Apr 18 2017
Maybe I'm misunderstanding what AUTest exactly tests, because I can see https://.../i/chromeos/builders/oak-release/builds/1060 passing the AUTest. That build corresponds to 9469.0.0 and that's a similar platform.
,
Apr 18 2017
> Maybe I'm misunderstanding what AUTest exactly tests, > because I can see > https://.../i/chromeos/builders/oak-release/builds/1060 > passing the AUTest. That build corresponds to 9469.0.0 > and that's a similar platform. Repeating, just to be clear: AU tests provide no coverage for recovery. They test the auto-update flows, which are completely separate.
,
Apr 18 2017
thanks for clarifying jrbarnette, looks like my last comment crossed timelines with yours, i.e. I didn't pay attention that there was your update before saving my changes...
,
Apr 18 2017
Don't we have platform_InstallRecoveryImage? I remember the AU team writing this a few years back that was supposed to test the recovery image.
,
Apr 18 2017
> Don't we have platform_InstallRecoveryImage? [ ... ] We do. There are at least three impediments to using it. First, it's never been used in the practical environment of the lab, so we have no guarantee it will work as intended. Second, the test relies on a fully working servo. Our current code for diagnosing servo is sufficiently weak that we'd have trouble distinguishing "test failed because of a bad recovery image" from "test failed because of a servo problem," and servos with problems are still common enough that we'd see lots of false failures. Finally, he coverage provided is also somewhat limited; it just tests that the DUT responds to 'ping' after some reasonable time. I _think_ that the test would have been enough to detect this failure, but I don't know whether it would detect the next problem. None of the problems are insurmountable, but again, failures of this sort have been rare enough that no one's been motivated to invest the effort to get better coverage.
,
Apr 18 2017
,
Apr 19 2017
,
Sep 15 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/d27a1a52bb7b7c063f40532b419887237719df49 commit d27a1a52bb7b7c063f40532b419887237719df49 Author: Mike Frysinger <vapier@chromium.org> Date: Fri Sep 15 17:50:32 2017 busybox: turn off static linking We turned this on because it was historically enabled, and because there was a latent bug in the hush wrapper patch. Those should be fixed by the upstream Gentoo 5c7ecf36f0bbbe18b513d7afb82b0f7bf3428 (which we included in CL:489122), so we can drop this again. BUG= chromium:712564 , chromium:710074 , chromium:764753 TEST=precq passes TEST=recovery image still works Change-Id: Ia8de426f7da212ef2970340adfca691d9ebfc553 Reviewed-on: https://chromium-review.googlesource.com/668036 Commit-Ready: Mike Frysinger <vapier@chromium.org> Tested-by: Mike Frysinger <vapier@chromium.org> Reviewed-by: Jason Clinton <jclinton@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> [modify] https://crrev.com/d27a1a52bb7b7c063f40532b419887237719df49/profiles/targets/chromeos/package.use |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by djkurtz@google.com
, Apr 18 2017