Setting rootfs writable forces recovery

[Andrew Dahl]

Chrome OS Version: 41.0.2272.76 (64-bit) 

Chromebook Model: Chromebook Pixel 2015 (Samus)

Issue description: 

Two things, and I believe they both do the same thing:

The "Enable debugging features" option and the make_dev_ssd.sh --remove_rootfs_verification --force command are not working as intended.

With developer mode enabled, I click on the "Enable debugging features" link on the bottom left of the first menu on boot, where you setup your wifi and such.  After clicking it, it warns me, I hit Proceed, the machine reboots.  I hit CTRL+D to get by the dev screen, it reboots again and comes up to the "Chrome OS is missing or damaged." screen.  Recovering from there works fine. 

I've also tried running "sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --force" from the shell it yields the same results.

This is from running the command on the shell:

[Andrew Dahl]

I checked the reason after going the "Enable debugging features" route, and the error is identical.

[Chirantan Ekbote]

Maybe try not using the --force flag?  I'm guessing that removing rootfs verification doesn't play well with having the dev_boot_signed_only flag set.

--
--
Chromium OS discuss mailing list: chromium-...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

[Andrew Dahl]

The alternative is to run 

make_dev_ssd.sh --remove_rootfs_verification --partitions 2
make_dev_ssd.sh --remove_rootfs_verification --partitions 4

I believe the result is the same.  The --force is required if you don't specify the partition though.  (Otherwise it just tells you to specify a partition and that it didn't do anything)

I'll look into setting dev_boot_signed_only to 0 though and give it another try.  Is that as simple as crossystem dev_boot_signed_only=0 ?

[Andrew Dahl]

That was it!  Thank you very much, Chirantan!

Solution:
sudo crossystem dev_boot_signed_only=0

[DennisLfromGA]

That is some great info. - thanx much!

I plan to get the Pixel 2 LS hopefully sometime this year and I will definitely be using it in Developer mode so this is invaluable.

Thinking back to problems some chromebox users had when trying to set rootfs as rw, this may be their solution too.

[Andrew Dahl]

Definitely!  I recall the same issue on my original Pixel too, but I had forgotten all about setting dev_boot_signed_only=0 -- I imagine that's the issue most people have here.

A bigger concern is that using "Enable debugging features" on start-up forces a restore because that doesn't set dev_boot_signed_only=0 -- of course, I'm unaware of the intent there, so maybe they're just expecting you know to set it prior to enabling the debugging features.

[DennisLfromGA]

Yep, I don't really understand it. 

I know 'make_dev_ssd.sh' rewrites the partition but I thought it would still be Google signed, not private signed so I don't know why the 'dev_boot_signed_only' switch has to be set to 0.

[Richard Barnette]

make_dev_ssd.sh removes all root verification, which means the
image no longer has a valid Google signature. In general,
anything that modifies the root partition will mean that the
device no longer passes verification checks.

--jrb

[DennisLfromGA]

Richard,

Okay, I kind'a get that but it really begs the question: Why did Google introduce "Enable debugging features" and not take care of the 'dev_boot_signed_only' switch.

[Hung-Te Lin]

Did you manually set dev_boot_signed_only before?
I thought dev_boot_signed_only should be default 0.

Maybe we can let make_dev_ssd.sh to check/set that flag as well in future.

--

--
Chromium OS discuss mailing list: chromium-...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dis...@chromium.org.

[Andrew Dahl]

I did not.  The only thing I did was put my Pixel in dev mode.  When I checked the value of dev_boot_signed_only, it was 1.  After setting it to 0, everything worked as expected.

[DennisLfromGA]

I think the default is '1' in non-dev mode and '0' in dev mode so maybe it's not getting 'set' when implementing the new "Enable debugging features" option.

There's been some discussion of this switch on the 'crouton' site that might shed some more light on this issue - see https://github.com/dnschneid/crouton/issues/765#issuecomment-40454485

[Andrew Dahl]

If this is still an issue (crouton setting dev_boot_signed_only to 1), which it looks like it is, I do believe I installed crouton before trying to remove rootfs verification, so that would explain this issue.

Checking the flag through the "Enable debugging features" would likely be a good idea though, if only to protect against users or applications (e.g. crouton) mucking things up.

[Hung-Te Lin]

2015-03-18 11:58 GMT+08:00 DennisLfromGA <denny.l...@gmail.com>:

I think the default is '1' in non-dev mode and '0' in dev mode so maybe it's not getting 'set' when implementing the new "Enable debugging features" option.

   The firmware clearly sets that value as default zero. Non-dev mode does not loot at that value (the flag's name tells that: it's only for dev_boot).

   So it's not caused by the new option.

 

There's been some discussion of this switch on the 'crouton' site that might shed some more light on this issue - see https://github.com/dnschneid/crouton/issues/765#issuecomment-40454485

   Seems like it's crouton who sets the bit to 1.

 

On Tuesday, March 17, 2015 at 11:35:20 PM UTC-4, Hung-Te Lin wrote:

Did you manually set dev_boot_signed_only before?
I thought dev_boot_signed_only should be default 0.

Maybe we can let make_dev_ssd.sh to check/set that flag as well in future.

[DennisLfromGA]

Andrew,

I just checked the latest version of 'crouton' and it sets the 'dev_boot_signed_only' switch to 1 unless 'dev_boot_usb' is 1 or 'dev_boot_legacy' is 1.

