linux

Linux FAQ

Where can I chat with developers?

All Chromium OS development discussions happen in our Chromebook Help Community⁠⁠. Feel free to ask anything, but be sure to search to see if your question has already been addressed first.

Where can I file feature requests?

As a nascent project, we‘ve got a lot on our plate and planning on releasing, so it’d be nice to hold off for now and check back in after a few ChromeOS releases.

Feel free to chat/ask on the mailing list above in the meantime.

Once we are in a more stable place, you can use our issue tracker. See the next question for details.

Where can I file bugs?

Please first make sure you’re using the latest dev channel. A lot of work is still ongoing.

Next, please make sure the issue isn’t already known or fixed. You can check the existing bug list⁠⁠.

If you still want to send feedback, you can file a feedback report⁠⁠ and include #crostini (another name for Linux on ChromeOS) in the description. Feedback about any part of ChromeOS can be filed with alt+shift+i.

If you still want to file a bug with the developers, use this link⁠⁠ to route to the right people.

Why the name Crostini?

It’s a play off crouton⁠⁠ which is a project to easily create full Linux environments (including developer tools) for users who turned on developer mode. Crostini (Linux on ChromeOS) aims to satisfy the majority of use cases covered by crouton⁠⁠, and is a larger & tastier snack than a crouton, hence the name.

crouton⁠⁠ helped define many of the use cases that developers wanted with ChromeOS, so it helped guide Linux on ChromeOS from a requirements perspective. We wanted to make sure that the majority of crouton⁠⁠ users would be able to use Linux on ChromeOS instead for their needs, but in a secure environment.

So crouton⁠⁠ helped inspire the direction of Linux on ChromeOS, but no code has been shared or reused between the two. It‘s not that crouton⁠⁠ is bad, it’s simply a completely different model.

When will my device be supported?

We are not currently publishing any information beyond this document. If your device is not listed in the Device Support⁠⁠ section of the official Chromium OS docs, then we have not yet made any decisions for that specific device that are ready for the public.

So please do not ask us for device support roadmaps as we don’t have them.

Do I need to enable developer mode?

There is no need to enable developer mode (where you see the scary screen at boot about OS verification being turned off). These features are all designed to run securely while your system is running in normal/verified mode.

For some devices you might have to switch to the dev channel⁠⁠, but that is entirely unrelated to developer mode.

Am I running Linux on ChromeOS?

If you’re using the Terminal app or programs in the default container we provide,including our programs to ease integration (e.g. Sommelier⁠), then yes.

If you’re running your own container or VM⁠, then no.

Why run VMs? Aren’t containers secure?

While containers often isolate themselves (via Linux namespaces⁠⁠), they do not isolate the kernel or similar system resources. That means it only takes a single bug in the kernel to fully exploit the system and steal your data.

That isn’t good enough for ChromeOS, hence we put everything inside a VM⁠⁠. Now you have to exploit crosvm⁠⁠ via its limited interactions with the guest, and crosvm⁠⁠ itself is heavily sandboxed.

For more details, see the Security⁠⁠ section of the official Chromium OS docs.

The default Linux on ChromeOS container’s storage is accessible under “Linux Files” in the ChromeOS Files app. Using Secure Shell⁠⁠, you can set up a SFTP mount to the other remote containers and then browse via the Files app as well.

Can I access files when the container isn’t running?

Currently, the container must be running in order to access its content. The default Linux on ChromeOS container will be started automatically when “Linux Files” is accessed from the Files app.

Can I install custom kernel modules?

Currently, no, Termina⁠⁠ does not include module support. That means trying to use software that requires building or loading custom kernel modules (e.g. VirtualBox) will not work. See the next question too.

Can I run a VM inside the VM?

Nested virtualization is supported on some ChromeOS devices to allow for Android Emulator support. Additionally, you could run qemu-system to emulate the hardware and boot whatever OS you want inside of that. Unfortunately, it‘ll be quite slow as QEMU⁠⁠ won’t be able to utilize KVM⁠⁠ for hardware acceleration.

Can I run a Docker container or other container inside ChromeOS’s Linux container?

Yes! You’ll probably need to install the relevant packages first for whatever container format you want to run.

What architecture works on my system?

The Linux container architecture will match the architecture of the device you have. You can find out what that is in two different ways:

In a new tab, navigate to: chrome://settings/help/details and look at the Platform, then match the board name with our public device list⁠⁠. Look at the “User ABI” field to see what kind of CPU you have.
Open up crosh⁠⁠ and run uname -m. This will print the architecture of your current device.

If you see x86_64, you’ll be able to run code compiled for Intel/AMD (32-bit/64-bit/x32 should all work).

If you see arm (or something similar like armv7l) or aarch64, you’ll be able to run code compiled for ARM/ARM64.

