Add a utility to tag/stamp image (deprecated)

THIS CL IS DEPRECATED BY http://codereview.chromium.org/3604001.

Add a utility to tag/stamp image

There are several procedures in Chrome OS post-processing before being released:
stamping, tagging, mod image for URLs, ... and signing.

Signing already has its own script, and we may need an integrated script to
handle all the stamping / tagging.

This CL can handle empty tag files like /root/.force_update_firmware
or /root/.dev_mode.

BUG=none
TEST=manually:
(1) Build a general dev image without firmware updates (default behavior of build_image for x86-generic ToT)
(2) bin/cros_tag_image.sh --from ../../build/images/x86-generic/latest/chromiumos_image.bin
    Expected: output message:
      Update Firmware: disabled
      Developer Mode: Enabled
(3) bin/cros_tag_image.sh --enable_update_firmware --disable_dev_mode \
                          --from ../../build/images/x86-generic/latest/chromiumos_image.bin
    Expected: output message:
      Update Firmware: disabled => Enabled
      Developer Mode: Enabled => disabled

    Manually verify:
      pushd ../../build/images/x86-generic/latest
      unpack_partitions.sh chromiumos_image.bin
      sudo mount -o loop,ro part_3 rootfs
      ls -l rootfs/root/.force_update_firmware # this file should exist
      ls -l rootfs/root/.dev_mode # this file should NOT exist (i.e., error)
      sudo umount rootfs

(4) bin/cros_tag_image.sh --disable_update_firmware --enable_dev_mode \
                          --from ../../build/images/x86-generic/latest/chromiumos_image.bin
    Expected: output message:
      Update Firmware: Enabled => disabled
      Developer Mode: disabled => Enabled

    Manually verify:
      pushd ../../build/images/x86-generic/latest
      unpack_partitions.sh chromiumos_image.bin
      sudo mount -o loop,ro part_3 rootfs
      ls -l rootfs/root/.force_update_firmware # this file should NOT exist (i.e., error)
      ls -l rootfs/root/.dev_mode # this file should exist
      sudo umount rootfs

Change-Id: I0fbce26d9e308d05ee31dbc4c10356c3c9f77c67

[gauravsh, 2010-09-29 03:40:13]

Can you move this to vboot_reference/image_signing/scripts/

Most of the post-processing scripts that we are currently using for stamping
before signing go there.

Or if you think it makes more sense, maybe we should move the post-processing
scripts in vboot_reference to crosutils. What do you think? (look at
set_lsb_description.sh, remove_test_label.sh, etc.)

[Hung-Te, 2010-09-29 07:16:11]

I was also wondering if this script should be in vboot_reference at first.
There are some issues for vboot_reference:
1. It's not checked-out by default in minilayout
2. There's no shflags library
3. The folder is named as "signing" which sounds all related to key signing
issue. 
   Stamping and tagging (which are not related to key signing) sounds better to
be somewhere else.

Then I found cros_sign_to_ssd, cros_update_image and cros_resign_image in
crosutils bin folder, which made me to consider crosutils for "everyone to use"
and wrapped the commands in vboot_reference for sining, and
vboot_reference/scripts for 
"who need to control all the detail of signing".

I'd love to also hear comments from Nick or who handles the releasing of images.
If current process only uses the scripts in crosutils, 
maybe it's better to isolate the stamping/tagging from vboot_reference 
(i.e., move lsb/test labl stuff into crosutils/bin).
Otherwise, we may consider creating a vboot_reference/scripts/stamping folder 
and put lsb/tag/label there. 
It's also OK to merge stamping/signing because they are not really so
different...

[gauravsh, 2010-09-30 02:54:15]

On 2010/09/29 07:16:11, Hung-Te wrote:
> I was also wondering if this script should be in vboot_reference at first.
> There are some issues for vboot_reference:
> 1. It's not checked-out by default in minilayout
> 2. There's no shflags library
> 3. The folder is named as "signing" which sounds all related to key signing
> issue. 
>    Stamping and tagging (which are not related to key signing) sounds better
to
> be somewhere else.
> 

I agree that stamping and tagging are not related to signing. However, the main
problem is that in our workflow, stamping/tagging is a post-processing step that
usually happens to final .bin images before the signing process. In particular,
they are run on hosts which most likely will not have a fully built chroot. That
is the main reason, the scripts under vboot_reference do not have many external
dependencies on any of the common.sh or shflags.sh which are used in crosutils. 

> Then I found cros_sign_to_ssd, cros_update_image and cros_resign_image in
> crosutils bin folder, which made me to consider crosutils for "everyone to
use"
> and wrapped the commands in vboot_reference for sining, and
> vboot_reference/scripts for 
> "who need to control all the detail of signing".

As it so happens, these scripts in turn use the vboot_reference signing scripts.
They are just wrappers around it. 

> 
> I'd love to also hear comments from Nick or who handles the releasing of
images.

I have been handling the releasing of images so far. This includes stamping,
tagging and the final signing. 

> If current process only uses the scripts in crosutils, 
> maybe it's better to isolate the stamping/tagging from vboot_reference 
> (i.e., move lsb/test labl stuff into crosutils/bin).
> Otherwise, we may consider creating a vboot_reference/scripts/stamping folder 
> and put lsb/tag/label there. 
> It's also OK to merge stamping/signing because they are not really so
> different...

That was my idea - to move these scripts to a private git repository as these
will only be used for Google's release process. In the long term, I want to
separate signing from stamping/tagging - crostools.git may be a better for this
to be. That is where all the release build scripts and tools live.

[Hung-Te, 2010-09-30 03:20:34]

I think these scripts are useful to both Google's release process and people who
just want to release their own branch of Chromium OS because they still need to
tag / change AU server for example.

I'll move this script into same folder where set_lsb_description.sh /
remove_test_label.sh exists because these are supposed to be in same level
(tagging / stamping / postprocessing) and in the future if we decide to move
these into crosutils, we can move all these files together.

P.S: I understand scripts in vboot_reference should not depend too much from
chroot environment but shflags is really helpful, what about importing shflags
into vboot_reference scripts folder?

[gauravsh, 2010-09-30 03:34:24]

On Wed, Sep 29, 2010 at 8:20 PM,  <hungte@chromium.org> wrote:
> I think these scripts are useful to both Google's release process and people
> who
> just want to release their own branch of Chromium OS because they still need
> to
> tag / change AU server for example.
>
> I'll move this script into same folder where set_lsb_description.sh /
> remove_test_label.sh exists because these are supposed to be in same level
> (tagging / stamping / postprocessing) and in the future if we decide to move
> these into crosutils, we can move all these files together.
>
> P.S: I understand scripts in vboot_reference should not depend too much from
> chroot environment but shflags is really helpful, what about importing
> shflags
> into vboot_reference scripts folder?

I am fine with that. Thanks!

>
> http://codereview.chromium.org/3421040/show
>



-- 
-g

[Hung-Te, 2010-09-30 04:04:55]

ok, the new one is in http://codereview.chromium.org/3604001
and I also added shflags library there.