So it looks like 'crouton' may have been the culprit in your case. :(

It also supports the idea of checking that switch when enabling debugging features.

[DennisLfromGA]

@Hung-Te Lin,

Thanx very much for the confirmation.

And thanx the explanation of the 'dev_boot_' naming convention - it makes a whole lot of sense ( now ;).

[Richard Barnette]

On 3/17/15 8:34 PM, Hung-Te Lin wrote:
> Did you manually set dev_boot_signed_only before?
> I thought dev_boot_signed_only should be default 0.
>
> Maybe we can let make_dev_ssd.sh to check/set that flag as well in future.
>
> 2015-03-18 10:40 GMT+08:00 DennisLfromGA <denny.l...@gmail.com

> <mailto:denny.l...@gmail.com>>:

>
> Richard,
>
> Okay, I kind'a get that but it really begs the question: Why did
> Google introduce "Enable debugging features" and not take care of
> the 'dev_boot_signed_only' switch.
>

I think Hung-Te's answer more or less covers the why: The
system is complicated enough that bugs of this sort can
creep in.

Changing make_dev_ssd.sh to force dev_boot_signed=0 seems
highly desirable, and should be roughly a one-line change.
If you're impatient for the fix, patches are always welcome.

> On Tuesday, March 17, 2015 at 3:58:05 PM UTC-4, Richard Barnette wrote:
>
> On 3/17/15 12:44 PM, DennisLfromGA wrote:
> > Yep, I don't really understand it.
> > I know 'make_dev_ssd.sh' rewrites the partition but I thought
> it would
> > still be Google signed, not private signed so I don't know
> why the
> > 'dev_boot_signed_only' switch has to be set to 0.
> >
> >
> make_dev_ssd.sh removes all root verification, which means the
> image no longer has a valid Google signature. In general,
> anything that modifies the root partition will mean that the
> device no longer passes verification checks.
>
> --jrb
>
> --
> --
> Chromium OS discuss mailing list: chromium-...@chromium.org

> <mailto:chromium-...@chromium.org>

> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en
>
> To unsubscribe from this group and stop receiving emails from it,
> send an email to chromium-os-dis...@chromium.org

> <mailto:chromium-os-dis...@chromium.org>.

>
>
> --
> --
> Chromium OS discuss mailing list: chromium-...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en
>

--
--jrb

[Richard Barnette]

On 3/17/15 8:34 PM, Hung-Te Lin wrote:

> Did you manually set dev_boot_signed_only before?
> I thought dev_boot_signed_only should be default 0.
>
> Maybe we can let make_dev_ssd.sh to check/set that flag as well in future.
>
> 2015-03-18 10:40 GMT+08:00 DennisLfromGA <denny.l...@gmail.com

> <mailto:denny.l...@gmail.com>>:

>
> Richard,
>
> Okay, I kind'a get that but it really begs the question: Why did
> Google introduce "Enable debugging features" and not take care of
> the 'dev_boot_signed_only' switch.
>

I think Hung-Te's answer more or less covers the why: The
system is complicated enough that bugs of this sort can
creep in.

Changing make_dev_ssd.sh to force dev_boot_signed=0 seems
highly desirable, and should be roughly a one-line change.
If you're impatient for the fix, patches are always welcome.

> On Tuesday, March 17, 2015 at 3:58:05 PM UTC-4, Richard Barnette wrote:
>
> On 3/17/15 12:44 PM, DennisLfromGA wrote:
> > Yep, I don't really understand it.
> > I know 'make_dev_ssd.sh' rewrites the partition but I thought
> it would
> > still be Google signed, not private signed so I don't know
> why the
> > 'dev_boot_signed_only' switch has to be set to 0.
> >
> >
> make_dev_ssd.sh removes all root verification, which means the
> image no longer has a valid Google signature. In general,
> anything that modifies the root partition will mean that the
> device no longer passes verification checks.
>
> --jrb
>
> --
> --
> Chromium OS discuss mailing list: chromium-...@chromium.org

> <mailto:chromium-...@chromium.org>

> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en
>
> To unsubscribe from this group and stop receiving emails from it,
> send an email to chromium-os-dis...@chromium.org

> <mailto:chromium-os-dis...@chromium.org>.

>
>
> --
> --
> Chromium OS discuss mailing list: chromium-...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en
>

--
--jrb

[DennisLfromGA]

@Richard Barnette,

Thanx for your earlier explanation of a signed and un-signed rootfs.

I can see why removing rootfs verification could compromise it and therefore could not be signed or verified by Google.

Also, since we do sometimes experiment with things like 'crouton' that can programmatically change things,

( In 'crouton's defense, they do issue a warning that the flag is being set and gives instructions on how to unset it. )

it indeed makes sense to at least check that switch and set it if necessary - like Hung-Te suggested.

I don't have the Pixel 2 LS yet, still saving up, so I can wait for a patch I think.

Besides, any patch I might devise might make things worse ;)

On Wednesday, March 18, 2015 at 11:49:41 AM UTC-4, Richard Barnette wrote:

On 3/17/15 8:34 PM, Hung-Te Lin wrote:

I think Hung-Te's answer more or less covers the why:  The
system is complicated enough that bugs of this sort can
creep in.

Changing make_dev_ssd.sh to force dev_boot_signed=0 seems
highly desirable, and should be roughly a one-line change.
If you're impatient for the fix, patches are always welcome.

--
--jrb

Thanx again,

-DennisL

[Chirantan Ekbote]

Here you go: https://chromium-review.googlesource.com/#/c/260970/