Can I run other architectures?

There is currently no integrated support for running e.g. ARM code on an Intel system, or vice-versa. You could handle this yourself (e.g. by using qemu-user), but if you’re familiar with qemu-user, then you already know that.

Can I run programs that keep running after logout?

Nope! All VMs⁠⁠ (and their containers) are tied to your login session. As soon as you log out, all programs are shut down/killed by design.

Since all your data lives in your encrypted home, we wouldn’t want that to possibly leak when you log out.

For more details, see the Security⁠⁠ section of the official Chromium OS docs.

Can I autorun programs when I log in?

Nope! All VMs⁠⁠ (and their containers) need to be manually relaunched. This helps prevent persistent exploits.

For more details, see the Security⁠⁠ section of the official Chromium OS docs.

Can I autorun programs when I boot?

Nope! See the previous questions.

Can I set environment variables for my container?

Sure! There are a few ways to do this.

environment.d⁠⁠ lets you set environment variables for your systemd --user session, which includes the Terminal and all GUI apps. You may need a newer container, Debian⁠⁠ 10 “buster”, to use this method.
If you just want environment variables in your Terminal, set those in your shell’s config file, such as ~/.bashrc or ~/.zshrc.

Changes to environment variables only take effect for newly started programs. You may also need to restart programs or the entire container for any changes to take effect.

Is multiprofile supported?

No, Terminal is only supported in the primary profile (*). Our goal is to have a fully functional and smooth experience for the primary profile, and to not crash or cause problems in secondary profiles. We don’t plan on making secondary profiles more featureful.

If you’re unfamiliar with multiprofile⁠⁠ support, check out the general multiprofile documentation⁠⁠ for more details.

(*): The Terminal application is disabled in all secondary profiles. People can manually start VMs⁠⁠ via crosh⁠⁠ and containers therein, but the UI and Files app probably won’t work integrate automatically.

Are child accounts supported?

No, Terminal is not supported in child accounts⁠⁠. We don’t have plans to make this available to such accounts.

If you’re unfamiliar with child accounts⁠⁠, check out the general child accounts documentation⁠⁠ for more details.

Are my VMs/containers/data synced/backed up?

Ultimately, you’re responsible for any data going into the containers. To easily sync data such as a project folder between machines, you can share a folder in Drive with Linux. Anything you add to that folder will be backed up to Drive and synced between your devices.

How can I backup a VM?

The simplest approach is to use the new backup functionality built into ChromeOS itself. To do so go to Settings and select “Developers" from the left-side nav. Then navigate into “Linux”. You’ll find “Backup & restore”. If you navigate into this menu, you’ll find a “Backup” button that saves a .tini file for you.

If you want to back up an individual container, another approach is to use the standard LXC⁠⁠ commands.

The vmc export command can be used to export an entire VM manually. It will dump the qcow2 disk image to the Downloads folder by default. Note that there isn’t yet a way to import a VM, so this is only useful for diagnostics or using another system to extract files.

Can I access the VM/container files directly (e.g. via the Files app)?

Currently, no, there is no way to access the image files used by the VM⁠⁠. There are no plans to change this.

If you want to back things up, you’ll need to do so by hand.

Why is the time inside the VM/container out of sync?

The clock inside of the VM⁠⁠ (and by extension, the containers) is automatically kept in sync with ChromeOS’s clock. So you do not have to run time keeping services yourself (e.g. ntp). That clock is based off of UTC⁠⁠.

Starting with R75, we attempt to sync timezone data into the container via timedatectl⁠⁠. If that doesn’t work, we fallback with exporting the TZ environment variable.

We don‘t currently update the timezone details inside the VM⁠⁠ itself. We also don’t try to update any other timezone settings as they are non-standard across distros. So the time might appear to be wrong at a glance in those environments, or stale if the TZ environment variable is used.

See https://crbug.com/829934⁠⁠ for some extended technical details. It’s more complicated than you might think!

What copy & paste formats are supported?

Currently, only text/plain content is supported. We plan on adding more formats soon (e.g. image/png⁠⁠ and text/rtf⁠⁠).

You can see the current supported list in exo/data_source.cc⁠⁠.

While X⁠⁠/Wayland⁠⁠ support an arbitrary number of MIME⁠⁠ formats, our ultimate goal is to only support all the formats that Chrome itself does. See the clipboard_constants.cc⁠⁠ file for that list.

Note that we’re only talking about constraints on data stored in the clipboard. Wayland⁠⁠ apps are still free to transfer data directly between themselves in whatever arbitrary format they like.

Can I read/write the clipboard automatically from inside the VM?

Currently, no.

