add script to mod dev install shim to create a dev recovery image

add script to mod dev install shim to create a dev recovery image

Change-Id: I1333cef94e5157206a464d9505de42707ead10a4

[Tan Gao, 2010-08-02 18:42:42]

Hi Andrew/Nick,

This CL includes a shell script that takes as inputs --
a.) path to a dev install shim (currently piggybacking on a factory install shim
generated by build_image --factory_install, without mod_for_factory scripts)
b.) name of a directory containing dev payloads

and generates a dev recovery image called "dev_recovery_image.bin") in the same
directory as the dev install shim.

A separate CL will be sent to handle the install script issue (e.g. do not use
chromeos-install for dev recovery)

PTAL thx!
Tan

[adlr, 2010-08-02 23:05:41]

http://codereview.chromium.org/3083007/diff/6001/7001
File mod_image_for_dev_recovery.sh (right):

http://codereview.chromium.org/3083007/diff/6001/7001#newcode69
mod_image_for_dev_recovery.sh:69: set -e
should you move to up to right after the flags stuff?

http://codereview.chromium.org/3083007/diff/6001/7001#newcode117
mod_image_for_dev_recovery.sh:117: KERN_IMG=$(mktemp)
can you make this local and echo it at the end?

http://codereview.chromium.org/3083007/diff/6001/7001#newcode118
mod_image_for_dev_recovery.sh:118: sudo cp ${source_img} ${KERN_IMG}
what if there is a mismatch between the kernel size on the rootfs and the one in
the kernel partition? perhaps you should ignore the rootfs here and just make a
dummy file of the exact length needed.

http://codereview.chromium.org/3083007/diff/6001/7001#newcode132
mod_image_for_dev_recovery.sh:132: extract_kernel_image_from_rootfs
then here, KERN_IMG=$(extract_kerne...)

http://codereview.chromium.org/3083007/diff/6001/7001#newcode144
mod_image_for_dev_recovery.sh:144: dd if="${TEMP_KERN}"   of="${TEMP_IMG}"
conv=notrunc bs=512 \
okay, so you are overwriting the kernel partition generated in install_gpt,
right?

http://codereview.chromium.org/3083007/diff/6001/7001#newcode180
mod_image_for_dev_recovery.sh:180: sudo mount -o loop "${TEMP_ROOTFS}"
"${TEMP_MNT_ROOTFS}"
definitely mount this read-only, or you make break vboot. but do you really need
anything on the rootfs?

[Tan Gao, 2010-08-02 23:29:39]

PTAL, thx!

http://codereview.chromium.org/3083007/diff/6001/7001
File mod_image_for_dev_recovery.sh (right):

http://codereview.chromium.org/3083007/diff/6001/7001#newcode69
mod_image_for_dev_recovery.sh:69: set -e
good point .. done

http://codereview.chromium.org/3083007/diff/6001/7001#newcode117
mod_image_for_dev_recovery.sh:117: KERN_IMG=$(mktemp)
On 2010/08/02 23:05:41, adlr wrote:
> can you make this local and echo it at the end?

Done.

http://codereview.chromium.org/3083007/diff/6001/7001#newcode118
mod_image_for_dev_recovery.sh:118: sudo cp ${source_img} ${KERN_IMG}
yes, it's known that kernel size on the rootfs would be smaller than the real
kernel partition (which has all the vboot add-on bits) .. $KERN_IMG is simply
used to compute number of sectors needed to be allocated to kernel partition in
install_gpt() .. not bits are actually copied from $KERN_IMG into the final
kernel partition

http://codereview.chromium.org/3083007/diff/6001/7001#newcode132
mod_image_for_dev_recovery.sh:132: extract_kernel_image_from_rootfs
On 2010/08/02 23:05:41, adlr wrote:
> then here, KERN_IMG=$(extract_kerne...)

Done.

