cros_make_image_bootable, mount_gpt_image, common.sh: root filesystem changes: ext2, ro by default

cros_make_image_bootable, mount_gpt_image, common.sh: root filesystem changes: ext2, ro by default

This change makes more of the root filesyste metadata static across builds, but
more can be done there.  It also changes the root filesystem to use ext2 as
we don't need journaling in normal mode.  Optionally we could use ext3 for
non-verified if desired (it's an easy change).

In particular, this change cleans up the following:
- clears the rootfs uuid
- labels it C-ROOT (instead of C-KEYFOB)
- removes reserved inodes and blocks

The major feature of this change, however, is that it adds two simple
helpers to common.sh: disable_rw_mount and enable_rw_mount.  They will
set high order byte (le) in the ro compat field to be 0xff.  This will
tell the kernel that the filesystem uses features R24-R31 which are safe
for use on the running kernel iff the filesystem is mounted read-only.

These functions are called in cros_make_image_bootable and
mount_gpt_image, respectively.  mount_gpt_image will always
enable_rw_mount and cros_make_image_bootable will disable_rw_mount if
--enable_rootfs_verification is true.

The approach is ugly but reasonably well contained.  If ext2 ever gets a
new revision and new features in the same range are introduced, then we
would be getting inconsistent behavior.  That said, it is unlikely that
that churmn will happen and if the impact is negative, it will ideally
show up during testing.

N.B., this will likely result in changes needing to be made to the
signing scripts in vboot_reference to ensure that rw mounting is
enabled/disabled in the same way (E.g., during stamping).

BUG=chromium-os:7468
TEST=- built x86-generic, imaged to usb stick, attempted to mount rw /dev/sdc3 on the host and was properly bounced.
     - booted to the image just fine on a dogfood device.
     - mod'd for recovery, then installed and booted.
     - mod_image_for_test runs with no errors; booted the resulting image as well
     - booted a factory_install with the pending dm changes
     - BVT passed with build_image x86-generic (vboot enabled)
     - [in progress] autotest that checks if the rootdev = /dev/dm-0 and
       then does a dumpe2fs | grep -q FEATURE_R31

[Will Drewry, 2010-10-20 04:29:54]

added a few extra people to the cc and review list because they are either
working on related areas or might have some extra thoughts

[Nick Sanders, 2010-10-20 05:56:35]

lg for me w/ addition of comments, gaurav should OK it as well.

http://codereview.chromium.org/3916002/diff/4001/5003
File common.sh (right):

http://codereview.chromium.org/3916002/diff/4001/5003#newcode456
common.sh:456: echo -ne '\xff' |
Maybe some more comments in line with 
# Update re_compat byte in foobar_options table in 
# filesystem header, offset 0x467

http://codereview.chromium.org/3916002/diff/4001/5003#newcode460
common.sh:460: enable_rw_mount() {
Can you add a link to the docs on this?

[Bill Richardson, 2010-10-20 15:52:48]

LGTM, once you've documented the magic incantation as Nick suggested.

BUT: after this goes in, please modify
src/platform/vboot_reference/scripts/image_signing/make_dev_ssd.sh so that the
--remove_rootfs_verification makes the filesystem mountable in rw mode again.

[Bill Richardson, 2010-10-20 15:53:56]

... and either make or file bugs to make the changes to the other signing
scripts that you mentioned. Thanks.

[adlr, 2010-10-20 17:37:58]

interesting hack for the ro mount.

LGTM

[gauravsh, 2010-10-20 19:06:55]

LGTM (and a very neat hack!)

http://codereview.chromium.org/3916002/diff/11001/12002
File build_image (right):

http://codereview.chromium.org/3916002/diff/11001/12002#newcode510
build_image:510: -m 0 \
do you expect any performance effected from changing the reserved block
percentage from the default of 5% to 0%?

http://codereview.chromium.org/3916002/diff/11001/12003
File common.sh (right):

http://codereview.chromium.org/3916002/diff/11001/12003#newcode475
common.sh:475: disable_rw_mount() {
Both these helpers don't have any external dependencies, so my concerns are
addressed (stampers and signers don't have a chroot and need stand-alone
scripts/programs)

[Will Drewry, 2010-10-20 19:11:48]

http://codereview.chromium.org/3916002/diff/4001/5003
File common.sh (right):

http://codereview.chromium.org/3916002/diff/4001/5003#newcode456
common.sh:456: echo -ne '\xff' |
On 2010/10/20 05:56:35, Nick Sanders wrote:
> Maybe some more comments in line with 
> # Update re_compat byte in foobar_options table in 
> # filesystem header, offset 0x467
> 

Done.

http://codereview.chromium.org/3916002/diff/4001/5003#newcode460
common.sh:460: enable_rw_mount() {
On 2010/10/20 05:56:35, Nick Sanders wrote:
> Can you add a link to the docs on this?

Done.

http://codereview.chromium.org/3916002/diff/11001/12002
File build_image (right):

http://codereview.chromium.org/3916002/diff/11001/12002#newcode510
build_image:510: -m 0 \
On 2010/10/20 19:06:55, gauravsh wrote:
> do you expect any performance effected from changing the reserved block
> percentage from the default of 5% to 0%?

I actually just wanted to make sure we use our filesystem to the fullest and not
keep extra blocks laying around for no reason on a ro filesystem.  That said, I
don't think it will have much impact except when we are very close to filling
the fs.  Thieu Le is also working on making the filesystem layout more
consistent across builds -- that will be more beneficial :)

From the man page:
"""
       -m reserved-blocks-percentage
              Set the percentage of the filesystem which may  only  be 
allocated  by  privileged  processes.
              Reserving  some  number  of  filesystem blocks for use by
privileged processes is done to avoid
              filesystem fragmentation, and to allow system daemons, such as
syslogd(8), to continue to func-
              tion  correctly  after  non-privileged  processes are prevented
from writing to the filesystem.
              Normally, the default percentage of reserved blocks is 5%.

"""

http://codereview.chromium.org/3916002/diff/11001/12003
File common.sh (right):

http://codereview.chromium.org/3916002/diff/11001/12003#newcode475
common.sh:475: disable_rw_mount() {
On 2010/10/20 19:06:55, gauravsh wrote:
> Both these helpers don't have any external dependencies, so my concerns are
> addressed (stampers and signers don't have a chroot and need stand-alone
> scripts/programs)

cool

[Will Drewry, 2010-10-20 20:37:52]

On 2010/10/20 15:53:56, Bill Richardson wrote:
> ... and either make or file bugs to make the changes to the other signing
> scripts that you mentioned. Thanks.

Will do. Need to update chromeos-setimage too.