From a security point of view, we don‘t want untrusted code silently or automatically extracting whatever the user has copied. Perhaps your browser session is copying personal data or passwords. It’s the same problem that the web platform⁠⁠ runs into.

This is not the same thing as users manually pasting data (e.g. ctrl+v). This is only about programmatic reading.

We don’t expect it to stay this way forever. Once we have a permission model and UI to manage these things, we can look into allowing users to grant this permission.

If you use xclip or X⁠⁠ tools, they often have a local buffer (in XWayland⁠⁠), but it won’t automatically sync with the rest of the system.

Do I have to manage VM updates?

Nope! The Termina⁠⁠ VM⁠⁠ is a component⁠⁠ that is updated automatically.

Keep in mind that the VM⁠⁠ is separate from the container.

How do I check the Termina version?

Since Termina⁠⁠ is a downloaded component, you can visit chrome://components in a new tab and look for cros-termina.

You can also connect to a VM⁠⁠ via vsh⁠⁠ and run cat /etc/lsb-release.

Do I have to manage container updates?

The Google provided packages in the container that communicate with ChromeOS or are required for ChromeOS integration will be automatically updated on a regular basis. This will install any necessary dependencies automatically.

There is no automatic upgrading of other installed packages in the container. We‘d rather avoid updating packages that might break programs already installed. The container is like any other Linux distro out there, so you’ll need to update it from time to time if you want newer software.

You can run sudo apt-get update && sudo apt-get dist-upgrade.

Can I use IPv6?

Yes, starting with R81. Both dual-stack and IPv6-only networks are supported.

ChromeOS only supports SLAAC; read more in the support page for IPv6 support on ChromeOS⁠⁠.

Can I access layer 2 networking?

Currently, no, networking access is only at layer 3 (i.e. IP). So you won’t be able to do any bridging or lower level fun stuff.

It‘s not clear if/when this will change. Bridging with the outside world is difficult with WiFi, and not many devices have Ethernet connections. We could support layer 2 between containers, but it’s not clear how many people want this in order to justify the effort involved.

Do VPNs set up by CrOS/Android (outside of the VM/containers) work?

Currently, no. You can star https://crbug.com/834585⁠⁠ for updates.

Is audio output supported?

Yes, starting with R74 (Termina⁠⁠ version 11707.0.0+).

If you set up your container before audio support was deployed, it might not be configured correctly (as the default before was to output to the null device). You can try these steps to recover:

# Make sure the new cros-pulse-config package is installed.
$ sudo apt-get update
$ sudo apt-get dist-upgrade

# Clear out existing pulse settings.
$ rm -rf ~/.config/pulse

# Turn it off & on again via crosh ([Ctrl]+[[Alt]]+[[T]]).
crosh> vmc stop termina

Is audio capture (e.g. microphone) supported?

This is now supported in the ChromeOS M84 release. To enable audio capture go to Settings and select “Developers" from the left-side nav. Then navigate into “Linux”. You’ll find “Allow Linux to access your microphone" as an option in that menu.

Can I access hardware (e.g. USB/Bluetooth/serial)?

ChromeOS now allows you to share certain devices through USB. To enable USB access, go to Settings and select “Developers" from the left-side nav. Then navigate into “Linux” and then into “USB preferences”. Here you can enable USB access on a case-by-case basis.

This is an area of active development for the team, and more devices will be supported over time.

Can I run Wayland programs?

Yes, and in fact, these are preferred! Chrome itself deals with Wayland⁠⁠ clients heavily, and so you’re much more likely to have things “just work” if you upgrade.

Sommelier⁠⁠ provides this support seamlessly.

Can I run X programs?

Yes, although you might run into some compatibility kinks, and it probably will never be as perfect as running a traditional X⁠⁠ server. However, with the wider community moving to Wayland⁠⁠, it should be good enough.

Sommelier⁠⁠ takes care of launching XWayland⁠⁠, acting as the WM⁠⁠, and otherwise translating X⁠⁠ and Wayland⁠⁠ requests between Chrome and the X⁠⁠ programs.

Why are windows sometimes tiny/fuzzy?

Linux apps that are visible in the launcher shelf should have an option to use either high or low density. If you find that the resolution isn’t working as desired, right-click on the icon to reveal the ability to toggle between high and low density.

While Chrome supports high DPI⁠⁠ displays, many Linux applications don‘t. When a program doesn’t properly support DPI⁠⁠ scaling, poor results follow.

Currently we expose the built-in resolution and DPI⁠⁠ directly to applications. If they show up tiny or fuzzy, it‘s because they don’t support scaling properly. You should report these issues to the respective upstream projects so that, hopefully someday, it’ll “just work”.

In the meantime, Sommelier⁠⁠ exposes some runtime settings so you can set the scale factor on a per-program basis to work around the misbehavior. Check out Sommelier⁠⁠’s documentation for more details.

