BTW, the --bootloader for vbutil_linux is not used by Depthcharge, so you can give it a dummy file (size>0).

With that, we can simplify the process of "prepare kernel package" to
 1. get /build/$BOARD/packages/sys-kernel/chromeos-kernel-* and linux-firmware-*
 2. extract and remove usr/lib/debug/boot*
 3. tar and upload to DUT
 4. tar to extract at /

5. vbutil_kernel --pack kernel.bin \
 --keyblock /usr/share/vboot/devkeys/kernel.keyblock \
 --signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \
 --version 1 --vmlinuz PATH_TO/boot/vmlinuz --bootloader DUMMY_FILE \
 --config CONFIG_FILE --arch x86_64

arch = x86_64, x86, arm, arm64 (?)

> - Update test partition kernel, with modules.

One issue is that self-built kernels and prebuilt ones usually expect kernel modules to be in different path (i.e. /lib/modules/4.4.X vs /lib/modules/4.4.X-githash), so it's going to be hard to change the kernel without patching the rootfs...

Now, if we can add/changes files in rootfs, it'd be great to be able to change others things (I'm thinking audio configuration, touchpad/screen FW, etc.)

> Updating modules implies we need to disable rootfs verification (which may create lots of new problems in suspend/resume and reboot tests), disable lsm module locking, also userland programs may not work properly.

I wouldn't expect that many issues (we do it all the time during bringup, precisely to be able to update kernel, and cros deploy specific packages), but I'm not familiar with what factory flow/tests expect.

> Now, if we can add/changes files in rootfs, it'd be great to be able to change others things (I'm thinking audio configuration, touchpad/screen FW, etc.)

That can be patched by adding mount --bind in factory init for a long time.

> I wouldn't expect that many issues

We did see that failure on many projects, when you start running long time stress tests with reboot. Many ChromeOS processes were designed in the concept that rootfs is read-only.

Usually for those projects, they will try to update kernel at the last minute and adjust test plan so run-in can be tested with original kernel.

Meanwhile, Stimim mentioned that Gale has also used update_kernel a lot so we are now putting this to supported feature again, since run-in may be not very important in proto or EVT builds.

@phoenix, from how we used this in the ongoing build by Duncan, I think it may be more convenient if there's a way to provide "modifying command line" without the need of giving whole command line, for example

  kernel_config_add and kernel_config_remove

or a kernel_config_re_sub (to perform re.sub)

What do you think?

kernel_config_add and kernel_config_remove sounds good if it's easy to parse.
I'll try it.

ToT update_kernel already have these features.