New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 907772 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Nov 30
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

`update_kernel.sh --remote_bootargs` makes kernel unbootable after several iterations due to repeated "cros_secure" settings

Project Member Reported by pihsun@google.com, Nov 22

Issue description

After debugging kernel using update_kernel.sh --remote_bootargs for several times, the kernel refuse to boot.                                                                  

[    0.000000] Kernel command line: cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure cros_secure loglevel=7 init=/sbin/init cros_secure oops=panic panic=-1 root=PARTUUID=2 ...
...
[    0.008309] Kernel panic - not syncing: Too many boot init vars at `cros_secure'

Looks like it's because depthcharge prepends "cros_secure" to the cmdline on boot, and update_kernel.sh reads remote bootargs from /proc/cmdline, which includes the "cros_secure" that depthcharge prepended.

I'm not sure which part should the fix be, should update_kernel.sh filter out cros_secure (or remove duplicates) from remote_bootargs, or should depthcharge not prepending cros_secure if there's already one?
 
Cc: vapier@chromium.org drinkcat@chromium.org
Description: Show this description
Cc: furquan@chromium.org diand...@chromium.org djkurtz@chromium.org groeck@chromium.org
Labels: OS-Chrome
Summary: `update_kernel.sh --remote_bootargs` makes kernel unbootable after several iterations due to repeated "cros_secure" settings (was: `update_kernel.sh --remote_bootargs` makes kernel unbootable after several iterations.)
having update_kernel.sh delete all instances of cros_secure sounds fragile when run on a system whose bootloader doesn't automatically insert it.  but seems reasonable to have it collapse (cros_secure )+ down to a single cros_secure.  that would mean the next boot would have two, but that should be OK.
Owner: pihsun@chromium.org
Project Member

Comment 6 by bugdroid1@chromium.org, Nov 29

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/crosutils/+/0bacb337d5f38ec41dbd941ac31001942a13898e

commit 0bacb337d5f38ec41dbd941ac31001942a13898e
Author: Peter Shih <pihsun@chromium.org>
Date: Thu Nov 29 20:11:20 2018

update_kernel: Remove multiple cros_secure from remote_bootargs.

update_kernel.sh get remote_bootargs from /proc/cmdline, which includes
the 'cros_secure' prepended by depthcharge. This cause the cmdline to
contain multiple instances of 'cros_secure' after multiple run of
`update_kernel.sh --remote_bootargs`, and eventually cause kernel to
refuse to boot because of too long cmdline.

Fix this by removing continuous repeating cros_secure flag from
remote_bootargs in update_kernel.sh.

BUG= chromium:907772 
TEST=manually, run `update_kernel.sh --remote_bootargs` multiple times,
     and see that `cat /proc/cmdline` on DUT still have only two
     cros_secure.

Change-Id: I308043648547cbb5ed6006cc436f56068848ab6a
Reviewed-on: https://chromium-review.googlesource.com/1351176
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Pi-Hsun Shih <pihsun@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/0bacb337d5f38ec41dbd941ac31001942a13898e/update_kernel.sh

Status: Fixed (was: Untriaged)

Sign in to add a comment