postinst: don't abort after marking new part bootable.

postinst: don't abort after marking new part bootable.

Also, remove &>, which doesn't work in our /bin/sh. The replacement is
2>&1 >

This has the side-effect of working around firmware updates that fail
causing update to fail (which is a spectacularly bad failure mode as
it can lead to bricked machines).

BUG=6947, 6948
TEST=Tested install w/ intentionally borked postinst

Committed: http://chrome-svn/viewvc/chromeos?view=rev&revision=36a47da

[Will Drewry, 2010-09-23 01:57:35]

LGTM

thanks!

http://codereview.chromium.org/3432020/diff/1/3
File chromeos-setimage (right):

http://codereview.chromium.org/3432020/diff/1/3#newcode39
chromeos-setimage:39: if type rootdev 2>&1 > /dev/null; then
change is fine, but I dunno why we do type rootdev after calling rootdev.  The
only reason the type rootdev was in there is because chromeos-setimage used to
be called in the chroot for image_to_vm, and there was no rootdev command. (The
line is pointless now :)

[adlr, 2010-09-23 17:11:52]

On Wed, Sep 22, 2010 at 6:57 PM, <wad@chromium.org> wrote:

> LGTM
>
> thanks!
>
>
> http://codereview.chromium.org/3432020/diff/1/3
> File chromeos-setimage (right):
>
> http://codereview.chromium.org/3432020/diff/1/3#newcode39
> chromeos-setimage:39: if type rootdev 2>&1 > /dev/null; then
> change is fine, but I dunno why we do type rootdev after calling
> rootdev.  The only reason the type rootdev was in there is because
> chromeos-setimage used to be called in the chroot for image_to_vm, and
> there was no rootdev command. (The line is pointless now :)


I'm also not sure why we want this, but in the interest of keeping this CL
focused, I've submitted as is.


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

[Kenneth Waters, 2010-09-23 18:44:11]

Umm, "2>&1 >/dev/null", redirects stderr to stdout, and silences stdout.  I'm
almost positive you want, ">/dev/null 2>&1", which silences both.

[adlr, 2010-09-23 21:36:54]

Thats good to know, and I'll send a fix. Is there a doc somewhere that
explains how these redirections are parsed?

Thanks,
-andrew

On Thu, Sep 23, 2010 at 11:44 AM, <kwaters@chromium.org> wrote:

> Umm, "2>&1 >/dev/null", redirects stderr to stdout, and silences stdout.
>  I'm
> almost positive you want, ">/dev/null 2>&1", which silences both.
>
>
> http://codereview.chromium.org/3432020/show
>

[adlr, 2010-09-23 21:45:19]

[-chromium-os-reviews]

Oh, I think I get it: if you do 2>&1 >somewhere

first, we dup fd1 (the existing stdout) to fd2, then point fd1 to a new
output.

We want to direct fd1 to a new output, then dup that to fd2

On Thu, Sep 23, 2010 at 2:36 PM, Andrew de los Reyes <adlr@chromium.org>wrote:

> Thats good to know, and I'll send a fix. Is there a doc somewhere that
> explains how these redirections are parsed?
>
> Thanks,
> -andrew
>
>
> On Thu, Sep 23, 2010 at 11:44 AM, <kwaters@chromium.org> wrote:
>
>> Umm, "2>&1 >/dev/null", redirects stderr to stdout, and silences stdout.
>>  I'm
>> almost positive you want, ">/dev/null 2>&1", which silences both.
>>
>>
>> http://codereview.chromium.org/3432020/show
>>
>
>

[Kenneth Waters, 2010-09-23 22:09:41]

On Thu, Sep 23, 2010 at 2:44 PM, Andrew de los Reyes <adlr@chromium.org>wrote:

> [-chromium-os-reviews]
>
> Oh, I think I get it: if you do 2>&1 >somewhere
>
> first, we dup fd1 (the existing stdout) to fd2, then point fd1 to a new
> output.
>
> We want to direct fd1 to a new output, then dup that to fd2
>

Yes that's exactly it.  Also from the bash man page,

There are two formats for  redirecting  standard  output  and  standard
       error:

              &>word
       and
              >&word

       Of the two forms, the first is preferred.  This is semantically
equiva‐
       lent to

              >word 2>&1

-- Kenneth Waters