Disable auto-updates?

[Anand]

I'm trying to debug a ChromeOS issue. But whenever I flash my chromebook, as soon as I log in, it tries to auto-update itself. This is making it impossible to repro issues that may trigger on reboot. How can I disable auto-updates?

[Sonny Rao]

there's lots of ways to disable auto updates.

A simple way would be to remove or rename /etc/init/update-engine.conf
which would prevent the updater from ever running.

> --
> --
> Chromium OS Developers mailing list: chromiu...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Chromium OS dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to chromium-os-d...@chromium.org.

[Mike Frysinger]

presumably it's in dev mode ?  switch to the console w/ctrl+alt+f1 and run `stop update_engine`.

if it's not in dev mode, you can't currently.

-mike

On Wed, Feb 17, 2016 at 10:07 PM, Anand <ami...@chromium.org> wrote:

I'm trying to debug a ChromeOS issue. But whenever I flash my chromebook, as soon as I log in, it tries to auto-update itself. This is making it impossible to repro issues that may trigger on reboot. How can I disable auto-updates?

--

[Richard Barnette]

The advice below is good for units running Google-signed images
booted in dev mode.

However, if you boot an image you built yourself, it shouldn't
try and update like that in the first place.

[Marc Herbert]

On Wednesday, 17 February 2016 20:26:26 UTC-8, Mike Frysinger wrote:

presumably it's in dev mode ?  switch to the console w/ctrl+alt+f1 and run `stop update_engine`.

On Wed, Feb 17, 2016 at 10:07 PM, Anand <ami...@chromium.org> wrote:

I'm trying to debug a ChromeOS issue. But whenever I flash my chromebook, as soon as I log in, it tries to auto-update itself. This is making it impossible to repro issues that may trigger on reboot. How can I disable auto-updates?

stop update-engine doesn't seem to help: on first boot without Internet access (e.g., behind a proxy) one still has to wait for a long time while the browser searches for updates and eventually times out. I mean, even after:

stop update-engine

restart ui

... one still has to wait for a long time before being able to login as guest.

On the later boots the "Browse as guest" button lets the user skip this search but not on the first boot since the "Browse as guest" button isn't present yet.

This is especially painful when one has to test a significant number of official builds quickly for an issue that does not require a full Internet connection (= many of them). In fact it's a bit ironic being slowed down by an attempt to upgrade when trying to test very specific build numbers...

Considering I have a one-click ssh shortcut to the (test) image, there should be some simple command(s) I could run to skip this wait, isn't there? Thanks in advance.

[Mike Frysinger]

i think we were talking about generally disabling AU vs messing with the OOBE flow.  iirc there's a flag file that gets created in /var or /home somewhere that says OOBE has happened.  you might be able to touch that to bypass OOBE.

if you have ssh access, you prob could insert some iptables rules to outright reject connections instead of letting them time out ...

-mike

[Kevin Cernekee]

On Tue, Apr 19, 2016 at 1:07 PM, Mike Frysinger <vap...@chromium.org> wrote:
> i think we were talking about generally disabling AU vs messing with the
> OOBE flow. iirc there's a flag file that gets created in /var or /home
> somewhere that says OOBE has happened. you might be able to touch that to
> bypass OOBE.

When I've wanted to do the opposite (force the system to repeat OOBE)
I've deleted /home/chronos/{.oobe_completed,Local\ State}

Maybe restoring those files from known-good backups will bypass OOBE,
but I haven't tried it. It is possible that other critical stuff gets
generated during OOBE.

> if you have ssh access, you prob could insert some iptables rules to
> outright reject connections instead of letting them time out ...

You could try changing CHROMEOS_AUSERVER in /etc/lsb-release to e.g.
http://127.0.0.1:8080/ and see if that fails more quickly.

Modifying other fields in that file, such as CHROMEOS_RELEASE_BOARD or
CHROMEOS_RELEASE_TRACK, should also cause the AU server to reject your
requests. But if you really need to run on an isolated network that
won't help much.

[Marc Herbert]

On Tuesday, 19 April 2016 13:50:35 UTC-7, Kevin Cernekee wrote:

On Tue, Apr 19, 2016 at 1:07 PM, Mike Frysinger <vap...@chromium.org> wrote:
> i think we were talking about generally disabling AU vs messing with the
> OOBE flow.  iirc there's a flag file that gets created in /var or /home
> somewhere that says OOBE has happened.  you might be able to touch that to
> bypass OOBE.

When I've wanted to do the opposite (force the system to repeat OOBE)
I've deleted /home/chronos/{.oobe_completed,Local\ State}

Maybe restoring those files from known-good backups will bypass OOBE,
but I haven't tried it.  It is possible that other critical stuff gets
generated during OOBE.

Thanks for the very quick response and the leads; thanks to them it looks like I have at last a dirty hack that seems to do the job:

dut=root@fe80::1234:c6ff:fe88:5678%eth1

ssh $dut stop ui

ssh $dut sed -i -e 's#^{#{\"EulaAccepted\":true,\"OobeComplete\":true,#' /home/chronos/Local?State

ssh $dut start ui

I'll script and keep using this and report here again future issues if any.

Barely tested yet so usual disclaimers apply; this may burn your board, don't use at home, etc.

 

> if you have ssh access, you prob could insert some iptables rules to
> outright reject connections instead of letting them time out ...

You could try changing CHROMEOS_AUSERVER in /etc/lsb-release to e.g.
http://127.0.0.1:8080/ and see if that fails more quickly.

I haven't tried this one; I fear it will do only half the job.

Marc

[Sam Stowell]

I have a question on this as well, I just recently rollback my chrome os itself. I have a Dell Chromebook 13, and once I rolled it back after a couple of restarts it asked at the bottom right to restart to update. Is there a way that I can completely remove that or not have it update at all?

Thank you!

[Mike Frysinger]

if it's in verified mode, then you can only disable updates via the admin console for enrolled devices

if it's in dev mode, then follow the insns posted earlier in this thread

-mike

On Tue, Feb 28, 2017 at 12:50 AM, Sam Stowell <sasto...@damien-hs.edu> wrote:

I have a question on this as well, I just recently rollback my chrome os itself. I have a Dell Chromebook 13, and once I rolled it back after a couple of restarts it asked at the bottom right to restart to update. Is there a way that I can completely remove that or not have it update at all?

Thank you!

[Mike Frysinger]

stopping update engine only works once.  when you reboot, it'll start up again.

if you want to stop it more permanently, you'd have to disable rootfs verification and then manually delete the init script.

/usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification

-mike

On Fri, Mar 10, 2017 at 9:38 PM, Sam Stowell <sasto...@damien-hs.edu> wrote:

My Chrome Book is in dev mode as of right now, Ive used the command
before and restarted it and I didn't see anything about updating it.
How do you get into verified mode and what is verified mode? I don't
know how to use the admin console for enrolled devices, and Ive used G
Suite before through google and some of the directions for disabling
auto updates after reboots are not in G Suite for some reason. Would
setting the channel to Beta work as well for not having updates? I
heard there is some problems with Beta channel for having custom
wallpapers and they disappear after every reboot. Sorry for the late reply as well, and please let me know more about this and what you mean by verified mode since I am confused. 

[Sam Stowell]

How do you delete it permanently through rootfs and manually deleting the init script.