Crostini is the codename for the Linux virtual machine in Chrome OS. It has a number of particular functions, such as running Docker containers. Recently, it also became possible to connect USB devices to the Linux VM.
Currently, only Android devices are usable within Crostini, as indicated by this phrase within the settings screen.
Only Android devices are currently supported
But to be specific, each Chrome Device should..
It is conceivable that the Chrome OS device itself has some USB devices that should only be used by the Chrome OS system, and not shared with the guest VM. Those devices should be blacklisted by bus and device number.
For example, the keyboard of a Chromebook might be connected over USB, and we simply do not want to share direct access to the keyboard with the VM, because then it would be impossible to use Chrome OS if the VM had control of the input. Another example is, if there were a USB fingerprint reader that unlocked the Chrome OS device - if the VM took control of the fingerprint reader, and the Chrome OS device would be bricked until power was cycled. It may be possible to throw in a hook to return control of a certain USB device on suspend, but that's getting a little risky.
In Crostini, Shared with Linux folders do not allow the underlying Linux VM to change the mode of shared files. Among other things, this prevents users from being able to use git.
$ git init .
error: chmod on /mnt/chromeos/MyFiles/Downloads/repo/.git/config.lock failed: Operation not permitted
fatal: could not set 'core.filemode' to 'false'
I'm sure there are a few reasons to prohibit this one of course, because a setuid binary could take control of Linux or something like that, but there are at least a finer grain of permissions / capabilities that can be filtered.
Currently, the Developer's Guide uses the classic tried-and-true Gentoo method of building up a system using a chroot and sysroot. While this is good for stage builds and populating fairly basic sysroots with linked binaries and libraries, it suffers from unpredictable build failures that make it difficult to bring up a development environment in some situations.
Such as? Well, the default for emerge is to always use the most recent "stable" release of a package. A model like that where tens or even thousands of packages all have their own, uncoordinated, rolling release schedules, and is an extremely complex problem to solve. Except using a container. Using super/hyper-visor capabilities you can stop a machine quite accurately and record its entire state in seconds.
E.g. cros_sdk has failed recently because chromeos-base/verity-0.0.1 failed to build yesterday (May 18, 2019) on the release-R75-12105.B branch.
Similarly, setup_board --board=elm failed yesterday (May 18, 2019) on the release-R75-12105.B branch.
These builds should be 100% reproducible even for external developers and the fact is that using a container-based build is the simplest way to achieve that goal. It just requires containers to be used instead of logical volumes.
Hi!
Is there something new about git error?