http://codereview.chromium.org/3083007/diff/6001/7001#newcode144
mod_image_for_dev_recovery.sh:144: dd if="${TEMP_KERN}"   of="${TEMP_IMG}"
conv=notrunc bs=512 \
correct. otherwise, we get a kernel overloaded with yet another vboot section
:-(

http://codereview.chromium.org/3083007/diff/6001/7001#newcode180
mod_image_for_dev_recovery.sh:180: sudo mount -o loop "${TEMP_ROOTFS}"
"${TEMP_MNT_ROOTFS}"
Done. the only thing needed from the rootfs is the size of the kernel image
(without vboot bits)

[adlr, 2010-08-03 20:49:17]

http://codereview.chromium.org/3083007/diff/11001/12001
File mod_image_for_dev_recovery.sh (right):

http://codereview.chromium.org/3083007/diff/11001/12001#newcode109
mod_image_for_dev_recovery.sh:109: local
source_img="${TEMP_MNT_ROOTFS}/boot/vmlinuz"
can you make it so you don't mount the rootfs at all? can you just get the
kernel size from the kernel partition?

http://codereview.chromium.org/3083007/diff/11001/12001#newcode180
mod_image_for_dev_recovery.sh:180: sudo mount -o ro,loop "${TEMP_ROOTFS}"
"${TEMP_MNT_ROOTFS}"
yeah, i would really try to get rid of this

[Tan Gao, 2010-08-03 20:55:50]

http://codereview.chromium.org/3083007/diff/11001/12001
File mod_image_for_dev_recovery.sh (right):

http://codereview.chromium.org/3083007/diff/11001/12001#newcode109
mod_image_for_dev_recovery.sh:109: local
source_img="${TEMP_MNT_ROOTFS}/boot/vmlinuz"
hmm .. the kernel partition ("part_2" produced by unpack_partitions.sh) contains
both the kernel image AND the vboot bits, aligned to 4MB boundaries. Unless
there's a more reliable way of estimating/extracting size of the kernel image
(i.e. without vboot bits) than simple subtraction of 4MB, I would not need to
mount rootfs here at all :-(

http://codereview.chromium.org/3083007/diff/11001/12001#newcode180
mod_image_for_dev_recovery.sh:180: sudo mount -o ro,loop "${TEMP_ROOTFS}"
"${TEMP_MNT_ROOTFS}"
agreed, if we have a better alternative :-) see comment above.

[adlr, 2010-08-03 21:03:01]

from chromeos-common.sh

  local num_vboot_sectors=512         # 256K

so, if you get the number of sectors for the current kernel partition, you
should be able to just subtract off 512. Rather than hard-code 512, i would
make a global variable for that (NUM_VBOOT_SECTORS i guess). then, take the
size of the kernel w/ vboot headers, and subtract off $(roundup
NUM_VBOOT_SECTORS). that should get you the length you want.

-andrew

On Tue, Aug 3, 2010 at 1:55 PM, <tgao@chromium.org> wrote:

>
> http://codereview.chromium.org/3083007/diff/11001/12001
> File mod_image_for_dev_recovery.sh (right):
>
> http://codereview.chromium.org/3083007/diff/11001/12001#newcode109
> mod_image_for_dev_recovery.sh:109: local
> source_img="${TEMP_MNT_ROOTFS}/boot/vmlinuz"
> hmm .. the kernel partition ("part_2" produced by unpack_partitions.sh)
> contains both the kernel image AND the vboot bits, aligned to 4MB
> boundaries. Unless there's a more reliable way of estimating/extracting
> size of the kernel image (i.e. without vboot bits) than simple
> subtraction of 4MB, I would not need to mount rootfs here at all :-(
>
>
> http://codereview.chromium.org/3083007/diff/11001/12001#newcode180
> mod_image_for_dev_recovery.sh:180: sudo mount -o ro,loop
> "${TEMP_ROOTFS}" "${TEMP_MNT_ROOTFS}"
> agreed, if we have a better alternative :-) see comment above.
>
>
> http://codereview.chromium.org/3083007/show
>

[Tan Gao, 2010-08-03 22:28:38]

uhh .. never mind, Bill's change (http://codereview.chromium.org/3054041) just
made kernel default to the max size (16MB). Now we don't even need to pass in
any kernel image/stub :-)

[Tan Gao, 2010-08-04 17:53:57]

Hi Andrew,

is this CL ready to go? Thanks!

Tan

[adlr, 2010-08-04 17:58:36]

LGTM