Newer git ebuilds have decided that the "git-prompt" script isn't really
bash completion so stopped installing it via that mechanism. Instead it
installed it started installing it in /usr/share/docs which gets
compressed by default and the path is based on ebuild version. The path
changed again in 1.9.3 to /usr/share/git and didn't compress it so that
makes it actually possibly usable but 1.9.3 or later isn't stable yet.
We can re-enable it the next time git gets updated but not worth fussing
over the current brokenness right now.
Using parallel_emerge has been disabled by default for all commands
except build_image for quite a while now, build_image kept it just
because it was still a bit faster than normal emerge. Keeping
parallel_emerge complicates future changes to build_image so it needs to
drop it entirely. Since that means nothing uses it by default we might
as well just rip out support for it entirely.
Previously /etc/os-release was installed both by set_lsb_release and
the baselayout package. Now it is only installed by set_lsb_release but
when baselayout is upgraded it removes /etc/os-release. So the first
update_chroot works but the second detects the chroot's version
incorrectly and tries to apply the one time updates in this directory.
Both of them are very old so we can just delete them. The second run
will now fix up /etc/os-release and we can all move on and be happy.
The host system's PATH may not be match the one required by the SDK.
When going through the enter_chroot script it gets reset because bash is
invoked as a login shell but this doesn't happen when using the plain
old chroot command.
Fixes https://github.com/coreos/scripts/pull/290
There is no need to arbitrarily bind mount all of the host system's /run
into the chroot. In fact this causes issues when the host system's /run
isn't set up in a way this script anticipates. Namely the user runtime
directory in /run/usr/$UID is another tmpfs mount on my system, leaving
the underlying directory node that is bind-mounted in with the wrong
ownership. Behave a little more like a responsible container and use a
fresh /run but continue binding /run/shm for whatever versions of Ubuntu
that depended on that behavior. Not strictly needed but go ahead and
create the user runtime directory with the correct permissions.
- Don't copy known_hosts if it doesn't exist.
- Don't bother with copying *.pub, not sure what that was for.
- Don't rewrite .ssh/config to remove internal Google ssh options.
The main case here is /etc/hosts does not exist on CoreOS. In the
process combine related and duplicate code. Setting the timezone now
happens in entire_chroot like hosts and resolv.conf. Don't bother with
setting a default UTC time zone, that is already the default.
- Automated builds drop SDK and binary packages into
gs://builds.developer.core-os.net/ and the new download URL is
http://builds.developer.core-os.net/ (COREOS_DEV_BUILDS)
- Change default upload path to gs://users.developer.core-os.net/ for
misc developer builds. Official builds go elsewhere and will just be
configured in buildbot/jenkins so some COREOS_OFFICIAL stuff is gone.
- Automated builds of images go to a private bucket,
gs://builds.release.core-os.net which later gets copied to
gs://alpha.release.core-os.net and friends by core_promote.
To behave more like setup_board/build_packages update_chroot should
fully configure portage to make sure everything is accurate.
Now binhosts are defined in make.conf.host_setup so the static config in
coreos-overlays doesn't need to refer to version.txt. setup_board
already made this change in 7a43a07f.
Define path locations to reduce dependency between static configs in
coreos-overlays and the behavior of the scripts repo. Spreading
configuration across two repos makes everything harder to understand.
Eventually everything should either be defined in profiles in
coreos-overlays or minimal auto-generated config files here in scripts.
For the most part this doesn't influence anything. The one exception is
the custom configuration for using curl is dropped, just rely on the
portage defaults. It appears curl was only used to work around a wget
issue with Google's internal SSL certificates. We care not. :)
The commands useradd/usermod will silently skip adding users to
secondary groups that are not in /etc/group. The idea being that the
tools should not create groups that conflict with existing LDAP/NIS
groups but why trying to do so isn't a fatal error I don't know.
Overall the code is rather complicated and tries to modify instead of
add when possible to allow running the SDK as the 'core' user. To keep
things simple gut this code, make the 'core' user special, and add
secondary groups via the 'gpasswd' command so that errors are reported
instead of silently ignored.
One functional change: the default groups have changed to kvm and
portage. The old list excluded kvm and included lots of extra cruft.
Make it possible for other scripts to share the same value for our
release repository and equally easy to override with a custom value.
Also allow setting the root from the command line in addition to the
environment. Usually --upload_root is better to use than --upload_path.
This makes it possible to toggle parallel_emerge just as other scripts
do. In other scripts update the help string to be more specific, the
--jobs option can be used to control parallelism.
Instead of handling toolchain packages in make_chroot and telling
update_chroot to skip the toolchains just depend on update_chroot to do
it properly. Reduces our code duplication by a tiny but worthwhile bit.
The current logic for downloading SDK tarballs is in cros_sdk and
written in python which isn't super convenient for re-using in the rest
of our shell scripts. This is a start of rewriting that logic into a
re-usable library but does not yet replace the functionality in cros_sdk.
We've had trouble with eclean and equery vanishing in our SDKs from time
to time. Although I don't know the root cause it seemed to be some
confusion in the ebuild environment, perhaps a mis-match between the
eclasses, profiles, and ebuilds. Updating all of those seemed to resolve
the issue and to make sure other environments are ok force a re-install
of portage and gentoolkit to clean things up.
When a user creates a chroot and as a common primary group such as
'users' the groupadd command fails. Instead treat this the same as users
and only fail if the group exists but has a different (such as the
'users' group not using GID 100). Hopefully this works better.
If the user already exists check that the UID and GID are correct and
modify it (setting shell and home directory) to match what the SDK
expects. This avoids needlessly failing if the user calling cros_sdk is
the 'core' user on a CoreOS machine.
Change new-user creation to copy the user's full name and group instead
of using a generic name and Google's 'eng' group. Also remove the
default password for the account, it isn't needed and uses perl.
The old chroot version system we inherited from Chromium OS always
assumes that a newly unpacked tarball is the latest and greatest but
since we version the SDK in the same way as target builds we can use
that version for these sorts of upgrade scripts and not make assumptions
about how late and great the starting tarball was.
The first upgrade script simply aborts to force the user to recreate
their chroot when moving from python 2.6 to 2.7.
Our SDK tarballs aren't compressed using pbzip2 so there is no advantage
to using pbzip2 to decompress them over bzip2, however lbzip2 does offer
a big advantage. Also trust that the portage config defines a valid
version of bzip2 since we have control over the tarball creation and can
make sure to always include required utilities.
The existing code seems to assume that the mounts inherited from the
system are private, the Linux default. However on our systems that
clearly isn't the case, all system mounts are set as shared. Considering
all of us have been have been seeing mounts leak out of the SDK despite
cros_sdk creating a new filesystem namespace via unshare I'm guessing
this is a systemd thing.
Instead force all system mounts to 'slave' mode in the SDK namespace so
global changes are still visible but no SDK mounts can leak out.
Already did this for catalyst builds but might as well do it for all.
With this competing builds on the same host should be a little
friendlier to each other.
Half of the current time is spent on calling locale-gen even when there is
nothing to be done (all locales already generated). Throw it into the bg
to unblock the main thread.
BUG=None
TEST=`cros_sdk` still works
TEST=`LANG=et_EE.UTF-8 cros_sdk` generates the new locale in the background
Change-Id: Ibe9a07bec60a59cab1cf4230358f7f8ff5b21c2e
Reviewed-on: https://gerrit.chromium.org/gerrit/58041
Reviewed-by: David James <davidjames@chromium.org>
Commit-Queue: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
All devpts mounts are actually shared, even if you do:
mount -t devpts none /dev/pts
mount -t devpts none /mnt/foo
mount -t devpts none /mnt/asdfasdf
These all provide the same data.
This is problematic because most distros mount their host devpts like so:
mount -t devpts devpts /dev/pts -o mode=620,gid=5
But when cros_sdk runs, it uses:
mount -t devpts none /dev/pts
We aren't specifying a mode/gid, so it ends up using the defaults, and
this resets the host devpts mount as well.
Since we've already assumed that the system has devpts available, it's
fine to also assume that the system has it mounted at /dev/pts and we
can simply bind mount it.
BUG=None
TEST=`cros_sdk` no longer messes up host perms on /dev/pts
Change-Id: Ib594fc5e47707f296d97ac1edce32659ed2b2273
Reviewed-on: https://gerrit.chromium.org/gerrit/48018
Reviewed-by: Steev Klimaszewski <threeway@gmail.com>
Reviewed-by: David James <davidjames@chromium.org>
Commit-Queue: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
I use a mount at src/build/images to stop image builds from repeatedly
filling up my SSD. The chroot needs to respect this.
TEST=cros_sdk
BUG=none
Change-Id: I5c7a26c3b4f263bd683d3a897e6edccb83187bda
Reviewed-on: https://gerrit.chromium.org/gerrit/47178
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Queue: Michael Spang <spang@chromium.org>
Tested-by: Michael Spang <spang@chromium.org>
Newer Gentoo builds have moved to /run which means /var/lock is a symlink
to /run/lock. But since that is an absolute symlink, it points outside of
the chroot which doesn't work for us. Use a stable path unrelated to the
chroot instead, but only with newer chroots.
We no longer have to worry about backwards compat because the code that
used to rely on this lock file (running sync processes) was punted a long
time ago.
BUG=chromium:218085
TEST=`cbuildbot chromiumos-sdk` passes
Change-Id: I38c6848dfb86386849050d7ccf3f90cbbe8e0e81
Reviewed-on: https://gerrit.chromium.org/gerrit/46231
Reviewed-by: David James <davidjames@chromium.org>
Commit-Queue: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
This patch installs "socat" and a proxy gateway script into
the chroot so that git can use a proxy to access "git://"
protocol urls. This is needed when performing builds from
behind a firewall that requires a proxy. The script reads
the proxy environment variables all_proxy (SOCKS),
https_proxy (CONNECT), and http_proxy (CONNECT), in order of
preference, and supports no_proxy as a whitelist of target
hosts that must NOT go through the proxy.
This also updates enter_chroot.sh to automatically use this
script as GIT_PROXY_COMMAND when it sees the proxy
environment variables set.
The "socat" program is added to hard-host-depends as a
separate patch. That handles socat installation in case of
building a chroot from scratch or upgrading.
The proxy-gw script is installed in the src/scripts/bin
directory which can be stably referenced within the chroot
as /mnt/host/source/src/scripts/bin/. The
"/mnt/host/source" portion of this path is obtained from the
CHROOT_TRUNK_DIR environment variable which is set to a
suitable value by preexisting logic in common.sh.
This change became necessary to unbreak builds behind
proxies with the recent addition of two ebuilds using
egit.eclass with repositories using git:// URLs.
Original patch by Paul Drews <paul.drews@intel.com>;
modified version by Josh Triplett <josh@joshtriplett.org>.
CQ-DEPENDS=I1b01bce6f3e6a562b87f748e61508d142af576d9
BUG=none
TEST=git clone git://nv-tegra.nvidia.com/tools/cbootimage.git
Change-Id: Ic7fc917d1aa24f408bef6f102b6458114dded694
Reviewed-on: https://gerrit.chromium.org/gerrit/41659
Tested-by: paul drews <paul.drews@intel.com>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Queue: paul drews <paul.drews@intel.com>
In an Ubuntu Precise chroot on the Chromebook Pixel, /run/shm is a
symbolic link to /dev/shm, so bind-mounting /run/shm to /dev/shm
is really bind-mounting /dev/shm to itself, which causes a 'too many
levels of symbolic links' error. To fix this, we check for a symbolic
link prior to running this command.
BUG=none
TEST=cros_sdk no longer prints errors on Chromebook Pixel
Change-Id: Ib46cde2b4a0e00b69bd187488967e445b228ae80
Reviewed-on: https://gerrit.chromium.org/gerrit/45048
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Queue: David James <davidjames@chromium.org>
Tested-by: David James <davidjames@chromium.org>
If ~/.subversion doesn't exist, the code didn't run, but if it existed
there is no reason to re-create it, nor is it necessary to change its
permissions since they are inherited by the bind mount source.
However user_mkdir was trying to run chown as root which does not work
over NFS with root_squash or krb-nfs.
Therefore, the un-needed call to user_mkdir is removed.
(this is an issue because cros_sdk --replace does call this code path
multiple times).
BUG=None
TEST=Built the chroot, and the permission denied on 'install' went away.
Change-Id: I01e9a7baf51a99a96d790c9613e26e652379e6df
Reviewed-on: https://gerrit.chromium.org/gerrit/44880
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Queue: Marc MERLIN <merlin@chromium.org>
Tested-by: Marc MERLIN <merlin@chromium.org>
If our sdk has an /etc/mtab file already, then clobber it. This fixes
build problems where chromeos-base now installs /etc/mtab for us, but
the sdk build isn't expecting it leading to the error:
INFO cros_sdk:make_chroot: Running init_setup()...
ln: creating symbolic link `/b/cbuild/new-sdk-chroot/etc/mtab': File exists
Running ['/b/cbuild/src/scripts/sdk_lib/make_chroot.sh', '--stage3_path',
'/b/cbuild/built-sdk.tar.xz', '--chroot', '/b/cbuild/new-sdk-chroot',
'--cache_dir', '/b/cbuild/.cache', '--nousepkg'] failed!
BUG=None
TEST=`cros_sdk --chroot foo` still works
Change-Id: I539cf329e93e28534e6ff00577ce415d76918b85
Reviewed-on: https://gerrit.chromium.org/gerrit/43641
Reviewed-by: David James <davidjames@chromium.org>
Commit-Queue: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
As-is all of the various emerge wrapping scripts default to using
--getbinpkg whenever --usepkg is enabled. This means every single emerge
command made makes multiple synchronous HTTP requests to the upstream
binary package repository to get the latest package list. This gets
really frustrating when working remotely with limited network
connectivity. Using --usepkg with --nogetbinpkg will use locally cached
packages without making remote requests.
use the efunctions package for the /etc/init.d/functions.sh script
instead of backing up the old function.sh which doesn't work with the
new baselayout