If you’re applying a system-wide zoom or otherwise changing the default display resolution, we attempt to scale the application output to match. This can lead to blurry results. You can adjust the resolution of your display, or tweak things via Sommelier⁠⁠ (see above for more details). Linux apps that are visible in the launcher shelf should have an option to use either high or low density. If you find that the resolution isn’t working as desired, right-click on the icon to reveal the ability to toggle between high and low density.

Will synergy work?

Synergy⁠⁠ will not work (as a client or server). It requires capturing and spoofing inputs (e.g. mouse/keyboard) for all windows. Since we‘re built on top of Wayland⁠⁠, by design, one client cannot get access to any other client on the system. This is a strong security boundary between clients as we don’t want arbitrary code running inside of a container being able to break out and attack other clients (like the browser) and sending arbitrary keystrokes.

There are no plans to ever enable this kind of control from the container. This isn‘t to say a synergy-like solution will never happen in ChromeOS (e.g. something like CRD⁠⁠), just that the solution won’t be synergy or any other tool in a container.

You can run synergy, and probably get it to convey input events for the single window that it‘s running under, but that’s as close as you’ll get.

Can I run Windows programs?

Sure, give WINE⁠⁠ a try. Compatibility will largely depend on WINE⁠⁠ though, so please don’t ask us for support.

Can I run macOS programs?

Probably not. You could try various existing Linux solutions, but chances are good that they are even rougher around the edges.

Why implement crosvm from scratch (instead of using QEMU/kvmtool/etc…)?

We have nothing against any of these other projects. In fact, they’re all pretty great, and their designs influenced ours. Most significantly, they did more than we needed and did not have as good a security model as we were able to attain by writing our own. While crosvm⁠⁠ cannot do everything those other projects can, it does only what we need it to.

For more details, check out the crosvm⁠⁠ project.

Don’t VMs slow everything down?

It is certainly true that VMs⁠⁠ add overhead when compared to running in only a container or directly in the system. However, in our tests, the overhead is negligible to the user experience, and well worth the strong gains in system security.

For more details, see the Security⁠⁠ section of the official Chromium OS docs.

Why run containers inside the VM? Why not run programs directly in the VM?

In order to keep VM⁠⁠ startup times low, we need Termina⁠⁠ to be as slim as possible. That means cutting out programs/files we don’t need or are about.

We use dm-verity⁠⁠ which requires the Termina⁠⁠ image be read-only for Security⁠⁠, but it also means we can safely share it between VM⁠⁠ instances.

Further, the versions of programs/libraries we ship are frequently newer than other distros (since we build off of Gentoo⁠⁠), and are compiled with extra security flags.

Allowing user modifications to the VM⁠⁠ prevents a stateless image that always works and is otherwise immune from user mistakes and bugs in programs.

Altogether, it’s difficult to support running arbitrary programs, and would result in a system lacking many desired properties outlined above. Forcing everything into a container produces a more robust solution, and allows users to freely experiment without worry.

Also, we love turtles⁠⁠.

Is Foreshadow (a.k.a. L1TF / CVE-2018-3646) handled?

Yes. For more details, see our public documentation⁠⁠.

Can I delete containers I no longer want?

Sure, feel free to delete whatever you want. However, there is no UI or commands currently to help with this.

Can I delete VMs I no longer want?

Sure, feel free to delete whatever you want. The vmc destroy command can be used to delete them manually.

Can I disable these features?

Administrators can control access to containers/VMs⁠⁠ via the management console, so enterprise/education organizations that want to limit this can.

Initially there is a “Linux” option under the standard ChromeOS settings, but the long-term plan is to remove this knob so things work on-demand. At which point, there will be no knob for unmanaged devices.

Can I boot another OS like Windows, macOS, Linux, *BSD, etc…?

Currently, no, you can only boot our custom Linux VM⁠⁠ named Termina⁠⁠. See also the next few questions.

Can I run my own VM/kernel?

Currently, no, you can only boot Termina⁠⁠ which uses our custom Linux kernel and configs. Stay tuned!

Can I run a different Linux distro?

Of course! The full LXD command line is available, and the included images remote has lots of other distros to choose from. However, we don’t test with anything other than the default container that we ship, so things may be broken when running another distro.

I’m running (insert distro here), how do I get {GUI apps, launcher icons, etc…}?

Sommelier⁠⁠ and Garcon⁠⁠ binaries are bind-mounted into every container, so no need to install or cross-compile. The systemd units and config files from cros-container-guest-tools⁠⁠ will start these daemons in a systemd user session. It’s also a good idea to run loginctl enable-linger <user> to allow these to remain running in the background.