[PSA] CrOS SDK Auto-update Enabled by default

[Jack Rosenthal]

Summary

cros_sdk's --update flag is now going to be enabled by default.

What does this mean for me?

Your SDK (the Gentoo-like chroot environment used for building ChromeOS) will auto-update from a tarball each time you enter it, including implicitly, e.g., via cros build-packages.  Here's what you need to know:

• Your boards you're building in the SDK, home directory, and caches will be preserved during an update, as this is stored in a separate out directory.

• You will be asked to exit any open chroot shells during an update.

• The version you update to is specified in sdk_version.conf, so you shouldn't expect an update unless you sync your tree.

• For users with limited network bandwidth requirements, know that the tarball is ~5 GB.  We are working on reducing the size of the tarball, but if your bandwidth requirements are very tight, it's recommended to sync to the stable branch which should see fewer updates.

• If you've manually-emerged packages into the SDK (e.g., via sudo emerge), you'll lose them during an SDK update. You will have to manually re-emerge them on every update, or use the tools outside of the SDK.

Why is this change being made?

Updating the SDK from tarball provides a number of benefits:

• Better stability and reproducibility across environments: instead of initially creating a chroot and keeping it up-to-date for many years, everyone should have a consistent local environment.

• Soon, we'll remove the need to update_chroot, both in CQ and locally, as we'll expect everyone to be using the pinned SDK version.  This will allow for faster builds.

Thanks to the 63 Googlers who helped internally beta-test this feature by opting-in and providing early feedback so we could make sure this feature was ready for everyone to use.

When will this change take effect?

For users on the main branch, this change has already landed.  Users on the stable branch should see it shortly.

Can I opt out?

You can opt-out for a single cros_sdk command by adding --no-update to your command.

We are also temporarily providing a global opt-out.  First, please file feedback so we can understand and address your use case before auto-update becomes mandatory.  Then, run this command to opt-out:

cros_sdk --no-update --update-sticky

If you've run that command and would like to opt-in again, run:

cros_sdk --update --update-sticky

Googlers may have received a duplicate copy of this email on internal lists.  We apologize for the spam!

[Jae Hoon Kim]

I have confirmed that the update works as expected, and that the `--no-update` flag can be used to circumvent the update.

In my workstation, I believe that I had a stale lock or a runaway `cros_sdk` process that was not killed, even with the `killall` command. I had to forcibly remove the file `/usr/local/google/home/kimjae/chromiumos/.chroot_lock`.

In general, the file that needs to be removed is `/usr/local/google/home/$USER/chromiumos/.chroot_lock`.

Without removing this file, the system would hang at the following message:

```

WARNING: Waiting for SDK deletion. If you have SDK shells open, please close them.

```

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
https://groups.google.com/a/chromium.org/group/chromium-os-dev
---
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org.

--

-Jae

[Mike Frysinger]

the warning message strongly indicates there is another process/shell that is still active in the SDK.  deleting the lock file doesn't change that.  are you really sure that nothing else is active on your system inside the existing SDK ?  the lock isn't held because the file exists, the lock is held because a process has an open fd to it.  when the process exits, the lock is automatically freed ... there's no way to leak the lock.

$ cd ~/chromiumos

$ sudo lsof -n -f -- .chroot_lock

hence deleting the lock file in order to delete the SDK is strongly discouraged.

-mike

[Jae Hoon Kim]

On Wed, Mar 13, 2024 at 1:56 AM Mike Frysinger <vap...@chromium.org> wrote:

the warning message strongly indicates there is another process/shell that is still active in the SDK.  deleting the lock file doesn't change that.  are you really sure that nothing else is active on your system inside the existing SDK ?  the lock isn't held because the file exists, the lock is held because a process has an open fd to it.  when the process exits, the lock is automatically freed ... there's no way to leak the lock.

$ cd ~/chromiumos

$ sudo lsof -n -f -- .chroot_lock

I should have investigated which process was holding the lock. (Will keep note of this if it happens again)

I mistakenly assumed that no SDK running was sufficient to release the lock.

 

hence deleting the lock file in order to delete the SDK is strongly discouraged.

I acknowledge that it is discouraged, but I had to delete it in order to continue.

Perhaps a reboot would have sufficed.

--

-Jae