https://wiki.archlinux.org/api.php?action=feedcontributions&user=Crescent&feedformat=atomArchWiki - User contributions [en]2024-03-29T00:42:07ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Chrome_OS_devices/Crostini&diff=802718Chrome OS devices/Crostini2024-03-09T14:38:16Z<p>Crescent: /* Troubleshooting */ Update instructions on resolving Firefox laggy clicking, scrolling & videos</p>
<hr />
<div>[[Category:Chrome OS devices]]<br />
[[ja:Crostini]]<br />
[[zh-hans:Chrome OS devices/Crostini]]<br />
[https://chromium.googlesource.com/chromiumos/docs/+/HEAD/containers_and_vms.md Crostini] is Google's umbrella term for making Linux application support easy to use and integrating well with Chrome OS.<br />
<br />
This article describes how to install Arch Linux on a Chromebook in a container (via Crostini), without needing to enable developer mode, allowing apps to run alongside other Chrome/Android apps.<br />
<br />
Highlights:<br />
<br />
* Officially supported, do not need to enable developer mode - leaves Chrome OS secure, no need to flash a BIOS etc.<br />
* Better battery life - battery life of Chrome with the functionality of Linux.<br />
* Audio (in/out) & OpenGL are supported, but USB devices are only partially supported and development is still in progress.<br />
<br />
== Introduction ==<br />
<br />
=== Enabling Linux support ===<br />
<br />
Look for Linux under Settings and enable it. This installs a Debian Linux container that we will then replace with an Arch Linux container.<br />
<br />
:''Settings > Linux > Enable''<br />
<br />
Crostini is still rolling out to Chromebooks. If you do not see an option to enable Linux, you may need to switch to the beta or developer channel, if it has not rolled out to the stable channel for your laptop yet. This can be done via ''Settings > About Chrome OS > Channel > Dev/Beta''.<br />
<br />
=== Replacing the default Debian Linux container with Arch Linux ===<br />
<br />
The below instructions were initially based on https://www.reddit.com/r/Crostini/wiki/howto/run-arch-linux?v=2d4c6b4c-bbb0-11e8-8f2f-0e740b2a8a8c.<br />
<br />
==== Optional: Delete the Debian container ====<br />
<br />
{{Warning|1=For the time being of Chrome 87, starting a vmc with a custom lxc image makes Termina think it is invalid and delete it. {{ic|lxc delete penguin}} should not leave the space unusable. See [https://bugs.chromium.org/p/chromium/issues/detail?id=1146390#c6]}}<br />
If you have no use for Debian anymore, you can save some storage space by destroying and recreating the Termina VM (this will let you skip renaming / deleting existing container later). Beware this will also delete any other containers you may have under Termina.<br />
{{Warning|Destroying the existing termina may also disable android apps and the play store.}}<br />
<br />
Open the crosh terminal in Chrome ({{ic|Ctrl+Alt+t}}).<br />
<br />
vmc destroy termina<br />
vmc start termina<br />
<br />
==== Create the container ====<br />
<br />
Open a new crosh terminal in Chrome ({{ic|Ctrl+Alt+t}}). Create an Arch Linux container in Termina using VMC:<br />
<br />
vmc container termina arch https://us.lxd.images.canonical.com/{{Dead link|2024|03|03|status=domain name not resolved}} archlinux/current<br />
<br />
The following error will be shown after completion:<br />
<br />
Error: operation `container_create` failed: failed to create container: `UNKNOWN`: requested VM does not exist: termina<br />
ERROR - ERROR: command failed<br />
<br />
This is expected behaviour, proceed with following steps.<br />
<br />
(If this doesn't work, you might be able to succeed with 'lxc launch images:archlinux' instead. It will create the image with a random name to be changed instead of arch later on. substitute arch in the following steps for this generated name.)<br />
<br />
Open a shell in Termina and check if the Arch Linux container is present (it may a few minutes to show on the list):<br />
<br />
vsh termina<br />
lxc list<br />
<br />
If the container is not started, start it:<br />
<br />
lxc start arch<br />
<br />
Launch a bash shell in the container:<br />
<br />
lxc exec arch -- bash<br />
<br />
==== Set up the user ====<br />
<br />
The container creates a default user on install based on the email used to sign in to Chrome OS. The username can be seen with the following command:<br />
<br />
grep 1000:1000 /etc/passwd|cut -d':' -f1<br />
<br />
Optionally you can rename user/group, by default named by your GMail id:<br />
<br />
# pkill -9 -u ''old-username''<br />
# groupmod -n ''new-username'' ''old-username''<br />
# usermod -d /home/''new-username'' -l ''new-username'' -m -c ''new-username'' ''old-username''<br />
<br />
A password needs setting for the user:<br />
<br />
# passwd ''username''<br />
<br />
You may additionally want to install [[sudo]] and add the user to the wheel group. Use after installation:<br />
<br />
# visudo<br />
<br />
Uncomment the following line to allow the wheel group to use sudo:<br />
<br />
# %wheel ALL=(ALL) ALL<br />
<br />
Add your user to the wheel group:<br />
<br />
# usermod -aG wheel ''username''<br />
<br />
Leave the container:<br />
<br />
# exit<br />
<br />
==== Set up the container for use in Chrome OS ====<br />
<br />
Login to the container using regular user account you just configured:<br />
<br />
lxc console arch<br />
<br />
Verify networking in the container. The command <br />
<br />
$ ip -4 a show dev eth0<br />
<br />
should return a non-empty output with the container's assigned IP address. If it is not empty, you can proceed, otherwise you are facing the issue described in [[#No network in container]] - follow the instructions listed there to address the issue.<br />
<br />
Install the Crostini container tools, Wayland for GUI application support and Xwayland for X11 application support:<br />
<br />
[[Install]] the {{AUR|cros-container-guest-tools-git}} package. Additionally install {{Pkg|wayland}} and {{Pkg|xorg-xwayland}} to be able to use GUI tools.<br />
<br />
[[Start/enable]] the following user units:<br />
<br />
{| class="wikitable"<br />
! Template instance !! Purpose<br />
|-<br />
| {{ic|sommelier@0.service}} || Wayland<br />
|-<br />
| {{ic|sommelier-x@0.service}} || X11<br />
|- <br />
| {{ic|sommelier@1.service}} || Wayland (low density)<br />
|-<br />
| {{ic|sommelier-x@1.service}} || X11 (low density)<br />
|}<br />
<br />
Make sure these user services are running successfully by checking their [[unit status]]es. Now, when apps are installed in Arch Linux, they will automatically appear in the Chrome OS launcher. Exit from the container shell back to the Termina shell by pressing {{ic|Ctrl+a}} {{ic|q}}.<br />
<br />
==== Replace the default Debian container with Arch Linux ====<br />
<br />
The default Debian container is named penguin. Renaming the "arch" container created above to it will cause Chrome OS to launch Linux apps from the arch container. Stop the Arch Linux container:<br />
<br />
lxc stop --force arch<br />
<br />
Stop the Debian container and rename it to "debian" (this step can be skipped if you have already removed the Debian container):<br />
<br />
lxc stop --force penguin<br />
lxc rename penguin debian<br />
<br />
Rename the Arch container to "penguin" and start it:<br />
<br />
lxc rename arch penguin<br />
lxc start penguin<br />
<br />
Restart the Linux subsystem to apply the changes. After restart, verify that no [[systemd#Using units|failed system or user units]] are listed.<br />
<br />
The following command should report the IP address assigned for container:<br />
<br />
ip -4 a show dev eth0<br />
<br />
== Troubleshooting ==<br />
<br />
{{Tip|Check the Chromium OS Garcon Bridge ({{ic|journalctl --user -u cros-garcon}}) for host integration issues, like "Linux files is empty in the Files app" or "Applications do not appear on Chrome OS".}}<br />
<br />
=== Arch container fails to start after update to Chrome OS 81 ===<br />
<br />
Most of custom containers stopped working with Chrome OS 81 update. The root cause is a LXC version update, as a result, the container fails to start with following error:<br />
<br />
lxc penguin 20200411193357.312 WARN initutils - initutils.c:setproctitle:324 - Invalid argument - Failed to set cmdline<br />
lxc penguin 20200411193357.395 WARN conf - conf.c:lxc_map_ids:2919 - newuidmap is lacking necessary privileges<br />
lxc penguin 20200411193357.395 WARN conf - conf.c:lxc_map_ids:2925 - newgidmap is lacking necessary privileges<br />
lxc penguin 20200411193357.400 WARN conf - conf.c:lxc_map_ids:2919 - newuidmap is lacking necessary privileges<br />
lxc penguin 20200411193357.400 WARN conf - conf.c:lxc_map_ids:2925 - newgidmap is lacking necessary privileges<br />
lxc penguin 20200411193357.477 ERROR conf - conf.c:run_buffer:335 - Script exited with status 32<br />
lxc penguin 20200411193357.477 ERROR conf - conf.c:lxc_setup:3589 - Failed to run mount hooks<br />
lxc penguin 20200411193357.477 ERROR start - start.c:do_start:1263 - Failed to setup container "penguin"<br />
lxc penguin 20200411193357.478 ERROR sync - sync.c:__sync_wait:62 - An error occurred in another process (expected sequence number 5)<br />
lxc penguin 20200411193357.478 WARN network - network.c:lxc_delete_network_priv:2561 - Failed to rename interface with index 17 from "eth0" to its initial name "veth421fa9d1"<br />
lxc penguin 20200411193357.478 ERROR lxccontainer - lxccontainer.c:wait_on_daemonized_start:842 - Received container state "ABORTING" instead of "RUNNING"<br />
lxc penguin 20200411193357.479 ERROR start - start.c:__lxc_start:1939 - Failed to spawn container "penguin"<br />
lxc penguin 20200411193357.701 WARN conf - conf.c:lxc_map_ids:2919 - newuidmap is lacking necessary privileges<br />
lxc penguin 20200411193357.701 WARN conf - conf.c:lxc_map_ids:2925 - newgidmap is lacking necessary privileges<br />
lxc 20200411193357.706 WARN commands - commands.c:lxc_cmd_rsp_recv:132 - Connection reset by peer - Failed to receive response for command "get_state"<br />
lxc 20200411193357.707 WARN commands - commands.c:lxc_cmd_rsp_recv:132 - Connection reset by peer - Failed to receive response for command "get_state"<br />
<br />
'''Solution'''<br />
<br />
Navigate to crosh and execute the following commands:<br />
<br />
vmc start termina<br />
vsh termina<br />
lxc file delete penguin/var/lib/lxc<br />
lxc file delete penguin/var/lib/lxcfs<br />
<br />
Restart Linux subsystem and container started should start normally.<br />
<br />
=== No network in container ===<br />
<br />
{{Accuracy|In systemd v249, the problem seems to have disappeared, and everything works as it should. However, in systemd v250, the problem seems to appear again. The above claims regarding v249 and v250 need to be confirmed with more user reports.}}<br />
<br />
As was reported by multiple sources, systemd-networkd and systemd-resolved services in systemd-244.1 are not working properly for unprivileged LXC containers, which ends up in missing network connectivity inside the Crostini container. Users may see only IPv6 address but no IPv4 address for the {{ic|arch}} container (for example, using {{ic|ip a}} command).<br />
<br />
One possible solution is stated here: [[LXD#No IPv4 with systemd-networkd]].<br />
<br />
Alternatively, another solution is to completely disable systemd-networkd/systemd-resolved and perform network configuration by [[dhclient]] service instead. First, install {{Pkg|dhclient}}, then, as the root user, run:<br />
<br />
dhcpcd eth0<br />
systemctl disable systemd-networkd<br />
systemctl disable systemd-resolved<br />
unlink /etc/resolv.conf<br />
touch /etc/resolv.conf<br />
systemctl enable dhclient@eth0<br />
systemctl start dhclient@eth0<br />
<br />
[[NetworkManager]] and [[dhcpcd]] also can be used to address the issue if you prefer them over the {{ic|dhclient}} solution.<br />
<br />
=== Permission denied with ping ===<br />
<br />
If you get<br />
<br />
ping: socket: permission denied<br />
<br />
when trying to ping from a user other than {{ic|root}}, you need to set the [[Capabilities|capability]] flag on the {{ic|/usr/bin/ping}} file to fix it.<br />
<br />
# setcap cap_net_raw+ep /usr/bin/ping<br />
<br />
This should solve the problem. See {{Bug|63710}}.<br />
<br />
=== App not opening in chrome OS (infinite spinner) ===<br />
<br />
I found that launching a console (lxc console penguin) session prevents apps from launching in Chrome OS. Launching results in an infinite spinner. In that case, I have to stop and start the container to get the Chrome OS launcher working<br />
<br />
lxc stop penguin<br />
lxc start penguin<br />
<br />
Instead of using an lxc console session, I use a regular Linux terminal GUI launched from Chrome OS that prevents this issue.<br />
<br />
=== Audio playback/input ===<br />
<br />
Crostini support audio playback starting Chrome OS 74. With {{AUR|cros-container-guest-tools-git}} installed both ALSA and PulseAudio playback should work after PulseAudio configuration. Audio input is supported starting Chrome OS 79.<br />
<br />
Enter the following command in the container (in case you did not):<br />
<br />
$ cp -rT /etc/skel/.config/pulse ~/.config/pulse<br />
<br />
It is also possible to use [[PipeWire]] instead of PulseAudio. Put the following file into {{ic|/etc/pipewire/pipewire.conf.d}}:<br />
<br />
{{hc|1=/etc/pipewire/pipewire.conf.d/crostini-audio.conf|2=<br />
context.objects = [<br />
{ factory = adapter<br />
args = {<br />
factory.name = api.alsa.pcm.sink<br />
node.name = "Virtio Soundcard Sink"<br />
media.class = "Audio/Sink"<br />
api.alsa.path = "hw:0,0"<br />
audio.channels = 2<br />
audio.position = "FL,FR"<br />
}<br />
}<br />
{ factory = adapter<br />
args = {<br />
factory.name = api.alsa.pcm.source<br />
node.name = "Virtio Soundcard Source"<br />
media.class = "Audio/Source"<br />
api.alsa.path = "hw:0,0"<br />
audio.channels = 2<br />
audio.position = "FL,FR"<br />
}<br />
}<br />
]<br />
}}<br />
<br />
=== Video playback ===<br />
<br />
[[mpv]] can play videos using software rendering without any addition configuration, however this is CPU consuming and laggy experience for modern video codecs like H265. For hardware accelerated playback GPU acceleration is required. Take into account, that GPU acceleration for Crostini is based on [https://docs.mesa3d.org/drivers/virgl VirGL], so no real GPU device pass-though is performed and hardware-specific APIs like VA-API or VPDAU are not available. However OpenGL acceleration can be used, i.e. this is example of {{ic|mpv.conf}} which enabled accelerated video and audio playback on Google Pixelbook starting Chrome OS 77:<br />
<br />
vo=gpu<br />
ao=alsa<br />
<br />
=== GPU acceleration ===<br />
<br />
On Google Pixelbook GPU acceleration works with Arch out-of-the-box starting Chrome OS 77. Also no flags need to be enabled on recent released of Chrome OS:<br />
<br />
{{hc|$ glxinfo -B|name of display: :0<br />
display: :0 screen: 0<br />
direct rendering: Yes<br />
Extended renderer info (GLX_MESA_query_renderer):<br />
Vendor: Red Hat (0x1af4)<br />
Device: virgl (0x1010)<br />
Version: 19.1.4<br />
--> Accelerated: yes <--<br />
Video memory: 0MB<br />
Unified memory: no<br />
Preferred profile: core (0x1)<br />
Max core profile version: 4.3<br />
Max compat profile version: 3.1<br />
Max GLES1 profile version: 1.1<br />
Max GLES[23] profile version: 3.2<br />
OpenGL vendor string: Red Hat<br />
OpenGL renderer string: virgl<br />
OpenGL core profile version string: 4.3 (Core Profile) Mesa 19.1.4<br />
OpenGL core profile shading language version string: 4.30<br />
OpenGL core profile context flags: (none)<br />
OpenGL core profile profile mask: core profile<br />
<br />
OpenGL version string: 3.1 Mesa 19.1.4<br />
OpenGL shading language version string: 1.40<br />
OpenGL context flags: (none)<br />
<br />
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.1.4<br />
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20}}<br />
<br />
=== Unlock the keyring when starting the container ===<br />
<br />
If you have problems with programs that use {{Pkg|gnome-keyring}}-daemon, you need to write a user systemd daemon (see [[Systemd/User#Writing user units]]) that will run the keyring daemon when the container starts.<br />
<br />
Create the following two files:<br />
<br />
{{hc|head=/etc/systemd/user/gnome-keyring.service|output=<br />
[Unit]<br />
Description=Keyring<br />
<br />
[Service]<br />
ExecStart=/usr/local/bin/export-keys<br />
KillUserProcesses=no<br />
<br />
[Install]<br />
WantedBy=default.target<br />
}}<br />
<br />
{{Warning|Leaving the password in plain text is potentially dangerous. You can replace {{ic|echo random-password}} with {{ic|cat ~/.password}} by creating the appropriate file in your home folder.}}<br />
<br />
{{hc|head=/usr/local/bin/export-keys|output=<br />
#!/bin/bash<br />
killall gnome-keyring-daemon<br />
echo random-password {{!}} gnome-keyring-daemon --components=secrets,ssh,pkcs11 --unlock --foreground<br />
}}<br />
<br />
Give the file launch rights:<br />
<br />
# chmod a+x /usr/local/bin/export-keys<br />
<br />
Then, [[start/enable]] the {{ic|gnome-keyring.service}} user unit and run<br />
<br />
$ echo -n login > ~/.local/share/keyrings/default<br />
<br />
=== Fullscreen video, games and mouse capture ===<br />
<br />
Currently Crostini has limited support for mouse capture starting with Chrome OS 79. You must enable the flag chrome://flags/#exo-pointer-lock to get mouse capture. The closed issue relating to mouse capture is https://bugs.chromium.org/p/chromium/issues/detail?id=927521.<br />
<br />
=== "Linux Files" is empty on host ===<br />
<br />
If you find the "Linux Files" directory on host is always empty and see the following logs in the guest Arch Linux, then you might be affected.<br />
<br />
Feb 24 21:18:23 penguin garcon[183]: [183]: sftp: accepted connection from vsock:2:3162708311<br />
Feb 24 21:18:23 penguin garcon[183]: [183]: Failed to execute requested program in child process: No such file or directory<br />
Feb 24 21:18:23 penguin garcon[183]: [183]: sftp: failed to spawn child process: No child processes (10)<br />
<br />
Since [https://crrev.com/c/3702822 2022-06], garcon launches the sftp server with {{ic|/usr/lib/openssh/sftp-server}}, while the {{Pkg|openssh}} package installs the binary at {{ic|/usr/lib/ssh/sftp-server}}. A workaround is linking the path expected by garcon to the installed one:<br />
<br />
# mkdir /usr/lib/openssh/<br />
# ln -s /usr/lib/ssh/sftp-server /usr/lib/openssh/sftp-server<br />
<br />
=== Firefox laggy clicking, scrolling & videos ===<br />
<br />
If firefox is exhibiting extremely laggy behavior when clicking on the address bar, scrolling, selecting text etc, and or playing lagged or choppy videos, running firefox with MOZ_ENABLE_WAYLAND=1 may resolve this. Inside firefox, about:support should show "Window Protocol" as wayland after this.<br />
<br />
MOZ_ENABLE_WAYLAND=1 firefox<br />
<br />
== See also ==<br />
<br />
* [https://chromium.googlesource.com/chromiumos/docs/+/HEAD/containers_and_vms.md Running Custom Containers Under Chrome OS]<br />
* [https://www.reddit.com/r/Crostini/ /r/Crostini]<br />
* [https://github.com/wernight/powerline-web-fonts Powerline Web Fonts for Chromebook]</div>Crescenthttps://wiki.archlinux.org/index.php?title=Chrome_OS_devices/Crostini&diff=802712Chrome OS devices/Crostini2024-03-09T14:21:33Z<p>Crescent: /* Troubleshooting */ Add instructions on resolving Firefox laggy clicking, scrolling & videos</p>
<hr />
<div>[[Category:Chrome OS devices]]<br />
[[ja:Crostini]]<br />
[[zh-hans:Chrome OS devices/Crostini]]<br />
[https://chromium.googlesource.com/chromiumos/docs/+/HEAD/containers_and_vms.md Crostini] is Google's umbrella term for making Linux application support easy to use and integrating well with Chrome OS.<br />
<br />
This article describes how to install Arch Linux on a Chromebook in a container (via Crostini), without needing to enable developer mode, allowing apps to run alongside other Chrome/Android apps.<br />
<br />
Highlights:<br />
<br />
* Officially supported, do not need to enable developer mode - leaves Chrome OS secure, no need to flash a BIOS etc.<br />
* Better battery life - battery life of Chrome with the functionality of Linux.<br />
* Audio (in/out) & OpenGL are supported, but USB devices are only partially supported and development is still in progress.<br />
<br />
== Introduction ==<br />
<br />
=== Enabling Linux support ===<br />
<br />
Look for Linux under Settings and enable it. This installs a Debian Linux container that we will then replace with an Arch Linux container.<br />
<br />
:''Settings > Linux > Enable''<br />
<br />
Crostini is still rolling out to Chromebooks. If you do not see an option to enable Linux, you may need to switch to the beta or developer channel, if it has not rolled out to the stable channel for your laptop yet. This can be done via ''Settings > About Chrome OS > Channel > Dev/Beta''.<br />
<br />
=== Replacing the default Debian Linux container with Arch Linux ===<br />
<br />
The below instructions were initially based on https://www.reddit.com/r/Crostini/wiki/howto/run-arch-linux?v=2d4c6b4c-bbb0-11e8-8f2f-0e740b2a8a8c.<br />
<br />
==== Optional: Delete the Debian container ====<br />
<br />
{{Warning|1=For the time being of Chrome 87, starting a vmc with a custom lxc image makes Termina think it is invalid and delete it. {{ic|lxc delete penguin}} should not leave the space unusable. See [https://bugs.chromium.org/p/chromium/issues/detail?id=1146390#c6]}}<br />
If you have no use for Debian anymore, you can save some storage space by destroying and recreating the Termina VM (this will let you skip renaming / deleting existing container later). Beware this will also delete any other containers you may have under Termina.<br />
{{Warning|Destroying the existing termina may also disable android apps and the play store.}}<br />
<br />
Open the crosh terminal in Chrome ({{ic|Ctrl+Alt+t}}).<br />
<br />
vmc destroy termina<br />
vmc start termina<br />
<br />
==== Create the container ====<br />
<br />
Open a new crosh terminal in Chrome ({{ic|Ctrl+Alt+t}}). Create an Arch Linux container in Termina using VMC:<br />
<br />
vmc container termina arch https://us.lxd.images.canonical.com/{{Dead link|2024|03|03|status=domain name not resolved}} archlinux/current<br />
<br />
The following error will be shown after completion:<br />
<br />
Error: operation `container_create` failed: failed to create container: `UNKNOWN`: requested VM does not exist: termina<br />
ERROR - ERROR: command failed<br />
<br />
This is expected behaviour, proceed with following steps.<br />
<br />
(If this doesn't work, you might be able to succeed with 'lxc launch images:archlinux' instead. It will create the image with a random name to be changed instead of arch later on. substitute arch in the following steps for this generated name.)<br />
<br />
Open a shell in Termina and check if the Arch Linux container is present (it may a few minutes to show on the list):<br />
<br />
vsh termina<br />
lxc list<br />
<br />
If the container is not started, start it:<br />
<br />
lxc start arch<br />
<br />
Launch a bash shell in the container:<br />
<br />
lxc exec arch -- bash<br />
<br />
==== Set up the user ====<br />
<br />
The container creates a default user on install based on the email used to sign in to Chrome OS. The username can be seen with the following command:<br />
<br />
grep 1000:1000 /etc/passwd|cut -d':' -f1<br />
<br />
Optionally you can rename user/group, by default named by your GMail id:<br />
<br />
# pkill -9 -u ''old-username''<br />
# groupmod -n ''new-username'' ''old-username''<br />
# usermod -d /home/''new-username'' -l ''new-username'' -m -c ''new-username'' ''old-username''<br />
<br />
A password needs setting for the user:<br />
<br />
# passwd ''username''<br />
<br />
You may additionally want to install [[sudo]] and add the user to the wheel group. Use after installation:<br />
<br />
# visudo<br />
<br />
Uncomment the following line to allow the wheel group to use sudo:<br />
<br />
# %wheel ALL=(ALL) ALL<br />
<br />
Add your user to the wheel group:<br />
<br />
# usermod -aG wheel ''username''<br />
<br />
Leave the container:<br />
<br />
# exit<br />
<br />
==== Set up the container for use in Chrome OS ====<br />
<br />
Login to the container using regular user account you just configured:<br />
<br />
lxc console arch<br />
<br />
Verify networking in the container. The command <br />
<br />
$ ip -4 a show dev eth0<br />
<br />
should return a non-empty output with the container's assigned IP address. If it is not empty, you can proceed, otherwise you are facing the issue described in [[#No network in container]] - follow the instructions listed there to address the issue.<br />
<br />
Install the Crostini container tools, Wayland for GUI application support and Xwayland for X11 application support:<br />
<br />
[[Install]] the {{AUR|cros-container-guest-tools-git}} package. Additionally install {{Pkg|wayland}} and {{Pkg|xorg-xwayland}} to be able to use GUI tools.<br />
<br />
[[Start/enable]] the following user units:<br />
<br />
{| class="wikitable"<br />
! Template instance !! Purpose<br />
|-<br />
| {{ic|sommelier@0.service}} || Wayland<br />
|-<br />
| {{ic|sommelier-x@0.service}} || X11<br />
|- <br />
| {{ic|sommelier@1.service}} || Wayland (low density)<br />
|-<br />
| {{ic|sommelier-x@1.service}} || X11 (low density)<br />
|}<br />
<br />
Make sure these user services are running successfully by checking their [[unit status]]es. Now, when apps are installed in Arch Linux, they will automatically appear in the Chrome OS launcher. Exit from the container shell back to the Termina shell by pressing {{ic|Ctrl+a}} {{ic|q}}.<br />
<br />
==== Replace the default Debian container with Arch Linux ====<br />
<br />
The default Debian container is named penguin. Renaming the "arch" container created above to it will cause Chrome OS to launch Linux apps from the arch container. Stop the Arch Linux container:<br />
<br />
lxc stop --force arch<br />
<br />
Stop the Debian container and rename it to "debian" (this step can be skipped if you have already removed the Debian container):<br />
<br />
lxc stop --force penguin<br />
lxc rename penguin debian<br />
<br />
Rename the Arch container to "penguin" and start it:<br />
<br />
lxc rename arch penguin<br />
lxc start penguin<br />
<br />
Restart the Linux subsystem to apply the changes. After restart, verify that no [[systemd#Using units|failed system or user units]] are listed.<br />
<br />
The following command should report the IP address assigned for container:<br />
<br />
ip -4 a show dev eth0<br />
<br />
== Troubleshooting ==<br />
<br />
{{Tip|Check the Chromium OS Garcon Bridge ({{ic|journalctl --user -u cros-garcon}}) for host integration issues, like "Linux files is empty in the Files app" or "Applications do not appear on Chrome OS".}}<br />
<br />
=== Arch container fails to start after update to Chrome OS 81 ===<br />
<br />
Most of custom containers stopped working with Chrome OS 81 update. The root cause is a LXC version update, as a result, the container fails to start with following error:<br />
<br />
lxc penguin 20200411193357.312 WARN initutils - initutils.c:setproctitle:324 - Invalid argument - Failed to set cmdline<br />
lxc penguin 20200411193357.395 WARN conf - conf.c:lxc_map_ids:2919 - newuidmap is lacking necessary privileges<br />
lxc penguin 20200411193357.395 WARN conf - conf.c:lxc_map_ids:2925 - newgidmap is lacking necessary privileges<br />
lxc penguin 20200411193357.400 WARN conf - conf.c:lxc_map_ids:2919 - newuidmap is lacking necessary privileges<br />
lxc penguin 20200411193357.400 WARN conf - conf.c:lxc_map_ids:2925 - newgidmap is lacking necessary privileges<br />
lxc penguin 20200411193357.477 ERROR conf - conf.c:run_buffer:335 - Script exited with status 32<br />
lxc penguin 20200411193357.477 ERROR conf - conf.c:lxc_setup:3589 - Failed to run mount hooks<br />
lxc penguin 20200411193357.477 ERROR start - start.c:do_start:1263 - Failed to setup container "penguin"<br />
lxc penguin 20200411193357.478 ERROR sync - sync.c:__sync_wait:62 - An error occurred in another process (expected sequence number 5)<br />
lxc penguin 20200411193357.478 WARN network - network.c:lxc_delete_network_priv:2561 - Failed to rename interface with index 17 from "eth0" to its initial name "veth421fa9d1"<br />
lxc penguin 20200411193357.478 ERROR lxccontainer - lxccontainer.c:wait_on_daemonized_start:842 - Received container state "ABORTING" instead of "RUNNING"<br />
lxc penguin 20200411193357.479 ERROR start - start.c:__lxc_start:1939 - Failed to spawn container "penguin"<br />
lxc penguin 20200411193357.701 WARN conf - conf.c:lxc_map_ids:2919 - newuidmap is lacking necessary privileges<br />
lxc penguin 20200411193357.701 WARN conf - conf.c:lxc_map_ids:2925 - newgidmap is lacking necessary privileges<br />
lxc 20200411193357.706 WARN commands - commands.c:lxc_cmd_rsp_recv:132 - Connection reset by peer - Failed to receive response for command "get_state"<br />
lxc 20200411193357.707 WARN commands - commands.c:lxc_cmd_rsp_recv:132 - Connection reset by peer - Failed to receive response for command "get_state"<br />
<br />
'''Solution'''<br />
<br />
Navigate to crosh and execute the following commands:<br />
<br />
vmc start termina<br />
vsh termina<br />
lxc file delete penguin/var/lib/lxc<br />
lxc file delete penguin/var/lib/lxcfs<br />
<br />
Restart Linux subsystem and container started should start normally.<br />
<br />
=== No network in container ===<br />
<br />
{{Accuracy|In systemd v249, the problem seems to have disappeared, and everything works as it should. However, in systemd v250, the problem seems to appear again. The above claims regarding v249 and v250 need to be confirmed with more user reports.}}<br />
<br />
As was reported by multiple sources, systemd-networkd and systemd-resolved services in systemd-244.1 are not working properly for unprivileged LXC containers, which ends up in missing network connectivity inside the Crostini container. Users may see only IPv6 address but no IPv4 address for the {{ic|arch}} container (for example, using {{ic|ip a}} command).<br />
<br />
One possible solution is stated here: [[LXD#No IPv4 with systemd-networkd]].<br />
<br />
Alternatively, another solution is to completely disable systemd-networkd/systemd-resolved and perform network configuration by [[dhclient]] service instead. First, install {{Pkg|dhclient}}, then, as the root user, run:<br />
<br />
dhcpcd eth0<br />
systemctl disable systemd-networkd<br />
systemctl disable systemd-resolved<br />
unlink /etc/resolv.conf<br />
touch /etc/resolv.conf<br />
systemctl enable dhclient@eth0<br />
systemctl start dhclient@eth0<br />
<br />
[[NetworkManager]] and [[dhcpcd]] also can be used to address the issue if you prefer them over the {{ic|dhclient}} solution.<br />
<br />
=== Permission denied with ping ===<br />
<br />
If you get<br />
<br />
ping: socket: permission denied<br />
<br />
when trying to ping from a user other than {{ic|root}}, you need to set the [[Capabilities|capability]] flag on the {{ic|/usr/bin/ping}} file to fix it.<br />
<br />
# setcap cap_net_raw+ep /usr/bin/ping<br />
<br />
This should solve the problem. See {{Bug|63710}}.<br />
<br />
=== App not opening in chrome OS (infinite spinner) ===<br />
<br />
I found that launching a console (lxc console penguin) session prevents apps from launching in Chrome OS. Launching results in an infinite spinner. In that case, I have to stop and start the container to get the Chrome OS launcher working<br />
<br />
lxc stop penguin<br />
lxc start penguin<br />
<br />
Instead of using an lxc console session, I use a regular Linux terminal GUI launched from Chrome OS that prevents this issue.<br />
<br />
=== Audio playback/input ===<br />
<br />
Crostini support audio playback starting Chrome OS 74. With {{AUR|cros-container-guest-tools-git}} installed both ALSA and PulseAudio playback should work after PulseAudio configuration. Audio input is supported starting Chrome OS 79.<br />
<br />
Enter the following command in the container (in case you did not):<br />
<br />
$ cp -rT /etc/skel/.config/pulse ~/.config/pulse<br />
<br />
It is also possible to use [[PipeWire]] instead of PulseAudio. Put the following file into {{ic|/etc/pipewire/pipewire.conf.d}}:<br />
<br />
{{hc|1=/etc/pipewire/pipewire.conf.d/crostini-audio.conf|2=<br />
context.objects = [<br />
{ factory = adapter<br />
args = {<br />
factory.name = api.alsa.pcm.sink<br />
node.name = "Virtio Soundcard Sink"<br />
media.class = "Audio/Sink"<br />
api.alsa.path = "hw:0,0"<br />
audio.channels = 2<br />
audio.position = "FL,FR"<br />
}<br />
}<br />
{ factory = adapter<br />
args = {<br />
factory.name = api.alsa.pcm.source<br />
node.name = "Virtio Soundcard Source"<br />
media.class = "Audio/Source"<br />
api.alsa.path = "hw:0,0"<br />
audio.channels = 2<br />
audio.position = "FL,FR"<br />
}<br />
}<br />
]<br />
}}<br />
<br />
=== Video playback ===<br />
<br />
[[mpv]] can play videos using software rendering without any addition configuration, however this is CPU consuming and laggy experience for modern video codecs like H265. For hardware accelerated playback GPU acceleration is required. Take into account, that GPU acceleration for Crostini is based on [https://docs.mesa3d.org/drivers/virgl VirGL], so no real GPU device pass-though is performed and hardware-specific APIs like VA-API or VPDAU are not available. However OpenGL acceleration can be used, i.e. this is example of {{ic|mpv.conf}} which enabled accelerated video and audio playback on Google Pixelbook starting Chrome OS 77:<br />
<br />
vo=gpu<br />
ao=alsa<br />
<br />
=== GPU acceleration ===<br />
<br />
On Google Pixelbook GPU acceleration works with Arch out-of-the-box starting Chrome OS 77. Also no flags need to be enabled on recent released of Chrome OS:<br />
<br />
{{hc|$ glxinfo -B|name of display: :0<br />
display: :0 screen: 0<br />
direct rendering: Yes<br />
Extended renderer info (GLX_MESA_query_renderer):<br />
Vendor: Red Hat (0x1af4)<br />
Device: virgl (0x1010)<br />
Version: 19.1.4<br />
--> Accelerated: yes <--<br />
Video memory: 0MB<br />
Unified memory: no<br />
Preferred profile: core (0x1)<br />
Max core profile version: 4.3<br />
Max compat profile version: 3.1<br />
Max GLES1 profile version: 1.1<br />
Max GLES[23] profile version: 3.2<br />
OpenGL vendor string: Red Hat<br />
OpenGL renderer string: virgl<br />
OpenGL core profile version string: 4.3 (Core Profile) Mesa 19.1.4<br />
OpenGL core profile shading language version string: 4.30<br />
OpenGL core profile context flags: (none)<br />
OpenGL core profile profile mask: core profile<br />
<br />
OpenGL version string: 3.1 Mesa 19.1.4<br />
OpenGL shading language version string: 1.40<br />
OpenGL context flags: (none)<br />
<br />
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.1.4<br />
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20}}<br />
<br />
=== Unlock the keyring when starting the container ===<br />
<br />
If you have problems with programs that use {{Pkg|gnome-keyring}}-daemon, you need to write a user systemd daemon (see [[Systemd/User#Writing user units]]) that will run the keyring daemon when the container starts.<br />
<br />
Create the following two files:<br />
<br />
{{hc|head=/etc/systemd/user/gnome-keyring.service|output=<br />
[Unit]<br />
Description=Keyring<br />
<br />
[Service]<br />
ExecStart=/usr/local/bin/export-keys<br />
KillUserProcesses=no<br />
<br />
[Install]<br />
WantedBy=default.target<br />
}}<br />
<br />
{{Warning|Leaving the password in plain text is potentially dangerous. You can replace {{ic|echo random-password}} with {{ic|cat ~/.password}} by creating the appropriate file in your home folder.}}<br />
<br />
{{hc|head=/usr/local/bin/export-keys|output=<br />
#!/bin/bash<br />
killall gnome-keyring-daemon<br />
echo random-password {{!}} gnome-keyring-daemon --components=secrets,ssh,pkcs11 --unlock --foreground<br />
}}<br />
<br />
Give the file launch rights:<br />
<br />
# chmod a+x /usr/local/bin/export-keys<br />
<br />
Then, [[start/enable]] the {{ic|gnome-keyring.service}} user unit and run<br />
<br />
$ echo -n login > ~/.local/share/keyrings/default<br />
<br />
=== Fullscreen video, games and mouse capture ===<br />
<br />
Currently Crostini has limited support for mouse capture starting with Chrome OS 79. You must enable the flag chrome://flags/#exo-pointer-lock to get mouse capture. The closed issue relating to mouse capture is https://bugs.chromium.org/p/chromium/issues/detail?id=927521.<br />
<br />
=== "Linux Files" is empty on host ===<br />
<br />
If you find the "Linux Files" directory on host is always empty and see the following logs in the guest Arch Linux, then you might be affected.<br />
<br />
Feb 24 21:18:23 penguin garcon[183]: [183]: sftp: accepted connection from vsock:2:3162708311<br />
Feb 24 21:18:23 penguin garcon[183]: [183]: Failed to execute requested program in child process: No such file or directory<br />
Feb 24 21:18:23 penguin garcon[183]: [183]: sftp: failed to spawn child process: No child processes (10)<br />
<br />
Since [https://crrev.com/c/3702822 2022-06], garcon launches the sftp server with {{ic|/usr/lib/openssh/sftp-server}}, while the {{Pkg|openssh}} package installs the binary at {{ic|/usr/lib/ssh/sftp-server}}. A workaround is linking the path expected by garcon to the installed one:<br />
<br />
# mkdir /usr/lib/openssh/<br />
# ln -s /usr/lib/ssh/sftp-server /usr/lib/openssh/sftp-server<br />
<br />
=== Firefox laggy clicking, scrolling & videos ===<br />
<br />
If firefox is exhibiting extremely laggy behaviour when clicking on the address bar, scrolling, selecting text etc, and or playing lagged or choppy videos, running firefox with MOZ_ENABLE_WAYLAND=1 may resolve this.<br />
<br />
MOZ_ENABLE_WAYLAND=1 firefox<br />
<br />
== See also ==<br />
<br />
* [https://chromium.googlesource.com/chromiumos/docs/+/HEAD/containers_and_vms.md Running Custom Containers Under Chrome OS]<br />
* [https://www.reddit.com/r/Crostini/ /r/Crostini]<br />
* [https://github.com/wernight/powerline-web-fonts Powerline Web Fonts for Chromebook]</div>Crescenthttps://wiki.archlinux.org/index.php?title=Dell_XPS_17_(9720)&diff=747201Dell XPS 17 (9720)2022-09-18T03:59:08Z<p>Crescent: /* Headphones / headset connected to the 3.5mm (TRRS) jack */ Delete section, works without it and doesnt work with it. Mistakeling added it, had updated at the same time that fixed it</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 17 (9720)]]<br />
{{Laptop style|Missing function keys section, hardware table needs some adjustments, some sections need to be reordered}}<br />
<br />
This page applies to the Dell XPS 17 (9720) and the Precision 5770, that are the same hardware.<br />
<br />
{| class="wikitable" style="float: right;"<br />
! Hardware !! PCI/USB ID !! Working?<br />
|-<br />
| GPU (Intel) || {{ic|8086:46a6}} || {{Yes}}<br />
|-<br />
| GPU (NVIDIA) || {{ic|10de:25a2}} || {{Yes}}<br />
|-<br />
| Wireless || {{ic|8086:51f0}} || {{Yes}}<br />
|-<br />
| Bluetooth || || {{Yes}}<br />
|-<br />
| Audio || {{ic|8086:51c8}} || {{Yes}}<br />
|-<br />
| Touchpad || {{ic|06CB:CE7E}} || {{Yes}}<br />
|-<br />
| Webcam || || {{Yes}}<br />
|-<br />
| Fingerprint sensor || {{ic|27c6:63ac}} || {{Yes}}<br />
|-<br />
| SD Card Reader || {{ic|10ec:5260}} || {{Y|Untested}}<br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
Before installing it is necessary to modify some UEFI Settings. They can be accessed with {{ic|F2}} when booting.<br />
<br />
* Change the SATA Mode from the default "RAID" to "AHCI". This will allow Linux to detect the NVMe SSD.<br />
* Disable [[Secure Boot]]. This may be re-enabled at a later point. See [[Secure Boot#Using a signed boot loader]].<br />
<br />
=== Dual boot ===<br />
<br />
Please note that changing from "RAID" to "AHCI" can break the default Windows installation and require a complete reinstall. Usually running windows own startup repair utility however fixes this issue in most cases. Another alternative is to follow this [https://gist.github.com/chenxiaolong/4beec93c464639a19ad82eeccc828c63 guide].<br />
<br />
The reinstall can be done through the Dell recovery in the UEFI if needed.<br />
<br />
Once you used the startup repair utility or have reinstalled, Windows should boot normally in AHCI mode and without error. Then one can proceed with typical dual boot setup.<br />
<br />
== Thunderbolt ==<br />
<br />
The following thunderbolt devices have been tested:<br />
<br />
{| class="wikitable"<br />
! Device !! Working? !! Comments<br />
|-<br />
| [https://www.dell.com/en-us/shop/dell-thunderbolt-dock-wd22tb4/apd/210-bdqh/pc-accessories Dell WD22TB4 ] || {{Yes}} || {{-}}<br />
|-<br />
| Dell WD19DC || {{Yes}} || {{-}}<br />
|-<br />
|}<br />
<br />
== Audio ==<br />
<br />
See [[Advanced Linux Sound Architecture#ALSA firmware]]: {{Pkg|sof-firmware}} is required, and allows full functionality.<br />
<br />
=== Microphone ===<br />
<br />
The laptop has several mic channels and the appropriate channel has to be unmuted before the mic will work. Open ''alsamixer'', press {{ic|F6}}, then in sof-soundwire:<br />
<br />
* Select Playback ({{ic|F3}})<br />
* Under Playback, select rt714 ADC 22 Mux and set it to DMIC1<br />
* Select Capture ({{ic|F4}})<br />
* Make sure PGA5.0 5 Master is unmuted and and the two rt714 FU02 channels are unmuted.<br />
<br />
Make sure both the left and right microphones for the PGA5.0 channel (use keys {{ic|;}} and {{ic|'}}) are selected. Other than the above mentioned channels in Playback and Capture, none of the other channels appears to able to influence recorded audio.<br />
<br />
== Touchpad sluggish/sticky ==<br />
<br />
As in previous XPS 17 iterations, some users may find the touchpad is sluggish or sticky occasionally. Previous tracking bug https://gitlab.freedesktop.org/libinput/libinput/-/issues/618 but it is not root-caused yet.<br />
<br />
Touchpad is significantly more stable in X than Wayland. X will rarely exhibit an issue where only the top left quadrant of the touchpad is usable, for a short amount of time (and is fixable by a reboot). <br />
<br />
Using Wayland, if the lower 20% of the screen is exhibiting significant tearing during pointer travel in that area, add the kernel parameter {{ic|1=i915.enable_psr=0}} to resolve this.<br />
<br />
== Power Management ==<br />
<br />
See [[Hibernation]] for kernel parameters & initramfs configuration.<br />
<br />
S3 Sleep: Not supported. S0ix however works reasonably, loosing ~ 0.5% per hour. "RAID" needs to be changed to "AHCI" for S0ix to work.<br />
<br />
NVIDIA's open source driver does not support power management as of July 2022. Installing the proprietary driver is needed for [[NVIDIA Optimus]]. Once the proprietary driver is installed, no additional configuration is needed and it automatically turns the GPU off when not in use, reducing battery power usage by 7-12 watts per hour.<br />
<br />
== Firmware ==<br />
<br />
Dell [https://fwupd.org/lvfs/devices/com.dell.uefi7d606caf.firmware provides firmware updates] that can be installed automatically using [[fwupd]] (or one of its graphical frontends such as Gnome Software or KDE Discover). User reports not receiving UEFI and some other firmware updates this way when there were newer versions available for download.<br />
<br />
Alternatively, firmware updates can also be installed from the UEFI directly by connecting to WiFi, or even installed manually by downloading them from the support page and placing the ''.exe'' file on a FAT32 drive or the EFI boot partition, then selecting the file in the "BIOS update" page after pressing {{ic|F12}} at boot time.<br />
<br />
It is possible to install custom [[Secure Boot]] root keys in the UEFI and use them for Secure Boot with Linux.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Dell_XPS_17_(9720)&diff=747191Dell XPS 17 (9720)2022-09-18T02:13:05Z<p>Crescent: /* Headphones / headset connected to the 3.5mm (TRRS) jack */ Causes default speaker to not work</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 17 (9720)]]<br />
{{Laptop style|Missing function keys section, hardware table needs some adjustments, some sections need to be reordered}}<br />
<br />
This page applies to the Dell XPS 17 (9720) and the Precision 5770, that are the same hardware.<br />
<br />
{| class="wikitable" style="float: right;"<br />
! Hardware !! PCI/USB ID !! Working?<br />
|-<br />
| GPU (Intel) || {{ic|8086:46a6}} || {{Yes}}<br />
|-<br />
| GPU (NVIDIA) || {{ic|10de:25a2}} || {{Yes}}<br />
|-<br />
| Wireless || {{ic|8086:51f0}} || {{Yes}}<br />
|-<br />
| Bluetooth || || {{Yes}}<br />
|-<br />
| Audio || {{ic|8086:51c8}} || {{Yes}}<br />
|-<br />
| Touchpad || {{ic|06CB:CE7E}} || {{Yes}}<br />
|-<br />
| Webcam || || {{Yes}}<br />
|-<br />
| Fingerprint sensor || {{ic|27c6:63ac}} || {{Yes}}<br />
|-<br />
| SD Card Reader || {{ic|10ec:5260}} || {{Y|Untested}}<br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
Before installing it is necessary to modify some UEFI Settings. They can be accessed with {{ic|F2}} when booting.<br />
<br />
* Change the SATA Mode from the default "RAID" to "AHCI". This will allow Linux to detect the NVMe SSD.<br />
* Disable [[Secure Boot]]. This may be re-enabled at a later point. See [[Secure Boot#Using a signed boot loader]].<br />
<br />
=== Dual boot ===<br />
<br />
Please note that changing from "RAID" to "AHCI" can break the default Windows installation and require a complete reinstall. Usually running windows own startup repair utility however fixes this issue in most cases. Another alternative is to follow this [https://gist.github.com/chenxiaolong/4beec93c464639a19ad82eeccc828c63 guide].<br />
<br />
The reinstall can be done through the Dell recovery in the UEFI if needed.<br />
<br />
Once you used the startup repair utility or have reinstalled, Windows should boot normally in AHCI mode and without error. Then one can proceed with typical dual boot setup.<br />
<br />
== Thunderbolt ==<br />
<br />
The following thunderbolt devices have been tested:<br />
<br />
{| class="wikitable"<br />
! Device !! Working? !! Comments<br />
|-<br />
| [https://www.dell.com/en-us/shop/dell-thunderbolt-dock-wd22tb4/apd/210-bdqh/pc-accessories Dell WD22TB4 ] || {{Yes}} || {{-}}<br />
|-<br />
| Dell WD19DC || {{Yes}} || {{-}}<br />
|-<br />
|}<br />
<br />
== Audio ==<br />
<br />
See [[Advanced Linux Sound Architecture#ALSA firmware]]: {{Pkg|sof-firmware}} is required, and allows full functionality.<br />
<br />
=== Microphone ===<br />
<br />
The laptop has several mic channels and the appropriate channel has to be unmuted before the mic will work. Open ''alsamixer'', press {{ic|F6}}, then in sof-soundwire:<br />
<br />
* Select Playback ({{ic|F3}})<br />
* Under Playback, select rt714 ADC 22 Mux and set it to DMIC1<br />
* Select Capture ({{ic|F4}})<br />
* Make sure PGA5.0 5 Master is unmuted and and the two rt714 FU02 channels are unmuted.<br />
<br />
Make sure both the left and right microphones for the PGA5.0 channel (use keys {{ic|;}} and {{ic|'}}) are selected. Other than the above mentioned channels in Playback and Capture, none of the other channels appears to able to influence recorded audio.<br />
<br />
=== Headphones / headset connected to the 3.5mm (TRRS) jack ===<br />
<br />
To get the headphones & headset connected to the 3.5mm jack detected and working, put the following line into your {{ic|/etc/modprobe.d/alsa-base.conf}}. However this caused the speakers to no longer be the default device, and for the speakers to work the headphones need to be connected and then disconnected:<br />
<br />
options snd_hda_intel index=0 model=dell-headset-multi<br />
<br />
== Touchpad sluggish/sticky ==<br />
<br />
As in previous XPS 17 iterations, some users may find the touchpad is sluggish or sticky occasionally. Previous tracking bug https://gitlab.freedesktop.org/libinput/libinput/-/issues/618 but it is not root-caused yet.<br />
<br />
Touchpad is significantly more stable in X than Wayland. X will rarely exhibit an issue where only the top left quadrant of the touchpad is usable, for a short amount of time (and is fixable by a reboot). <br />
<br />
Using Wayland, if the lower 20% of the screen is exhibiting significant tearing during pointer travel in that area, add the kernel parameter {{ic|1=i915.enable_psr=0}} to resolve this.<br />
<br />
== Power Management ==<br />
<br />
See [[Hibernation]] for kernel parameters & initramfs configuration.<br />
<br />
S3 Sleep: Not supported. S0ix however works reasonably, loosing ~ 0.5% per hour. "RAID" needs to be changed to "AHCI" for S0ix to work.<br />
<br />
NVIDIA's open source driver does not support power management as of July 2022. Installing the proprietary driver is needed for [[NVIDIA Optimus]]. Once the proprietary driver is installed, no additional configuration is needed and it automatically turns the GPU off when not in use, reducing battery power usage by 7-12 watts per hour.<br />
<br />
== Firmware ==<br />
<br />
Dell [https://fwupd.org/lvfs/devices/com.dell.uefi7d606caf.firmware provides firmware updates] that can be installed automatically using [[fwupd]] (or one of its graphical frontends such as Gnome Software or KDE Discover). User reports not receiving UEFI and some other firmware updates this way when there were newer versions available for download.<br />
<br />
Alternatively, firmware updates can also be installed from the UEFI directly by connecting to WiFi, or even installed manually by downloading them from the support page and placing the ''.exe'' file on a FAT32 drive or the EFI boot partition, then selecting the file in the "BIOS update" page after pressing {{ic|F12}} at boot time.<br />
<br />
It is possible to install custom [[Secure Boot]] root keys in the UEFI and use them for Secure Boot with Linux.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Dell_XPS_17_(9720)&diff=746140Dell XPS 17 (9720)2022-09-13T17:27:23Z<p>Crescent: /* Audio */ Get headphones / headset working - instructions</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 17 (9720)]]<br />
{{Laptop style|Missing function keys section, hardware table needs some adjustments, some sections need to be reordered}}<br />
<br />
This page applies to the Dell XPS 17 (9720) and the Precision 5770, that are the same hardware.<br />
<br />
{| class="wikitable" style="float: right;"<br />
! Hardware !! PCI/USB ID !! Working?<br />
|-<br />
| GPU (Intel) || {{ic|8086:46a6}} || {{Yes}}<br />
|-<br />
| GPU (NVIDIA) || {{ic|10de:25a2}} || {{Yes}}<br />
|-<br />
| Wireless || {{ic|8086:51f0}} || {{Yes}}<br />
|-<br />
| Bluetooth || || {{Yes}}<br />
|-<br />
| Audio || {{ic|8086:51c8}} || {{Yes}}<br />
|-<br />
| Touchpad || {{ic|06CB:CE7E}} || {{Yes}}<br />
|-<br />
| Webcam || || {{Yes}}<br />
|-<br />
| Fingerprint sensor || {{ic|27c6:63ac}} || {{Yes}}<br />
|-<br />
| SD Card Reader || {{ic|10ec:5260}} || {{Y|Untested}}<br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
Before installing it is necessary to modify some UEFI Settings. They can be accessed with {{ic|F2}} when booting.<br />
<br />
* Change the SATA Mode from the default "RAID" to "AHCI". This will allow Linux to detect the NVMe SSD.<br />
* Disable [[Secure Boot]]. This may be re-enabled at a later point. See [[Secure Boot#Using a signed boot loader]].<br />
<br />
=== Dual boot ===<br />
<br />
Please note that changing from "RAID" to "AHCI" can break the default Windows installation and require a complete reinstall. Usually running windows own startup repair utility however fixes this issue in most cases. Another alternative is to follow this [https://gist.github.com/chenxiaolong/4beec93c464639a19ad82eeccc828c63 guide].<br />
<br />
The reinstall can be done through the Dell recovery in the UEFI if needed.<br />
<br />
Once you used the startup repair utility or have reinstalled, Windows should boot normally in AHCI mode and without error. Then one can proceed with typical dual boot setup.<br />
<br />
== Thunderbolt ==<br />
<br />
The following thunderbolt devices have been tested:<br />
<br />
{| class="wikitable"<br />
! Device !! Working? !! Comments<br />
|-<br />
| [https://www.dell.com/en-us/shop/dell-thunderbolt-dock-wd22tb4/apd/210-bdqh/pc-accessories Dell WD22TB4 ] || {{Yes}} || {{-}}<br />
|-<br />
| Dell WD19DC || {{Yes}} || {{-}}<br />
|-<br />
|}<br />
<br />
== Audio ==<br />
<br />
See [[Advanced Linux Sound Architecture#ALSA firmware]]: {{Pkg|sof-firmware}} is required, and allows full functionality.<br />
<br />
=== Microphone ===<br />
<br />
The laptop has several mic channels and the appropriate channel has to be unmuted before the mic will work. Open ''alsamixer'', press {{ic|F6}}, then in sof-soundwire:<br />
<br />
* Select Playback ({{ic|F3}})<br />
* Under Playback, select rt714 ADC 22 Mux and set it to DMIC1<br />
* Select Capture ({{ic|F4}})<br />
* Make sure PGA5.0 5 Master is unmuted and and the two rt714 FU02 channels are unmuted.<br />
<br />
Make sure both the left and right microphones for the PGA5.0 channel (use keys {{ic|;}} and {{ic|'}}) are selected. Other than the above mentioned channels in Playback and Capture, none of the other channels appears to able to influence recorded audio.<br />
<br />
=== Headphones / headset connected to the 3.5mm (TRRS) jack ===<br />
<br />
To get the headphones & headset connected to the 3.5mm jack detected and working, put the following line into your {{ic|/etc/modprobe.d/alsa-base.conf}}:<br />
<br />
options snd_hda_intel index=0 model=dell-headset-multi<br />
<br />
== Touchpad sluggish/sticky ==<br />
<br />
As in previous XPS 17 iterations, some users may find the touchpad is sluggish or sticky occasionally. Previous tracking bug https://gitlab.freedesktop.org/libinput/libinput/-/issues/618 but it is not root-caused yet.<br />
<br />
Touchpad is significantly more stable in X than Wayland. X will rarely exhibit an issue where only the top left quadrant of the touchpad is usable, for a short amount of time (and is fixable by a reboot). <br />
<br />
Using Wayland, if the lower 20% of the screen is exhibiting significant tearing during pointer travel in that area, add the kernel parameter {{ic|1=i915.enable_psr=0}} to resolve this.<br />
<br />
== Power Management ==<br />
<br />
See [[Hibernation]] for kernel parameters & initramfs configuration.<br />
<br />
S3 Sleep: Not supported. S0ix however works reasonably, loosing ~ 0.5% per hour. "RAID" needs to be changed to "AHCI" for S0ix to work.<br />
<br />
NVIDIA's open source driver does not support power management as of July 2022. Installing the proprietary driver is needed for [[NVIDIA Optimus]]. Once the proprietary driver is installed, no additional configuration is needed and it automatically turns the GPU off when not in use, reducing battery power usage by 7-12 watts per hour.<br />
<br />
== Firmware ==<br />
<br />
Dell [https://fwupd.org/lvfs/devices/com.dell.uefi7d606caf.firmware provides firmware updates] that can be installed automatically using [[fwupd]] (or one of its graphical frontends such as Gnome Software or KDE Discover). User reports not receiving UEFI and some other firmware updates this way when there were newer versions available for download.<br />
<br />
Alternatively, firmware updates can also be installed from the UEFI directly by connecting to WiFi, or even installed manually by downloading them from the support page and placing the ''.exe'' file on a FAT32 drive or the EFI boot partition, then selecting the file in the "BIOS update" page after pressing {{ic|F12}} at boot time.<br />
<br />
It is possible to install custom [[Secure Boot]] root keys in the UEFI and use them for Secure Boot with Linux.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Dell_XPS_17_(9720)&diff=740923Dell XPS 17 (9720)2022-08-10T16:40:45Z<p>Crescent: /* Microphone */ typo</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 17 (9720)]]<br />
{{Laptop style|Missing function keys section, hardware table needs some adjustments, some sections need to be reordered}}<br />
<br />
This page applies to the Dell XPS 17 (9720) and the Precision 5770, that are the same hardware.<br />
<br />
{| class="wikitable" style="float: right;"<br />
! Hardware !! PCI/USB ID !! Working?<br />
|-<br />
| GPU (Intel) || {{ic|8086:46a6}} || {{Yes}}<br />
|-<br />
| GPU (NVIDIA) || {{ic|10de:25a2}} || {{Yes}}<br />
|-<br />
| Wireless || {{ic|8086:51f0}} || {{Yes}}<br />
|-<br />
| Bluetooth || || {{Yes}}<br />
|-<br />
| Audio || {{ic|8086:51c8}} || {{Yes}}<br />
|-<br />
| Touchpad || {{ic|06CB:CE7E}} || {{Yes}}<br />
|-<br />
| Webcam || || {{Yes}}<br />
|-<br />
| Fingerprint sensor || {{ic|27c6:63ac}} || {{Y|Untested}}<br />
|-<br />
| SD Card Reader || {{ic|10ec:5260}} || {{Y|Untested}}<br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
Before installing it is necessary to modify some UEFI Settings. They can be accessed with {{ic|F2}} when booting.<br />
* Change the SATA Mode from the default "RAID" to "AHCI". This will allow Linux to detect the NVME SSD.<br />
* Disable [[Secure Boot]]. This may be re-enabled at a later point. See [[Unified Extensible Firmware Interface/Secure Boot#Using a signed boot loader|Using a signed bootloader]]<br />
<br />
=== Dual boot ===<br />
<br />
Please note that changing from "RAID" to "AHCI" can break the default Windows installation and require a complete reinstall. Usually running windows own startup repair utility however fixes this issue in most cases. Another alternative is to follow this [https://gist.github.com/chenxiaolong/4beec93c464639a19ad82eeccc828c63 guide].<br />
<br />
The reinstall can be done through the Dell recovery in the UEFI if needed.<br />
<br />
Once you used the startup repair utility or have reinstalled, Windows should boot normally in AHCI mode and without error. Then one can proceed with typical dual boot setup.<br />
<br />
== Thunderbolt ==<br />
<br />
The following thunderbolt devices have been tested:<br />
<br />
{| class="wikitable"<br />
! Device !! Working? !! Comments<br />
|-<br />
| [https://www.dell.com/en-us/shop/dell-thunderbolt-dock-wd22tb4/apd/210-bdqh/pc-accessories Dell WD22TB4 ] || {{Yes}} || {{-}}<br />
|-<br />
| Dell WD19DC || {{Yes}} || {{-}}<br />
|-<br />
|}<br />
<br />
== Audio ==<br />
<br />
See [[Advanced Linux Sound Architecture#ALSA firmware]]: {{Pkg|sof-firmware}} is required, and allows full functionality.<br />
<br />
=== Microphone ===<br />
<br />
The laptop has several mic channels and the appropriate channel has to be unmuted before the mic will work. Open ''alsamixer'', press {{ic|F6}}, then in sof-soundwire:<br />
<br />
* Select Playback ({{ic|F3}})<br />
* Under Playback, select rt714 ADC 22 Mux and set it to DMIC1<br />
* Select Capture ({{ic|F4}})<br />
* Make sure PGA5.0 5 Master is unmuted and and the two rt714 FU02 channels are unmuted.<br />
<br />
Make sure both the left and right microphones for the PGA5.0 channel (use keys {{ic|;}} and {{ic|'}}) are selected. Other than the above mentioned channels in Playback and Capture, none of the other channels appears to able to influence recorded audio.<br />
<br />
== Touchpad sluggish/sticky ==<br />
<br />
As in previous XPS 17 iterations, some users may find the touchpad is sluggish or sticky occasionally. Previous tracking bug https://gitlab.freedesktop.org/libinput/libinput/-/issues/618 but it is not root-caused yet.<br />
<br />
Touchpad is significantly more stable in X than Wayland. X will rarely exhibit an issue where only the top left quadrant of the touchpad is usable, for a short amount of time (and is fixable by a reboot). <br />
<br />
Using Wayland, if the lower 20% of the screen is exhibiting significant tearing during pointer travel in that area, add the kernel parameter {{ic|1=i915.enable_psr=0}} to resolve this.<br />
<br />
== Power Management ==<br />
<br />
See [[Hibernation]] for kernel parameters & initramfs configuration.<br />
<br />
S3 Sleep: Not supported. S0ix however works reasonably, loosing ~ 0.5% per hour. "RAID" needs to be changed to "AHCI" for S0ix to work.<br />
<br />
NVIDIA's open source driver does not support power management as of July 2022. Installing the proprietary driver is needed for [[NVIDIA Optimus]]. Once the proprietary driver is installed, no additional configuration is needed and it automatically turns the GPU off when not in use, reducing battery power usage by 7-12 watts per hour.<br />
<br />
== Firmware ==<br />
<br />
Dell [https://fwupd.org/lvfs/devices/com.dell.uefi7d606caf.firmware provides firmware updates] that can be installed automatically using [[fwupd]] (or one of its graphical frontends such as Gnome Software or KDE Discover). User reports not receiving UEFI and some other firmware updates this way when there were newer versions available for download.<br />
<br />
Alternatively, firmware updates can also be installed from the UEFI directly by connecting to WiFi, or even installed manually by downloading them from the support page and placing the ''.exe'' file on a fat32 drive or the EFI boot partition, then selecting the file in the "BIOS update" page after pressing {{ic|F12}} at boot time.<br />
<br />
It is possible to install custom [[Secure Boot]] root keys in the UEFI and use them for Secure Boot with Linux.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Dell_XPS_17_(9720)&diff=740922Dell XPS 17 (9720)2022-08-10T16:39:55Z<p>Crescent: /* Microphone */ typos</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 17 (9720)]]<br />
{{Laptop style|Missing function keys section, hardware table needs some adjustments, some sections need to be reordered}}<br />
<br />
This page applies to the Dell XPS 17 (9720) and the Precision 5770, that are the same hardware.<br />
<br />
{| class="wikitable" style="float: right;"<br />
! Hardware !! PCI/USB ID !! Working?<br />
|-<br />
| GPU (Intel) || {{ic|8086:46a6}} || {{Yes}}<br />
|-<br />
| GPU (NVIDIA) || {{ic|10de:25a2}} || {{Yes}}<br />
|-<br />
| Wireless || {{ic|8086:51f0}} || {{Yes}}<br />
|-<br />
| Bluetooth || || {{Yes}}<br />
|-<br />
| Audio || {{ic|8086:51c8}} || {{Yes}}<br />
|-<br />
| Touchpad || {{ic|06CB:CE7E}} || {{Yes}}<br />
|-<br />
| Webcam || || {{Yes}}<br />
|-<br />
| Fingerprint sensor || {{ic|27c6:63ac}} || {{Y|Untested}}<br />
|-<br />
| SD Card Reader || {{ic|10ec:5260}} || {{Y|Untested}}<br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
Before installing it is necessary to modify some UEFI Settings. They can be accessed with {{ic|F2}} when booting.<br />
* Change the SATA Mode from the default "RAID" to "AHCI". This will allow Linux to detect the NVME SSD.<br />
* Disable [[Secure Boot]]. This may be re-enabled at a later point. See [[Unified Extensible Firmware Interface/Secure Boot#Using a signed boot loader|Using a signed bootloader]]<br />
<br />
=== Dual boot ===<br />
<br />
Please note that changing from "RAID" to "AHCI" can break the default Windows installation and require a complete reinstall. Usually running windows own startup repair utility however fixes this issue in most cases. Another alternative is to follow this [https://gist.github.com/chenxiaolong/4beec93c464639a19ad82eeccc828c63 guide].<br />
<br />
The reinstall can be done through the Dell recovery in the UEFI if needed.<br />
<br />
Once you used the startup repair utility or have reinstalled, Windows should boot normally in AHCI mode and without error. Then one can proceed with typical dual boot setup.<br />
<br />
== Thunderbolt ==<br />
<br />
The following thunderbolt devices have been tested:<br />
<br />
{| class="wikitable"<br />
! Device !! Working? !! Comments<br />
|-<br />
| [https://www.dell.com/en-us/shop/dell-thunderbolt-dock-wd22tb4/apd/210-bdqh/pc-accessories Dell WD22TB4 ] || {{Yes}} || {{-}}<br />
|-<br />
| Dell WD19DC || {{Yes}} || {{-}}<br />
|-<br />
|}<br />
<br />
== Audio ==<br />
<br />
See [[Advanced Linux Sound Architecture#ALSA firmware]]: {{Pkg|sof-firmware}} is required, and allows full functionality.<br />
<br />
=== Microphone ===<br />
<br />
The laptop has several mic channels and the appropriate channel has to be unmuted before the mic will work. Open ''alsamixer'', press {{ic|F6}}, then in sof-soundwire:<br />
<br />
* Select Playback ({{ic|F3}})<br />
* Under Playback, select rt714 ADC 22 Mux and set it to DMIC1<br />
* Select Capture ({{ic|F4}})<br />
* Make sure PGA5.0 5 Master is unmuted and and the two rt714 FU02 channels are unmuted.<br />
<br />
Make sure both the left and right microphone sfor the PGA5.0 channel ({{ic|;}} and {{ic|'}}) are selected. Other than the above mentioned channels in Playback and Capture, none of the other channels appears to able to influence recorded audio.<br />
<br />
== Touchpad sluggish/sticky ==<br />
<br />
As in previous XPS 17 iterations, some users may find the touchpad is sluggish or sticky occasionally. Previous tracking bug https://gitlab.freedesktop.org/libinput/libinput/-/issues/618 but it is not root-caused yet.<br />
<br />
Touchpad is significantly more stable in X than Wayland. X will rarely exhibit an issue where only the top left quadrant of the touchpad is usable, for a short amount of time (and is fixable by a reboot). <br />
<br />
Using Wayland, if the lower 20% of the screen is exhibiting significant tearing during pointer travel in that area, add the kernel parameter {{ic|1=i915.enable_psr=0}} to resolve this.<br />
<br />
== Power Management ==<br />
<br />
See [[Hibernation]] for kernel parameters & initramfs configuration.<br />
<br />
S3 Sleep: Not supported. S0ix however works reasonably, loosing ~ 0.5% per hour. "RAID" needs to be changed to "AHCI" for S0ix to work.<br />
<br />
NVIDIA's open source driver does not support power management as of July 2022. Installing the proprietary driver is needed for [[NVIDIA Optimus]]. Once the proprietary driver is installed, no additional configuration is needed and it automatically turns the GPU off when not in use, reducing battery power usage by 7-12 watts per hour.<br />
<br />
== Firmware ==<br />
<br />
Dell [https://fwupd.org/lvfs/devices/com.dell.uefi7d606caf.firmware provides firmware updates] that can be installed automatically using [[fwupd]] (or one of its graphical frontends such as Gnome Software or KDE Discover). User reports not receiving UEFI and some other firmware updates this way when there were newer versions available for download.<br />
<br />
Alternatively, firmware updates can also be installed from the UEFI directly by connecting to WiFi, or even installed manually by downloading them from the support page and placing the ''.exe'' file on a fat32 drive or the EFI boot partition, then selecting the file in the "BIOS update" page after pressing {{ic|F12}} at boot time.<br />
<br />
It is possible to install custom [[Secure Boot]] root keys in the UEFI and use them for Secure Boot with Linux.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Dell_XPS_17_(9720)&diff=740921Dell XPS 17 (9720)2022-08-10T16:38:38Z<p>Crescent: /* Microphone */ typo add s</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 17 (9720)]]<br />
{{Laptop style|Missing function keys section, hardware table needs some adjustments, some sections need to be reordered}}<br />
<br />
This page applies to the Dell XPS 17 (9720) and the Precision 5770, that are the same hardware.<br />
<br />
{| class="wikitable" style="float: right;"<br />
! Hardware !! PCI/USB ID !! Working?<br />
|-<br />
| GPU (Intel) || {{ic|8086:46a6}} || {{Yes}}<br />
|-<br />
| GPU (NVIDIA) || {{ic|10de:25a2}} || {{Yes}}<br />
|-<br />
| Wireless || {{ic|8086:51f0}} || {{Yes}}<br />
|-<br />
| Bluetooth || || {{Yes}}<br />
|-<br />
| Audio || {{ic|8086:51c8}} || {{Yes}}<br />
|-<br />
| Touchpad || {{ic|06CB:CE7E}} || {{Yes}}<br />
|-<br />
| Webcam || || {{Yes}}<br />
|-<br />
| Fingerprint sensor || {{ic|27c6:63ac}} || {{Y|Untested}}<br />
|-<br />
| SD Card Reader || {{ic|10ec:5260}} || {{Y|Untested}}<br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
Before installing it is necessary to modify some UEFI Settings. They can be accessed with {{ic|F2}} when booting.<br />
* Change the SATA Mode from the default "RAID" to "AHCI". This will allow Linux to detect the NVME SSD.<br />
* Disable [[Secure Boot]]. This may be re-enabled at a later point. See [[Unified Extensible Firmware Interface/Secure Boot#Using a signed boot loader|Using a signed bootloader]]<br />
<br />
=== Dual boot ===<br />
<br />
Please note that changing from "RAID" to "AHCI" can break the default Windows installation and require a complete reinstall. Usually running windows own startup repair utility however fixes this issue in most cases. Another alternative is to follow this [https://gist.github.com/chenxiaolong/4beec93c464639a19ad82eeccc828c63 guide].<br />
<br />
The reinstall can be done through the Dell recovery in the UEFI if needed.<br />
<br />
Once you used the startup repair utility or have reinstalled, Windows should boot normally in AHCI mode and without error. Then one can proceed with typical dual boot setup.<br />
<br />
== Thunderbolt ==<br />
<br />
The following thunderbolt devices have been tested:<br />
<br />
{| class="wikitable"<br />
! Device !! Working? !! Comments<br />
|-<br />
| [https://www.dell.com/en-us/shop/dell-thunderbolt-dock-wd22tb4/apd/210-bdqh/pc-accessories Dell WD22TB4 ] || {{Yes}} || {{-}}<br />
|-<br />
| Dell WD19DC || {{Yes}} || {{-}}<br />
|-<br />
|}<br />
<br />
== Audio ==<br />
<br />
See [[Advanced Linux Sound Architecture#ALSA firmware]]: {{Pkg|sof-firmware}} is required, and allows full functionality.<br />
<br />
=== Microphone ===<br />
<br />
The laptop has several mic channels and the appropriate channel has to be unmuted before the mic will work. Open ''alsamixer'', press {{ic|F6}}, then in sof-soundwire:<br />
<br />
* Select Playback ({{ic|F3}})<br />
* Under Playback, select rt714 ADC 22 Mux and set it to DMIC1<br />
* Select Capture ({{ic|F4}})<br />
* Make sure PGA5.0 5 Master is unmuted and and the two rt714 FU02 channels are unmuted.<br />
<br />
Make sure both the left or right microphone channels for the PGA5.0 channel ({{ic|;}} and {{ic|'}}). Other than the above mentioned channels in Playback and Capture, none of the other channels appears to able to influence recorded audio.<br />
<br />
== Touchpad sluggish/sticky ==<br />
<br />
As in previous XPS 17 iterations, some users may find the touchpad is sluggish or sticky occasionally. Previous tracking bug https://gitlab.freedesktop.org/libinput/libinput/-/issues/618 but it is not root-caused yet.<br />
<br />
Touchpad is significantly more stable in X than Wayland. X will rarely exhibit an issue where only the top left quadrant of the touchpad is usable, for a short amount of time (and is fixable by a reboot). <br />
<br />
Using Wayland, if the lower 20% of the screen is exhibiting significant tearing during pointer travel in that area, add the kernel parameter {{ic|1=i915.enable_psr=0}} to resolve this.<br />
<br />
== Power Management ==<br />
<br />
See [[Hibernation]] for kernel parameters & initramfs configuration.<br />
<br />
S3 Sleep: Not supported. S0ix however works reasonably, loosing ~ 0.5% per hour. "RAID" needs to be changed to "AHCI" for S0ix to work.<br />
<br />
NVIDIA's open source driver does not support power management as of July 2022. Installing the proprietary driver is needed for [[NVIDIA Optimus]]. Once the proprietary driver is installed, no additional configuration is needed and it automatically turns the GPU off when not in use, reducing battery power usage by 7-12 watts per hour.<br />
<br />
== Firmware ==<br />
<br />
Dell [https://fwupd.org/lvfs/devices/com.dell.uefi7d606caf.firmware provides firmware updates] that can be installed automatically using [[fwupd]] (or one of its graphical frontends such as Gnome Software or KDE Discover). User reports not receiving UEFI and some other firmware updates this way when there were newer versions available for download.<br />
<br />
Alternatively, firmware updates can also be installed from the UEFI directly by connecting to WiFi, or even installed manually by downloading them from the support page and placing the ''.exe'' file on a fat32 drive or the EFI boot partition, then selecting the file in the "BIOS update" page after pressing {{ic|F12}} at boot time.<br />
<br />
It is possible to install custom [[Secure Boot]] root keys in the UEFI and use them for Secure Boot with Linux.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Dell_XPS_17_(9720)&diff=740506Dell XPS 17 (9720)2022-08-07T17:42:53Z<p>Crescent: Update touchpad and fingerprint sensor device ids</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 17 (9720)]]<br />
{{Laptop style|Missing function keys section, hardware table needs some adjustments, some sections need to be reordered}}<br />
<br />
This page applies to the Dell XPS 17 (9720) and the Precision 5770, that are the same hardware.<br />
<br />
{| class="wikitable" style="float: right;"<br />
! Hardware !! PCI/USB ID !! Working?<br />
|-<br />
| GPU (Intel) || {{ic|8086:46a6}} || {{Yes}}<br />
|-<br />
| GPU (NVIDIA) || {{ic|10de:25a2}} || {{Yes}}<br />
|-<br />
| Wireless || {{ic|8086:51f0}} || {{Yes}}<br />
|-<br />
| Bluetooth || || {{Yes}}<br />
|-<br />
| Audio || {{ic|8086:51c8}} || {{Yes}}<br />
|-<br />
| Touchpad || {{ic|06CB:CE7E}} || {{Yes}}<br />
|-<br />
| Webcam || || {{Yes}}<br />
|-<br />
| Fingerprint sensor || {{ic|27c6:63ac}} || {{Y|Untested}}<br />
|-<br />
| SD Card Reader || {{ic|10ec:5260}} || {{Y|Untested}}<br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
Before installing it is necessary to modify some UEFI Settings. They can be accessed with {{ic|F2}} when booting.<br />
* Change the SATA Mode from the default "RAID" to "AHCI". This will allow Linux to detect the NVME SSD.<br />
* Disable [[Secure Boot]]. This may be re-enabled at a later point. See [[Unified Extensible Firmware Interface/Secure Boot#Using a signed boot loader|Using a signed bootloader]]<br />
<br />
=== Dual boot ===<br />
<br />
Please note that changing from "RAID" to "AHCI" can break the default Windows installation and require a complete reinstall. Usually running windows own startup repair utility however fixes this issue in most cases. Another alternative is to follow this [https://gist.github.com/chenxiaolong/4beec93c464639a19ad82eeccc828c63 guide].<br />
<br />
The reinstall can be done through the Dell recovery in the UEFI if needed.<br />
<br />
Once you used the startup repair utility or have reinstalled, Windows should boot normally in AHCI mode and without error. Then one can proceed with typical dual boot setup.<br />
<br />
== Thunderbolt ==<br />
<br />
The following thunderbolt devices have been tested:<br />
<br />
{| class="wikitable"<br />
! Device !! Working? !! Comments<br />
|-<br />
| [https://www.dell.com/en-us/shop/dell-thunderbolt-dock-wd22tb4/apd/210-bdqh/pc-accessories Dell WD22TB4 ] || {{Yes}} || {{-}}<br />
|-<br />
| Dell WD19DC || {{Yes}} || {{-}}<br />
|-<br />
|}<br />
<br />
== Audio ==<br />
<br />
See [[Advanced Linux Sound Architecture#ALSA firmware]]: {{Pkg|sof-firmware}} is required, and allows full functionality.<br />
<br />
=== Microphone ===<br />
<br />
The laptop has several mic channel and the appropriate channel has to be unmuted before the mic will work. Open ''alsamixer'', press {{ic|F6}}, then in sof-soundwire:<br />
<br />
* Select Playback ({{ic|F3}})<br />
* Under Playback, select rt714 ADC 22 Mux and set it to DMIC1<br />
* Select Capture ({{ic|F4}})<br />
* Make sure PGA5.0 5 Master is unmuted and and the two rt714 FU02 channels are unmuted.<br />
<br />
Make sure both the left or right microphone channels for the PGA5.0 channel ({{ic|;}} and {{ic|'}}). Other than the above mentioned channels in Playback and Capture, none of the other channels appears to able to influence recorded audio.<br />
<br />
== Touchpad sluggish/sticky ==<br />
<br />
As in previous XPS 17 iterations, some users may find the touchpad is sluggish or sticky occasionally. Previous tracking bug https://gitlab.freedesktop.org/libinput/libinput/-/issues/618 but it is not root-caused yet.<br />
<br />
Touchpad is significantly more stable in X than Wayland. X will rarely exhibit an issue where only the top left quadrant of the touchpad is usable, for a short amount of time (and is fixable by a reboot). <br />
<br />
Using Wayland, if the lower 20% of the screen is exhibiting significant tearing during pointer travel in that area, add the kernel parameter {{ic|1=i915.enable_psr=0}} to resolve this.<br />
<br />
== Power Management ==<br />
<br />
See [[Hibernation]] for kernel parameters & initramfs configuration.<br />
<br />
S3 Sleep: Not supported. S0ix however works reasonably, loosing ~ 0.5% per hour. "RAID" needs to be changed to "AHCI" for S0ix to work.<br />
<br />
NVIDIA's open source driver does not support power management as of July 2022. Installing the proprietary driver is needed for [[NVIDIA Optimus]]. Once the proprietary driver is installed, no additional configuration is needed and it automatically turns the GPU off when not in use, reducing battery power usage by 7-12 watts per hour.<br />
<br />
== Firmware ==<br />
<br />
Dell [https://fwupd.org/lvfs/devices/com.dell.uefi7d606caf.firmware provides firmware updates] that can be installed automatically using [[fwupd]] (or one of its graphical frontends such as Gnome Software or KDE Discover). User reports not receiving UEFI and some other firmware updates this way when there were newer versions available for download.<br />
<br />
Alternatively, firmware updates can also be installed from the UEFI directly by connecting to WiFi, or even installed manually by downloading them from the support page and placing the ''.exe'' file on a fat32 drive or the EFI boot partition, then selecting the file in the "BIOS update" page after pressing {{ic|F12}} at boot time.<br />
<br />
It is possible to install custom [[Secure Boot]] root keys in the UEFI and use them for Secure Boot with Linux.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Dell_XPS_17_(9720)&diff=740505Dell XPS 17 (9720)2022-08-07T17:39:53Z<p>Crescent: Update touchpad working to yes</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 17 (9720)]]<br />
{{Laptop style|Missing function keys section, hardware table needs some adjustments, some sections need to be reordered}}<br />
<br />
This page applies to the Dell XPS 17 (9720) and the Precision 5770, that are the same hardware.<br />
<br />
{| class="wikitable" style="float: right;"<br />
! Hardware !! PCI/USB ID !! Working?<br />
|-<br />
| GPU (Intel) || {{ic|8086:46a6}} || {{Yes}}<br />
|-<br />
| GPU (NVIDIA) || {{ic|10de:25a2}} || {{Yes}}<br />
|-<br />
| Wireless || {{ic|8086:51f0}} || {{Yes}}<br />
|-<br />
| Bluetooth || || {{Yes}}<br />
|-<br />
| Audio || {{ic|8086:51c8}} || {{Yes}}<br />
|-<br />
| Touchpad || || {{Yes}}<br />
|-<br />
| Webcam || || {{Yes}}<br />
|-<br />
| Fingerprint sensor || || {{Y|Untested}}<br />
|-<br />
| SD Card Reader || {{ic|10ec:5260}} || {{Y|Untested}}<br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
Before installing it is necessary to modify some UEFI Settings. They can be accessed with {{ic|F2}} when booting.<br />
* Change the SATA Mode from the default "RAID" to "AHCI". This will allow Linux to detect the NVME SSD.<br />
* Disable [[Secure Boot]]. This may be re-enabled at a later point. See [[Unified Extensible Firmware Interface/Secure Boot#Using a signed boot loader|Using a signed bootloader]]<br />
<br />
=== Dual boot ===<br />
<br />
Please note that changing from "RAID" to "AHCI" can break the default Windows installation and require a complete reinstall. Usually running windows own startup repair utility however fixes this issue in most cases. Another alternative is to follow this [https://gist.github.com/chenxiaolong/4beec93c464639a19ad82eeccc828c63 guide].<br />
<br />
The reinstall can be done through the Dell recovery in the UEFI if needed.<br />
<br />
Once you used the startup repair utility or have reinstalled, Windows should boot normally in AHCI mode and without error. Then one can proceed with typical dual boot setup.<br />
<br />
== Thunderbolt ==<br />
<br />
The following thunderbolt devices have been tested:<br />
<br />
{| class="wikitable"<br />
! Device !! Working? !! Comments<br />
|-<br />
| [https://www.dell.com/en-us/shop/dell-thunderbolt-dock-wd22tb4/apd/210-bdqh/pc-accessories Dell WD22TB4 ] || {{Yes}} || {{-}}<br />
|-<br />
| Dell WD19DC || {{Yes}} || {{-}}<br />
|-<br />
|}<br />
<br />
== Audio ==<br />
<br />
See [[Advanced Linux Sound Architecture#ALSA firmware]]: {{Pkg|sof-firmware}} is required, and allows full functionality.<br />
<br />
=== Microphone ===<br />
<br />
The laptop has several mic channel and the appropriate channel has to be unmuted before the mic will work. Open ''alsamixer'', press {{ic|F6}}, then in sof-soundwire:<br />
<br />
* Select Playback ({{ic|F3}})<br />
* Under Playback, select rt714 ADC 22 Mux and set it to DMIC1<br />
* Select Capture ({{ic|F4}})<br />
* Make sure PGA5.0 5 Master is unmuted and and the two rt714 FU02 channels are unmuted.<br />
<br />
Make sure both the left or right microphone channels for the PGA5.0 channel ({{ic|;}} and {{ic|'}}). Other than the above mentioned channels in Playback and Capture, none of the other channels appears to able to influence recorded audio.<br />
<br />
== Touchpad sluggish/sticky ==<br />
<br />
As in previous XPS 17 iterations, some users may find the touchpad is sluggish or sticky occasionally. Previous tracking bug https://gitlab.freedesktop.org/libinput/libinput/-/issues/618 but it is not root-caused yet.<br />
<br />
Touchpad is significantly more stable in X than Wayland. X will rarely exhibit an issue where only the top left quadrant of the touchpad is usable, for a short amount of time (and is fixable by a reboot). <br />
<br />
Using Wayland, if the lower 20% of the screen is exhibiting significant tearing during pointer travel in that area, add the kernel parameter {{ic|1=i915.enable_psr=0}} to resolve this.<br />
<br />
== Power Management ==<br />
<br />
See [[Hibernation]] for kernel parameters & initramfs configuration.<br />
<br />
S3 Sleep: Not supported. S0ix however works reasonably, loosing ~ 0.5% per hour. "RAID" needs to be changed to "AHCI" for S0ix to work.<br />
<br />
NVIDIA's open source driver does not support power management as of July 2022. Installing the proprietary driver is needed for [[NVIDIA Optimus]]. Once the proprietary driver is installed, no additional configuration is needed and it automatically turns the GPU off when not in use, reducing battery power usage by 7-12 watts per hour.<br />
<br />
== Firmware ==<br />
<br />
Dell [https://fwupd.org/lvfs/devices/com.dell.uefi7d606caf.firmware provides firmware updates] that can be installed automatically using [[fwupd]] (or one of its graphical frontends such as Gnome Software or KDE Discover). User reports not receiving UEFI and some other firmware updates this way when there were newer versions available for download.<br />
<br />
Alternatively, firmware updates can also be installed from the UEFI directly by connecting to WiFi, or even installed manually by downloading them from the support page and placing the ''.exe'' file on a fat32 drive or the EFI boot partition, then selecting the file in the "BIOS update" page after pressing {{ic|F12}} at boot time.<br />
<br />
It is possible to install custom [[Secure Boot]] root keys in the UEFI and use them for Secure Boot with Linux.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Dell_XPS_17_(9720)&diff=740503Dell XPS 17 (9720)2022-08-07T16:57:16Z<p>Crescent: /* Microphone */ update instructions for stereo mic</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 17 (9720)]]<br />
{{Laptop style|Missing function keys section, hardware table needs some adjustments, some sections need to be reordered}}<br />
<br />
This page applies to the Dell XPS 17 (9720) and the Precision 5770, that are the same hardware.<br />
<br />
{| class="wikitable" style="float: right;"<br />
! Hardware !! PCI/USB ID !! Working?<br />
|-<br />
| GPU (Intel) || {{ic|8086:46a6}} || {{Yes}}<br />
|-<br />
| GPU (NVIDIA) || {{ic|10de:25a2}} || {{Yes}}<br />
|-<br />
| Wireless || {{ic|8086:51f0}} || {{Yes}}<br />
|-<br />
| Bluetooth || || {{Yes}}<br />
|-<br />
| Audio || {{ic|8086:51c8}} || {{Yes}}<br />
|-<br />
| Touchpad || || {{Y|Partial}}<br />
|-<br />
| Webcam || || {{Yes}}<br />
|-<br />
| Fingerprint sensor || || {{Y|Untested}}<br />
|-<br />
| SD Card Reader || {{ic|10ec:5260}} || {{Y|Untested}}<br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
Before installing it is necessary to modify some UEFI Settings. They can be accessed with {{ic|F2}} when booting.<br />
* Change the SATA Mode from the default "RAID" to "AHCI". This will allow Linux to detect the NVME SSD.<br />
* Disable [[Secure Boot]]. This may be re-enabled at a later point. See [[Unified Extensible Firmware Interface/Secure Boot#Using a signed boot loader|Using a signed bootloader]]<br />
<br />
=== Dual boot ===<br />
<br />
Please note that changing from "RAID" to "AHCI" can break the default Windows installation and require a complete reinstall. Usually running windows own startup repair utility however fixes this issue in most cases. Another alternative is to follow this [https://gist.github.com/chenxiaolong/4beec93c464639a19ad82eeccc828c63 guide].<br />
<br />
The reinstall can be done through the Dell recovery in the UEFI if needed.<br />
<br />
Once you used the startup repair utility or have reinstalled, Windows should boot normally in AHCI mode and without error. Then one can proceed with typical dual boot setup.<br />
<br />
== Thunderbolt ==<br />
<br />
The following thunderbolt devices have been tested:<br />
<br />
{| class="wikitable"<br />
! Device !! Working? !! Comments<br />
|-<br />
| [https://www.dell.com/en-us/shop/dell-thunderbolt-dock-wd22tb4/apd/210-bdqh/pc-accessories Dell WD22TB4 ] || {{Yes}} || {{-}}<br />
|-<br />
| Dell WD19DC || {{Yes}} || {{-}}<br />
|-<br />
|}<br />
<br />
== Audio ==<br />
<br />
See [[Advanced Linux Sound Architecture#ALSA firmware]]: {{Pkg|sof-firmware}} is required, and allows full functionality.<br />
<br />
=== Microphone ===<br />
<br />
The laptop has several mic channel and the appropriate channel has to be unmuted before the mic will work. Open ''alsamixer'', press {{ic|F6}}, then in sof-soundwire:<br />
<br />
* Select Playback ({{ic|F3}})<br />
* Under Playback, select rt714 ADC 22 Mux and set it to DMIC1<br />
* Select Capture ({{ic|F4}})<br />
* Make sure PGA5.0 5 Master is unmuted and and the two rt714 FU02 channels are unmuted.<br />
<br />
Make sure both the left or right microphone channels for the PGA5.0 channel ({{ic|;}} and {{ic|'}}). Other than the above mentioned channels in Playback and Capture, none of the other channels appears to able to influence recorded audio.<br />
<br />
== Touchpad sluggish/sticky ==<br />
<br />
As in previous XPS 17 iterations, some users may find the touchpad is sluggish or sticky occasionally. Previous tracking bug https://gitlab.freedesktop.org/libinput/libinput/-/issues/618 but it is not root-caused yet.<br />
<br />
Touchpad is significantly more stable in X than Wayland. X will rarely exhibit an issue where only the top left quadrant of the touchpad is usable, for a short amount of time (and is fixable by a reboot). <br />
<br />
Using Wayland, if the lower 20% of the screen is exhibiting significant tearing during pointer travel in that area, add the kernel parameter {{ic|1=i915.enable_psr=0}} to resolve this.<br />
<br />
== Power Management ==<br />
<br />
See [[Hibernation]] for kernel parameters & initramfs configuration.<br />
<br />
S3 Sleep: Not supported. S0ix however works reasonably, loosing ~ 0.5% per hour. "RAID" needs to be changed to "AHCI" for S0ix to work.<br />
<br />
NVIDIA's open source driver does not support power management as of July 2022. Installing the proprietary driver is needed for [[NVIDIA Optimus]]. Once the proprietary driver is installed, no additional configuration is needed and it automatically turns the GPU off when not in use, reducing battery power usage by 7-12 watts per hour.<br />
<br />
== Firmware ==<br />
<br />
Dell [https://fwupd.org/lvfs/devices/com.dell.uefi7d606caf.firmware provides firmware updates] that can be installed automatically using [[fwupd]] (or one of its graphical frontends such as Gnome Software or KDE Discover). User reports not receiving UEFI and some other firmware updates this way when there were newer versions available for download.<br />
<br />
Alternatively, firmware updates can also be installed from the UEFI directly by connecting to WiFi, or even installed manually by downloading them from the support page and placing the ''.exe'' file on a fat32 drive or the EFI boot partition, then selecting the file in the "BIOS update" page after pressing {{ic|F12}} at boot time.<br />
<br />
It is possible to install custom [[Secure Boot]] root keys in the UEFI and use them for Secure Boot with Linux.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Power_management/Suspend_and_hibernate&diff=740283Power management/Suspend and hibernate2022-08-06T00:41:46Z<p>Crescent: /* Intel Rapid Start Technology (IRST) */ Minor path correction /sys/bus</p>
<hr />
<div>[[Category:Power management]]<br />
[[de:Bereitschaft und Ruhezustand]]<br />
[[es:Power management (Español)/Suspend and hibernate]]<br />
[[ja:サスペンドとハイバネート]]<br />
[[ru:Power management (Русский)/Suspend and hibernate]]<br />
[[zh-hans:Power management (简体中文)/Suspend and hibernate]]<br />
{{Related articles start}}<br />
{{Related|Uswsusp}}<br />
{{Related|systemd}}<br />
{{Related|Power management}}<br />
{{Related|Wakeup triggers}}<br />
{{Related|swap}}<br />
{{Related articles end}}<br />
<br />
Currently there are three methods of suspending available:<br />
<br />
; Suspend to RAM (aka suspend, aka sleep): The '''S3''' sleeping state as defined by ACPI. Works by cutting off power to most parts of the machine aside from the RAM, which is required to restore the machine's state. Because of the large power savings, it is advisable for laptops to automatically enter this mode when the computer is running on batteries and the lid is closed (or the user is inactive for some time).<br />
; Suspend to disk (aka hibernate): The '''S4''' sleeping state as defined by ACPI. Saves the machine's state into [[swap space]] and completely powers off the machine. When the machine is powered on, the state is restored. Until then, there is [[Wikipedia:Standby power|zero]] power consumption.<br />
; Suspend to both: A hybrid of the aforementioned methods, sometimes called '''hybrid suspend'''. Saves the machine's state into swap space, but does not power off the machine. Instead, it invokes usual suspend to RAM. Therefore, if the battery is not depleted, the system can resume from RAM. If the battery is depleted, the system can be resumed from disk, which is much slower than resuming from RAM, but the machine's state has not been lost.<br />
<br />
There are multiple low level interfaces (backends) providing basic functionality, and some high level interfaces providing tweaks to handle problematic hardware drivers/kernel modules (e.g. video card re-initialization).<br />
<br />
{{Expansion|Document "suspend to idle" (called [https://docs.kernel.org/admin-guide/pm/sleep-states.html#suspend-to-idle S2Idle] by the kernel, [https://01.org/blogs/qwang59/2018/how-achieve-s0ix-states-linux S0ix] by Intel and [https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby Modern Standby] by Microsoft) and {{ic|/sys/power/mem_sleep}} values.}}<br />
<br />
== Low level interfaces ==<br />
<br />
Though these interfaces can be used directly, it is advisable to use the [[#High level interfaces|high level interfaces]] to suspend/hibernate. Using low level interfaces directly is significantly faster than using any high level interface, since running all the pre- and post-suspend hooks takes time, but hooks can properly set hardware clock, restore wireless etc.<br />
<br />
=== kernel (swsusp) ===<br />
<br />
The most straightforward approach is to directly inform the in-kernel software suspend code (swsusp) to enter a suspended state; the exact method and state depends on the level of hardware support. On modern kernels, writing appropriate strings to {{ic|/sys/power/state}} is the primary mechanism to trigger this suspend.<br />
<br />
See [https://docs.kernel.org/admin-guide/pm/sleep-states.html kernel documentation] for details.<br />
<br />
=== uswsusp ===<br />
<br />
The uswsusp ('Userspace Software Suspend') is a wrapper around the kernel's suspend-to-RAM mechanism, which performs some graphics adapter manipulations from userspace before suspending and after resuming.<br />
<br />
See main article [[Uswsusp]].<br />
<br />
== High level interfaces ==<br />
<br />
The end goal of these packages is to provide binaries/scripts that can be invoked to perform suspend/hibernate. Actually hooking them up to power buttons or menu clicks or laptop lid events is usually left to other tools. To automatically suspend/hibernate on certain power events, such as laptop lid close or battery depletion percentage, you may want to look into running [[Acpid]].<br />
<br />
=== systemd ===<br />
<br />
[[systemd]] provides native commands for suspend, hibernate and a hybrid suspend, see [[Power management#Power management with systemd]] for details. This is the default interface used in Arch Linux.<br />
<br />
See [[Power management#Sleep hooks]] for additional information on configuring suspend/hibernate hooks. Also see {{man|1|systemctl}}, {{man|8|systemd-sleep}}, and {{man|7|systemd.special}}.<br />
<br />
== Hibernation ==<br />
<br />
In order to use hibernation, you need to create a [[swap]] partition or file. You will need to point the kernel to your swap using the {{ic|1=resume=}} kernel parameter, which is configured via the boot loader. You will also need to [[#Configure the initramfs|configure the initramfs]]. This tells the kernel to attempt resuming from the specified swap in early userspace. These three steps are described in detail below.<br />
<br />
{{Note|<br />
* See [[Dm-crypt/Swap encryption#With suspend-to-disk support]] when using [[encryption]].<br />
* {{Pkg|linux-hardened}} does not support hibernation, see {{Bug|63648}}.<br />
}}<br />
<br />
=== About swap partition/file size ===<br />
<br />
Even if your swap partition is smaller than RAM, you still have a big chance of hibernating successfully. See "image_size" in the [https://docs.kernel.org/admin-guide/pm/sleep-states.html?highlight=image_size#basic-sysfs-interfaces-for-system-suspend-and-hibernation kernel documentation] for information on the {{ic|image_size}} {{man|5|sysfs}} pseudo-file.<br />
<br />
You may either decrease the value of {{ic|/sys/power/image_size}} to make the suspend image as small as possible (for small swap partitions), or increase it to possibly speed up the hibernation process. For systems with a large amount of RAM, smaller values may drastically increase the speed of resuming a hibernating system. [[systemd#systemd-tmpfiles - temporary files]] can be used to make this change persistent:<br />
<br />
{{hc|/etc/tmpfiles.d/hibernation_image_size.conf|<br />
# Path Mode UID GID Age Argument<br />
w /sys/power/image_size - - - - 0<br />
}}<br />
<br />
The suspend image cannot span multiple swap partitions and/or swap files. It must fully fit in one swap partition or one swap file.[https://docs.kernel.org/power/swsusp.html]<br />
<br />
=== Configure the initramfs ===<br />
<br />
* When an [[initramfs]] with the {{ic|base}} hook is used, which is the default, the {{ic|resume}} hook is required in {{ic|/etc/mkinitcpio.conf}}. Whether by label or by UUID, the swap partition is referred to with a udev device node, so the {{ic|resume}} hook must go ''after'' the {{ic|udev}} hook. This example was made starting from the default hook configuration:<br />
<br />
:{{bc|1=HOOKS=(base udev autodetect keyboard modconf block filesystems '''resume''' fsck)}}<br />
<br />
:Remember to [[regenerate the initramfs]] for these changes to take effect.<br />
<br />
:{{Note|[[LVM]] users should add the {{ic|resume}} hook after {{ic|lvm2}}.}}<br />
<br />
* When an initramfs with the {{ic|systemd}} hook is used, a resume mechanism is already provided, and no further hooks need to be added.<br />
<br />
=== Required kernel parameters ===<br />
<br />
The [[kernel parameter]] {{ic|1=resume=''swap_device''}} must be used. Any of the [[persistent block device naming]] methods can be used as {{ic|''swap_device''}}. For example:<br />
<br />
* {{ic|1=resume=UUID=4209c845-f495-4c43-8a03-5363dd433153}}<br />
* {{ic|1=resume="PARTLABEL=Swap partition"}}<br />
* {{ic|1=resume=/dev/archVolumeGroup/archLogicalVolume}} -- if swap is on a [[LVM]] logical volume (UUID and Label should also work)<br />
<br />
The kernel parameters will only take effect after rebooting. To be able to hibernate right away, obtain the volume's major and minor device numbers from [[lsblk]] and echo them in format {{ic|''major'':''minor''}} to {{ic|/sys/power/resume}}. If using a swap file, additionally echo the resume offset to {{ic|/sys/power/resume_offset}}.[https://docs.kernel.org/power/swsusp.html]<br />
<br />
For example, if the swap device is {{ic|8:3}}:<br />
<br />
# echo 8:3 > /sys/power/resume<br />
<br />
Or when hibernating to a swap file, if the swap file is on volume {{ic|8:2}} and has the offset {{ic|38912}}:<br />
<br />
# echo 8:2 > /sys/power/resume<br />
# echo 38912 > /sys/power/resume_offset<br />
<br />
==== Hibernation into swap file ====<br />
<br />
{{Warning|[[Btrfs#Swap file|Btrfs]] on Linux kernel before version 5.0 does not support swap files. Failure to heed this warning may result in file system corruption. While a swap file may be used on Btrfs when mounted through a loop device, this will result in severely degraded swap performance.}}<br />
<br />
Using a [[swap#Manually|swap file]] requires also setting the {{ic|1=resume=''swap_device''}} and additionally a {{ic|1=resume_offset=''swap_file_offset''}} [[kernel parameters]]. See [https://docs.kernel.org/power/swsusp-and-swap-files.html the kernel documentation].<br />
<br />
{{ic|''swap_device''}} is the volume where the swap file resides and it follows the same format as for the [[Persistent block device naming#Kernel parameters|root parameter]]. The value of {{ic|''swap_file_offset''}} can be obtained by running {{ic|filefrag -v ''swap_file''}}, the output is in a table format and the required value is located in the first row of the {{ic|physical_offset}} column. For example:<br />
<br />
{{hc|# filefrag -v /swapfile|<br />
Filesystem type is: ef53<br />
File size of /swapfile is 4294967296 (1048576 blocks of 4096 bytes)<br />
ext: logical_offset: physical_offset: length: expected: flags:<br />
0: 0.. 0: '''38912'''.. 38912: 1: <br />
1: 1.. 22527: 38913.. 61439: 22527: unwritten<br />
2: 22528.. 53247: 899072.. 929791: 30720: 61440: unwritten<br />
...<br />
}}<br />
<br />
In the example the value of {{ic|''swap_file_offset''}} is the first {{ic|38912}} with the two periods.<br />
<br />
{{Tip|<br />
* The following command may be used to identify {{ic|''swap_device''}}: {{ic|1=findmnt -no UUID -T /swapfile}}<br />
* The following command may be used to identify {{ic|''swap_file_offset''}}: {{ic|1=filefrag -v /swapfile {{!}} awk '$1=="0:" {print substr($4, 1, length($4)-2)}'}}<br />
* The value of {{ic|''swap_file_offset''}} can also be obtained by running {{ic|swap-offset ''swap_file''}}. The ''swap-offset'' binary is provided within the set of tools [[uswsusp]]. If using this method, then these two parameters have to be provided in {{ic|/etc/suspend.conf}} via the keys {{ic|resume device}} and {{ic|resume offset}}. No reboot is required in this case.<br />
}}<br />
<br />
{{Note|<br />
* For a stacked block device such as an encrypted container (LUKS), RAID or LVM, the {{ic|resume}} parameter must point to the unlocked/mapped device that contains the file system with the swap file.<br />
* If the swap file is in {{ic|/home/}}, ''systemd-logind'' will not be able to determine its size and thus will prevent hibernation with the following message: {{ic|Failed to hibernate system via logind: Not enough swap space for hibernation}}. See [https://github.com/systemd/systemd/issues/15354 systemd issue 15354] for two workarounds.<br />
}}<br />
<br />
{{Tip|You might want to decrease the [[swappiness]] for your swap file if the only purpose is to be able to hibernate and not expand RAM.}}<br />
<br />
==== Hibernation into swap file on Btrfs ====<br />
<br />
The resume_offset number can be computed using the [https://github.com/osandov/osandov-linux/blob/master/scripts/btrfs_map_physical.c tool btrfs_map_physical.c].<br />
Do not try to use the filefrag tool, on [[Btrfs]] the "physical" offset you get from filefrag is not the real physical offset on disk; there is a virtual disk address space in order to support multiple devices. [https://bugzilla.kernel.org/show_bug.cgi?id=202803]<br />
<br />
Download or copy the [https://github.com/osandov/osandov-linux/blob/master/scripts/btrfs_map_physical.c tool btrfs_map_physical.c] into a file named {{ic|btrfs_map_physical.c}}, then compile it,<br />
<br />
$ gcc -O2 -o btrfs_map_physical btrfs_map_physical.c<br />
<br />
and run it. An example output is shown below.<br />
<br />
{{hc|# ./btrfs_map_physical ''/path/to/swapfile''|<br />
FILE OFFSET EXTENT TYPE LOGICAL SIZE LOGICAL OFFSET PHYSICAL SIZE DEVID PHYSICAL OFFSET<br />
0 regular 4096 2927632384 268435456 1 '''4009762816'''<br />
4096 prealloc 268431360 2927636480 268431360 1 4009766912<br />
268435456 prealloc 268435456 3251634176 268435456 1 4333764608<br />
536870912 prealloc 268435456 3520069632 268435456 1 4602200064<br />
805306368 prealloc 268435456 3788505088 268435456 1 4870635520<br />
1073741824 prealloc 268435456 4056940544 268435456 1 5139070976<br />
1342177280 prealloc 268435456 4325376000 268435456 1 5407506432<br />
1610612736 prealloc 268435456 4593811456 268435456 1 5675941888<br />
}}<br />
<br />
Note the the first physical offset returned by this tool. In this example, we use {{ic|4009762816}}. Also note the pagesize that can be found with {{ic|getconf PAGESIZE}}.<br />
<br />
To compute the {{ic|resume_offset}} value, divide the physical offset by the pagesize. In this example, it is {{ic|1=4009762816 / 4096 = 978946}}.<br />
<br />
==== Hibernation into a thinly-provisioned LVM volume ====<br />
<br />
Hibernation into a thinly-provisioned [[LVM]] volume is possible, but you have to make sure that the volume is fully allocated. Otherwise resuming from it will fail, see {{Bug|50703}}.<br />
<br />
You can fully allocate the LVM volume by simply filling it with zeros. E.g.:<br />
<br />
# dd if=/dev/zero of=/dev/vg0/swap bs=1M status=progress<br />
<br />
To verify the volume is fully allocated, you can use:<br />
<br />
{{hc|# lvs|<br />
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert<br />
swap vg0 Vwi-aot--- 10.00g pool 100<br />
}}<br />
<br />
A fully allocated volume will show up as having 100% data usage.<br />
<br />
{{Warning|Do not to use [[TRIM]] on thinly-provisioned swap volumes that are used for hibernation, i.e. do not use {{ic|discard}} in {{ic|/etc/fstab}} and the {{ic|-d}}/{{ic|--discard}} option of ''swapon''. Otherwise the used space will be deallocated.}}<br />
<br />
== Intel Rapid Start Technology (IRST) ==<br />
<br />
Intel Rapid Start Technology is a firmware solution to hibernation that allows hibernating from sleep after a predefined interval or battery state. This should be faster and more reliable than regular hibernation as it is done by firmware instead of at the operating system level. Generally it must enabled in the firmware and the firmware also provides support for setting the duration after suspend/battery event triggering hibernation, however some devices despite supporting IRST in the firmware, only allow it to be configured via Intel's Windows drivers. In such cases the intel-rst kernel module described below should be able to configure the events under Linux.<br />
<br />
With Intel Rapid Start Technology (IRST) enabled, resuming from a deep sleep takes "[https://mjg59.dreamwidth.org/26022.html a few seconds longer than resuming from S3 but is far faster than resuming from hibernation]".<br />
<br />
Many Intel-based systems have firmware support for IRST but require a special partition on an SSD (rather than an HDD). OEM deployments of Windows may already have a preexisting IRST partition which can be retained during the Arch Linux installation process (rather than wiping and re-partitioning the whole SSD). It should show up as an unformatted partition equal in size to the system's RAM.<br />
<br />
{{Warning|The Intel Rapid Start partition is not encrypted; "Intel recommends disabling Intel Rapid Start Technology if you are using software-based disk encryption".[https://www.intel.com/content/www/us/en/support/articles/000024080/technologies.html]}}<br />
<br />
However, if you intend to wipe and re-partition the whole drive (or have already done so), then the IRST partition must be recreated if you also plan on using the technology. This can be done by creating an empty partition equal in size to the system's RAM and by setting its partition type to [[Wikipedia:GUID Partition Table#Partition type GUIDs|GUID]] {{ic|D3BFE2DE-3DAF-11DF-BA40-E3A556D89593}} for a [[GPT]] partition or [[Wikipedia:Partition type|ID]] {{ic|0x84}} for an [[MBR]] partition. You may also need to enable support for IRST in your system's firmware settings.<br />
<br />
{{Tip|The duration of time before IRST kicks in (after suspending) can be adjusted in the system's firmware settings.}}<br />
<br />
The duration of the IRST hibernation process (i.e., copying the "entire contents of RAM to a special partition") is dependent on the system's RAM size and SSD speed and can thus take 20–60 seconds. Some systems may indicate the process's completion with an LED indicator, e.g., when it stops blinking.<br />
<br />
Configuring IRST hibernation events in Linux requires {{ic|1=CONFIG_INTEL_RST=y}} or if set to module, the intel-rst module loaded. Once loaded via {{ic|modprobe intel_rst}}, it should create files wakeup_events and wakeup_time under for e.g. {{ic|/sys/bus/acpi/drivers/intel_rapid_start/*/wakeup_events}} that can be used for further configuration. This module is tersely documented, see the source [https://github.com/torvalds/linux/blob/143a6252e1b8ab424b4b293512a97cca7295c182/drivers/platform/x86/intel/rst.c drivers/platform/x86/intel/rst.c] for more details.<br />
<br />
See also the [https://www.intel.com/content/www/us/en/support/articles/000024078/technologies.html general Q&A] and [https://www.intel.com/content/www/us/en/support/articles/000005836/boards-and-kits/desktop-boards.html user guides] for Intel Rapid Start Technology.<br />
<br />
== Troubleshooting ==<br />
<br />
=== ACPI_OS_NAME ===<br />
<br />
You might want to tweak your '''DSDT table''' to make it work. See [[DSDT]].<br />
<br />
=== Suspend/hibernate does not work, or does not work consistently ===<br />
<br />
There have been many reports about the screen going black without easily viewable errors or the ability to do anything when going into and coming back from suspend and/or hibernate. These problems have been seen on both laptops and desktops. This is not an official solution, but switching to an older kernel, especially the LTS-kernel, will probably fix this.<br />
<br />
Also problem may arise when using hardware watchdog timer (disabled by default, see {{ic|1=RuntimeWatchdogSec=}} in {{man|5|systemd-system.conf|OPTIONS}}). Bugged watchdog timer may reset the computer before the system finished creating the hibernation image.<br />
<br />
Sometimes the screen goes black due to device initialization from within the initramfs. Removing any modules you might have in [[Mkinitcpio#MODULES]] and rebuilding the initramfs, can possibly solve this issue, specially graphics drivers for [[Kernel mode setting#Early KMS start|early KMS]]. Initializing such devices before resuming can cause inconsistencies that prevents the system resuming from hibernation. This does not affect resuming from RAM. Also, check the blog article [https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues best practices to debug suspend issues].<br />
<br />
Moving from the [[radeon]] video driver to the newer [[AMDGPU]] driver could also help to make the hibernation and awakening process successful.<br />
<br />
For Intel graphics drivers, enabling early KMS may help to solve the blank screen issue. Refer to [[Kernel mode setting#Early KMS start]] for details.<br />
<br />
After upgrading to kernel 4.15.3, resume may fail with a static (non-blinking) cursor on a black screen. [[Blacklisting]] the module {{ic|nvidiafb}} might help. [https://bbs.archlinux.org/viewtopic.php?id=234646]<br />
<br />
Laptops with Intel CPU that load {{ic|intel_lpss_pci}} module for touchpad, may face kernel panic on resume (blinking caps lock) [https://bbs.archlinux.org/viewtopic.php?id=231881]. The module needs to be added to [[initramfs]] as:<br />
<br />
{{hc|head=/etc/mkinitcpio.conf|output=<br />
MODULES=(... intel_lpss_pci ...)<br />
}}<br />
<br />
Then [[regenerate the initramfs]].<br />
<br />
=== Wake-on-LAN ===<br />
<br />
If [[Wake-on-LAN]] is active, the network interface card will consume power even if the computer is hibernated.<br />
<br />
=== Instantaneous wakeups from suspend ===<br />
<br />
See [[Wakeup triggers#Instantaneous wakeups from suspend]].<br />
<br />
=== System does not power off when hibernating ===<br />
<br />
When you hibernate your system, the system should power off (after saving the state on the disk). Sometimes, you might see the power LED is still glowing. If that happens, it might be instructive to set the {{ic|HibernateMode}} to {{ic|shutdown}} in {{man|5|sleep.conf.d}}:<br />
<br />
{{hc|/etc/systemd/sleep.conf.d/hibernatemode.conf|2=<br />
[Sleep]<br />
HibernateMode=shutdown<br />
}}<br />
<br />
With the above configuration, if everything else is set up correctly, on invocation of a {{ic|systemctl hibernate}} the machine will shutdown saving state to disk as it does so.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Power_management/Suspend_and_hibernate&diff=740219Power management/Suspend and hibernate2022-08-05T16:35:10Z<p>Crescent: /* Intel Rapid Start Technology (IRST) */ Minor clarity</p>
<hr />
<div>[[Category:Power management]]<br />
[[de:Bereitschaft und Ruhezustand]]<br />
[[es:Power management (Español)/Suspend and hibernate]]<br />
[[ja:サスペンドとハイバネート]]<br />
[[ru:Power management (Русский)/Suspend and hibernate]]<br />
[[zh-hans:Power management (简体中文)/Suspend and hibernate]]<br />
{{Related articles start}}<br />
{{Related|Uswsusp}}<br />
{{Related|systemd}}<br />
{{Related|Power management}}<br />
{{Related|Wakeup triggers}}<br />
{{Related|swap}}<br />
{{Related articles end}}<br />
<br />
Currently there are three methods of suspending available:<br />
<br />
; Suspend to RAM (aka suspend, aka sleep): The '''S3''' sleeping state as defined by ACPI. Works by cutting off power to most parts of the machine aside from the RAM, which is required to restore the machine's state. Because of the large power savings, it is advisable for laptops to automatically enter this mode when the computer is running on batteries and the lid is closed (or the user is inactive for some time).<br />
; Suspend to disk (aka hibernate): The '''S4''' sleeping state as defined by ACPI. Saves the machine's state into [[swap space]] and completely powers off the machine. When the machine is powered on, the state is restored. Until then, there is [[Wikipedia:Standby power|zero]] power consumption.<br />
; Suspend to both: A hybrid of the aforementioned methods, sometimes called '''hybrid suspend'''. Saves the machine's state into swap space, but does not power off the machine. Instead, it invokes usual suspend to RAM. Therefore, if the battery is not depleted, the system can resume from RAM. If the battery is depleted, the system can be resumed from disk, which is much slower than resuming from RAM, but the machine's state has not been lost.<br />
<br />
There are multiple low level interfaces (backends) providing basic functionality, and some high level interfaces providing tweaks to handle problematic hardware drivers/kernel modules (e.g. video card re-initialization).<br />
<br />
{{Expansion|Document "suspend to idle" (called [https://docs.kernel.org/admin-guide/pm/sleep-states.html#suspend-to-idle S2Idle] by the kernel, [https://01.org/blogs/qwang59/2018/how-achieve-s0ix-states-linux S0ix] by Intel and [https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby Modern Standby] by Microsoft) and {{ic|/sys/power/mem_sleep}} values.}}<br />
<br />
== Low level interfaces ==<br />
<br />
Though these interfaces can be used directly, it is advisable to use the [[#High level interfaces|high level interfaces]] to suspend/hibernate. Using low level interfaces directly is significantly faster than using any high level interface, since running all the pre- and post-suspend hooks takes time, but hooks can properly set hardware clock, restore wireless etc.<br />
<br />
=== kernel (swsusp) ===<br />
<br />
The most straightforward approach is to directly inform the in-kernel software suspend code (swsusp) to enter a suspended state; the exact method and state depends on the level of hardware support. On modern kernels, writing appropriate strings to {{ic|/sys/power/state}} is the primary mechanism to trigger this suspend.<br />
<br />
See [https://docs.kernel.org/admin-guide/pm/sleep-states.html kernel documentation] for details.<br />
<br />
=== uswsusp ===<br />
<br />
The uswsusp ('Userspace Software Suspend') is a wrapper around the kernel's suspend-to-RAM mechanism, which performs some graphics adapter manipulations from userspace before suspending and after resuming.<br />
<br />
See main article [[Uswsusp]].<br />
<br />
== High level interfaces ==<br />
<br />
The end goal of these packages is to provide binaries/scripts that can be invoked to perform suspend/hibernate. Actually hooking them up to power buttons or menu clicks or laptop lid events is usually left to other tools. To automatically suspend/hibernate on certain power events, such as laptop lid close or battery depletion percentage, you may want to look into running [[Acpid]].<br />
<br />
=== systemd ===<br />
<br />
[[systemd]] provides native commands for suspend, hibernate and a hybrid suspend, see [[Power management#Power management with systemd]] for details. This is the default interface used in Arch Linux.<br />
<br />
See [[Power management#Sleep hooks]] for additional information on configuring suspend/hibernate hooks. Also see {{man|1|systemctl}}, {{man|8|systemd-sleep}}, and {{man|7|systemd.special}}.<br />
<br />
== Hibernation ==<br />
<br />
In order to use hibernation, you need to create a [[swap]] partition or file. You will need to point the kernel to your swap using the {{ic|1=resume=}} kernel parameter, which is configured via the boot loader. You will also need to [[#Configure the initramfs|configure the initramfs]]. This tells the kernel to attempt resuming from the specified swap in early userspace. These three steps are described in detail below.<br />
<br />
{{Note|<br />
* See [[Dm-crypt/Swap encryption#With suspend-to-disk support]] when using [[encryption]].<br />
* {{Pkg|linux-hardened}} does not support hibernation, see {{Bug|63648}}.<br />
}}<br />
<br />
=== About swap partition/file size ===<br />
<br />
Even if your swap partition is smaller than RAM, you still have a big chance of hibernating successfully. See "image_size" in the [https://docs.kernel.org/admin-guide/pm/sleep-states.html?highlight=image_size#basic-sysfs-interfaces-for-system-suspend-and-hibernation kernel documentation] for information on the {{ic|image_size}} {{man|5|sysfs}} pseudo-file.<br />
<br />
You may either decrease the value of {{ic|/sys/power/image_size}} to make the suspend image as small as possible (for small swap partitions), or increase it to possibly speed up the hibernation process. For systems with a large amount of RAM, smaller values may drastically increase the speed of resuming a hibernating system. [[systemd#systemd-tmpfiles - temporary files]] can be used to make this change persistent:<br />
<br />
{{hc|/etc/tmpfiles.d/hibernation_image_size.conf|<br />
# Path Mode UID GID Age Argument<br />
w /sys/power/image_size - - - - 0<br />
}}<br />
<br />
The suspend image cannot span multiple swap partitions and/or swap files. It must fully fit in one swap partition or one swap file.[https://docs.kernel.org/power/swsusp.html]<br />
<br />
=== Configure the initramfs ===<br />
<br />
* When an [[initramfs]] with the {{ic|base}} hook is used, which is the default, the {{ic|resume}} hook is required in {{ic|/etc/mkinitcpio.conf}}. Whether by label or by UUID, the swap partition is referred to with a udev device node, so the {{ic|resume}} hook must go ''after'' the {{ic|udev}} hook. This example was made starting from the default hook configuration:<br />
<br />
:{{bc|1=HOOKS=(base udev autodetect keyboard modconf block filesystems '''resume''' fsck)}}<br />
<br />
:Remember to [[regenerate the initramfs]] for these changes to take effect.<br />
<br />
:{{Note|[[LVM]] users should add the {{ic|resume}} hook after {{ic|lvm2}}.}}<br />
<br />
* When an initramfs with the {{ic|systemd}} hook is used, a resume mechanism is already provided, and no further hooks need to be added.<br />
<br />
=== Required kernel parameters ===<br />
<br />
The [[kernel parameter]] {{ic|1=resume=''swap_device''}} must be used. Any of the [[persistent block device naming]] methods can be used as {{ic|''swap_device''}}. For example:<br />
<br />
* {{ic|1=resume=UUID=4209c845-f495-4c43-8a03-5363dd433153}}<br />
* {{ic|1=resume="PARTLABEL=Swap partition"}}<br />
* {{ic|1=resume=/dev/archVolumeGroup/archLogicalVolume}} -- if swap is on a [[LVM]] logical volume (UUID and Label should also work)<br />
<br />
The kernel parameters will only take effect after rebooting. To be able to hibernate right away, obtain the volume's major and minor device numbers from [[lsblk]] and echo them in format {{ic|''major'':''minor''}} to {{ic|/sys/power/resume}}. If using a swap file, additionally echo the resume offset to {{ic|/sys/power/resume_offset}}.[https://docs.kernel.org/power/swsusp.html]<br />
<br />
For example, if the swap device is {{ic|8:3}}:<br />
<br />
# echo 8:3 > /sys/power/resume<br />
<br />
Or when hibernating to a swap file, if the swap file is on volume {{ic|8:2}} and has the offset {{ic|38912}}:<br />
<br />
# echo 8:2 > /sys/power/resume<br />
# echo 38912 > /sys/power/resume_offset<br />
<br />
==== Hibernation into swap file ====<br />
<br />
{{Warning|[[Btrfs#Swap file|Btrfs]] on Linux kernel before version 5.0 does not support swap files. Failure to heed this warning may result in file system corruption. While a swap file may be used on Btrfs when mounted through a loop device, this will result in severely degraded swap performance.}}<br />
<br />
Using a [[swap#Manually|swap file]] requires also setting the {{ic|1=resume=''swap_device''}} and additionally a {{ic|1=resume_offset=''swap_file_offset''}} [[kernel parameters]]. See [https://docs.kernel.org/power/swsusp-and-swap-files.html the kernel documentation].<br />
<br />
{{ic|''swap_device''}} is the volume where the swap file resides and it follows the same format as for the [[Persistent block device naming#Kernel parameters|root parameter]]. The value of {{ic|''swap_file_offset''}} can be obtained by running {{ic|filefrag -v ''swap_file''}}, the output is in a table format and the required value is located in the first row of the {{ic|physical_offset}} column. For example:<br />
<br />
{{hc|# filefrag -v /swapfile|<br />
Filesystem type is: ef53<br />
File size of /swapfile is 4294967296 (1048576 blocks of 4096 bytes)<br />
ext: logical_offset: physical_offset: length: expected: flags:<br />
0: 0.. 0: '''38912'''.. 38912: 1: <br />
1: 1.. 22527: 38913.. 61439: 22527: unwritten<br />
2: 22528.. 53247: 899072.. 929791: 30720: 61440: unwritten<br />
...<br />
}}<br />
<br />
In the example the value of {{ic|''swap_file_offset''}} is the first {{ic|38912}} with the two periods.<br />
<br />
{{Tip|<br />
* The following command may be used to identify {{ic|''swap_device''}}: {{ic|1=findmnt -no UUID -T /swapfile}}<br />
* The following command may be used to identify {{ic|''swap_file_offset''}}: {{ic|1=filefrag -v /swapfile {{!}} awk '$1=="0:" {print substr($4, 1, length($4)-2)}'}}<br />
* The value of {{ic|''swap_file_offset''}} can also be obtained by running {{ic|swap-offset ''swap_file''}}. The ''swap-offset'' binary is provided within the set of tools [[uswsusp]]. If using this method, then these two parameters have to be provided in {{ic|/etc/suspend.conf}} via the keys {{ic|resume device}} and {{ic|resume offset}}. No reboot is required in this case.<br />
}}<br />
<br />
{{Note|<br />
* For a stacked block device such as an encrypted container (LUKS), RAID or LVM, the {{ic|resume}} parameter must point to the unlocked/mapped device that contains the file system with the swap file.<br />
* If the swap file is in {{ic|/home/}}, ''systemd-logind'' will not be able to determine its size and thus will prevent hibernation with the following message: {{ic|Failed to hibernate system via logind: Not enough swap space for hibernation}}. See [https://github.com/systemd/systemd/issues/15354 systemd issue 15354] for two workarounds.<br />
}}<br />
<br />
{{Tip|You might want to decrease the [[swappiness]] for your swap file if the only purpose is to be able to hibernate and not expand RAM.}}<br />
<br />
==== Hibernation into swap file on Btrfs ====<br />
<br />
The resume_offset number can be computed using the [https://github.com/osandov/osandov-linux/blob/master/scripts/btrfs_map_physical.c tool btrfs_map_physical.c].<br />
Do not try to use the filefrag tool, on [[Btrfs]] the "physical" offset you get from filefrag is not the real physical offset on disk; there is a virtual disk address space in order to support multiple devices. [https://bugzilla.kernel.org/show_bug.cgi?id=202803]<br />
<br />
Download or copy the [https://github.com/osandov/osandov-linux/blob/master/scripts/btrfs_map_physical.c tool btrfs_map_physical.c] into a file named {{ic|btrfs_map_physical.c}}, then compile it,<br />
<br />
$ gcc -O2 -o btrfs_map_physical btrfs_map_physical.c<br />
<br />
and run it. An example output is shown below.<br />
<br />
{{hc|# ./btrfs_map_physical ''/path/to/swapfile''|<br />
FILE OFFSET EXTENT TYPE LOGICAL SIZE LOGICAL OFFSET PHYSICAL SIZE DEVID PHYSICAL OFFSET<br />
0 regular 4096 2927632384 268435456 1 '''4009762816'''<br />
4096 prealloc 268431360 2927636480 268431360 1 4009766912<br />
268435456 prealloc 268435456 3251634176 268435456 1 4333764608<br />
536870912 prealloc 268435456 3520069632 268435456 1 4602200064<br />
805306368 prealloc 268435456 3788505088 268435456 1 4870635520<br />
1073741824 prealloc 268435456 4056940544 268435456 1 5139070976<br />
1342177280 prealloc 268435456 4325376000 268435456 1 5407506432<br />
1610612736 prealloc 268435456 4593811456 268435456 1 5675941888<br />
}}<br />
<br />
Note the the first physical offset returned by this tool. In this example, we use {{ic|4009762816}}. Also note the pagesize that can be found with {{ic|getconf PAGESIZE}}.<br />
<br />
To compute the {{ic|resume_offset}} value, divide the physical offset by the pagesize. In this example, it is {{ic|1=4009762816 / 4096 = 978946}}.<br />
<br />
==== Hibernation into a thinly-provisioned LVM volume ====<br />
<br />
Hibernation into a thinly-provisioned [[LVM]] volume is possible, but you have to make sure that the volume is fully allocated. Otherwise resuming from it will fail, see {{Bug|50703}}.<br />
<br />
You can fully allocate the LVM volume by simply filling it with zeros. E.g.:<br />
<br />
# dd if=/dev/zero of=/dev/vg0/swap bs=1M status=progress<br />
<br />
To verify the volume is fully allocated, you can use:<br />
<br />
{{hc|# lvs|<br />
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert<br />
swap vg0 Vwi-aot--- 10.00g pool 100<br />
}}<br />
<br />
A fully allocated volume will show up as having 100% data usage.<br />
<br />
{{Warning|Do not to use [[TRIM]] on thinly-provisioned swap volumes that are used for hibernation, i.e. do not use {{ic|discard}} in {{ic|/etc/fstab}} and the {{ic|-d}}/{{ic|--discard}} option of ''swapon''. Otherwise the used space will be deallocated.}}<br />
<br />
== Intel Rapid Start Technology (IRST) ==<br />
<br />
Intel Rapid Start Technology is a firmware solution to hibernation that allows hibernating from sleep after a predefined interval or battery state. This should be faster and more reliable than regular hibernation as it is done by firmware instead of at the operating system level. Generally it must enabled in the firmware and the firmware also provides support for setting the duration after suspend/battery event triggering hibernation, however some devices despite supporting IRST in the firmware, only allow it to be configured via Intel's Windows drivers. In such cases the intel-rst kernel module described below should be able to configure the events under linux.<br />
<br />
With Intel Rapid Start Technology (IRST) enabled, resuming from a deep sleep takes "[https://mjg59.dreamwidth.org/26022.html a few seconds longer than resuming from S3 but is far faster than resuming from hibernation]".<br />
<br />
Many Intel-based systems have firmware support for IRST but require a special partition on an SSD (rather than an HDD). OEM deployments of Windows may already have a preexisting IRST partition which can be retained during the Arch Linux installation process (rather than wiping and repartitioning the whole SSD). It should show up as an unformatted partition equal in size to the system's RAM.<br />
<br />
{{Warning|The Intel Rapid Start partition is not encrypted; "Intel recommends disabling Intel Rapid Start Technology if you are using software-based disk encryption".[https://www.intel.com/content/www/us/en/support/articles/000024080/technologies.html]}}<br />
<br />
However, if you intend to wipe and repartition the whole drive (or have already done so), then the IRST partition must be recreated if you also plan on using the technology. This can be done by creating an empty partition equal in size to the system's RAM and by setting its partition type to [[Wikipedia:GUID Partition Table#Partition type GUIDs|GUID]] {{ic|D3BFE2DE-3DAF-11DF-BA40-E3A556D89593}} for a [[GPT]] partition or [[Wikipedia:Partition type|ID]] {{ic|0x84}} for an [[MBR]] partition. You may also need to enable support for IRST in your system's firmware settings.<br />
<br />
{{Tip|The duration of time before IRST kicks in (after suspending) can be adjusted in the system's firmware settings.}}<br />
<br />
The duration of the IRST hibernation process (i.e., copying the "entire contents of RAM to a special partition") is dependant on the system's RAM size and SSD speed and can thus take 20–60 seconds. Some systems may indicate the process's completion with an LED indicator, e.g., when it stops blinking.<br />
<br />
Configuring IRST hibernation events in linux requires CONFIG_INTEL_RST=y or if set to module, the intel-rst module loaded. Once loaded via <code>modprobe intel_rst</code>, it should create files wakeup_events and wakeup_time under for eg. <code>/acpi/drivers/intel_rapid_start/*/wakeup_events</code> that can be used for further configuration. This module is tersely documented, see the source [https://github.com/torvalds/linux/blob/143a6252e1b8ab424b4b293512a97cca7295c182/drivers/platform/x86/intel/rst.c drivers/platform/x86/intel/rst.c] for more details.<br />
<br />
See also the [https://www.intel.com/content/www/us/en/support/articles/000024078/technologies.html general Q&A] and [https://www.intel.com/content/www/us/en/support/articles/000005836/boards-and-kits/desktop-boards.html user guides] for Intel Rapid Start Technology.<br />
<br />
== Troubleshooting ==<br />
<br />
=== ACPI_OS_NAME ===<br />
<br />
You might want to tweak your '''DSDT table''' to make it work. See [[DSDT]].<br />
<br />
=== Suspend/hibernate does not work, or does not work consistently ===<br />
<br />
There have been many reports about the screen going black without easily viewable errors or the ability to do anything when going into and coming back from suspend and/or hibernate. These problems have been seen on both laptops and desktops. This is not an official solution, but switching to an older kernel, especially the LTS-kernel, will probably fix this.<br />
<br />
Also problem may arise when using hardware watchdog timer (disabled by default, see {{ic|1=RuntimeWatchdogSec=}} in {{man|5|systemd-system.conf|OPTIONS}}). Bugged watchdog timer may reset the computer before the system finished creating the hibernation image.<br />
<br />
Sometimes the screen goes black due to device initialization from within the initramfs. Removing any modules you might have in [[Mkinitcpio#MODULES]] and rebuilding the initramfs, can possibly solve this issue, specially graphics drivers for [[Kernel mode setting#Early KMS start|early KMS]]. Initializing such devices before resuming can cause inconsistencies that prevents the system resuming from hibernation. This does not affect resuming from RAM. Also, check the blog article [https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues best practices to debug suspend issues].<br />
<br />
Moving from the [[radeon]] video driver to the newer [[AMDGPU]] driver could also help to make the hibernation and awakening process successful.<br />
<br />
For Intel graphics drivers, enabling early KMS may help to solve the blank screen issue. Refer to [[Kernel mode setting#Early KMS start]] for details.<br />
<br />
After upgrading to kernel 4.15.3, resume may fail with a static (non-blinking) cursor on a black screen. [[Blacklisting]] the module {{ic|nvidiafb}} might help. [https://bbs.archlinux.org/viewtopic.php?id=234646]<br />
<br />
Laptops with Intel CPU that load {{ic|intel_lpss_pci}} module for touchpad, may face kernel panic on resume (blinking caps lock) [https://bbs.archlinux.org/viewtopic.php?id=231881]. The module needs to be added to [[initramfs]] as:<br />
<br />
{{hc|head=/etc/mkinitcpio.conf|output=<br />
MODULES=(... intel_lpss_pci ...)<br />
}}<br />
<br />
Then [[regenerate the initramfs]].<br />
<br />
=== Wake-on-LAN ===<br />
<br />
If [[Wake-on-LAN]] is active, the network interface card will consume power even if the computer is hibernated.<br />
<br />
=== Instantaneous wakeups from suspend ===<br />
<br />
See [[Wakeup triggers#Instantaneous wakeups from suspend]].<br />
<br />
=== System does not power off when hibernating ===<br />
<br />
When you hibernate your system, the system should power off (after saving the state on the disk). Sometimes, you might see the power LED is still glowing. If that happens, it might be instructive to set the {{ic|HibernateMode}} to {{ic|shutdown}} in {{man|5|sleep.conf.d}}:<br />
<br />
{{hc|/etc/systemd/sleep.conf.d/hibernatemode.conf|2=<br />
[Sleep]<br />
HibernateMode=shutdown<br />
}}<br />
<br />
With the above configuration, if everything else is set up correctly, on invocation of a {{ic|systemctl hibernate}} the machine will shutdown saving state to disk as it does so.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Power_management/Suspend_and_hibernate&diff=740218Power management/Suspend and hibernate2022-08-05T16:33:37Z<p>Crescent: /* Intel Rapid Start Technology (IRST) */ typo</p>
<hr />
<div>[[Category:Power management]]<br />
[[de:Bereitschaft und Ruhezustand]]<br />
[[es:Power management (Español)/Suspend and hibernate]]<br />
[[ja:サスペンドとハイバネート]]<br />
[[ru:Power management (Русский)/Suspend and hibernate]]<br />
[[zh-hans:Power management (简体中文)/Suspend and hibernate]]<br />
{{Related articles start}}<br />
{{Related|Uswsusp}}<br />
{{Related|systemd}}<br />
{{Related|Power management}}<br />
{{Related|Wakeup triggers}}<br />
{{Related|swap}}<br />
{{Related articles end}}<br />
<br />
Currently there are three methods of suspending available:<br />
<br />
; Suspend to RAM (aka suspend, aka sleep): The '''S3''' sleeping state as defined by ACPI. Works by cutting off power to most parts of the machine aside from the RAM, which is required to restore the machine's state. Because of the large power savings, it is advisable for laptops to automatically enter this mode when the computer is running on batteries and the lid is closed (or the user is inactive for some time).<br />
; Suspend to disk (aka hibernate): The '''S4''' sleeping state as defined by ACPI. Saves the machine's state into [[swap space]] and completely powers off the machine. When the machine is powered on, the state is restored. Until then, there is [[Wikipedia:Standby power|zero]] power consumption.<br />
; Suspend to both: A hybrid of the aforementioned methods, sometimes called '''hybrid suspend'''. Saves the machine's state into swap space, but does not power off the machine. Instead, it invokes usual suspend to RAM. Therefore, if the battery is not depleted, the system can resume from RAM. If the battery is depleted, the system can be resumed from disk, which is much slower than resuming from RAM, but the machine's state has not been lost.<br />
<br />
There are multiple low level interfaces (backends) providing basic functionality, and some high level interfaces providing tweaks to handle problematic hardware drivers/kernel modules (e.g. video card re-initialization).<br />
<br />
{{Expansion|Document "suspend to idle" (called [https://docs.kernel.org/admin-guide/pm/sleep-states.html#suspend-to-idle S2Idle] by the kernel, [https://01.org/blogs/qwang59/2018/how-achieve-s0ix-states-linux S0ix] by Intel and [https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby Modern Standby] by Microsoft) and {{ic|/sys/power/mem_sleep}} values.}}<br />
<br />
== Low level interfaces ==<br />
<br />
Though these interfaces can be used directly, it is advisable to use the [[#High level interfaces|high level interfaces]] to suspend/hibernate. Using low level interfaces directly is significantly faster than using any high level interface, since running all the pre- and post-suspend hooks takes time, but hooks can properly set hardware clock, restore wireless etc.<br />
<br />
=== kernel (swsusp) ===<br />
<br />
The most straightforward approach is to directly inform the in-kernel software suspend code (swsusp) to enter a suspended state; the exact method and state depends on the level of hardware support. On modern kernels, writing appropriate strings to {{ic|/sys/power/state}} is the primary mechanism to trigger this suspend.<br />
<br />
See [https://docs.kernel.org/admin-guide/pm/sleep-states.html kernel documentation] for details.<br />
<br />
=== uswsusp ===<br />
<br />
The uswsusp ('Userspace Software Suspend') is a wrapper around the kernel's suspend-to-RAM mechanism, which performs some graphics adapter manipulations from userspace before suspending and after resuming.<br />
<br />
See main article [[Uswsusp]].<br />
<br />
== High level interfaces ==<br />
<br />
The end goal of these packages is to provide binaries/scripts that can be invoked to perform suspend/hibernate. Actually hooking them up to power buttons or menu clicks or laptop lid events is usually left to other tools. To automatically suspend/hibernate on certain power events, such as laptop lid close or battery depletion percentage, you may want to look into running [[Acpid]].<br />
<br />
=== systemd ===<br />
<br />
[[systemd]] provides native commands for suspend, hibernate and a hybrid suspend, see [[Power management#Power management with systemd]] for details. This is the default interface used in Arch Linux.<br />
<br />
See [[Power management#Sleep hooks]] for additional information on configuring suspend/hibernate hooks. Also see {{man|1|systemctl}}, {{man|8|systemd-sleep}}, and {{man|7|systemd.special}}.<br />
<br />
== Hibernation ==<br />
<br />
In order to use hibernation, you need to create a [[swap]] partition or file. You will need to point the kernel to your swap using the {{ic|1=resume=}} kernel parameter, which is configured via the boot loader. You will also need to [[#Configure the initramfs|configure the initramfs]]. This tells the kernel to attempt resuming from the specified swap in early userspace. These three steps are described in detail below.<br />
<br />
{{Note|<br />
* See [[Dm-crypt/Swap encryption#With suspend-to-disk support]] when using [[encryption]].<br />
* {{Pkg|linux-hardened}} does not support hibernation, see {{Bug|63648}}.<br />
}}<br />
<br />
=== About swap partition/file size ===<br />
<br />
Even if your swap partition is smaller than RAM, you still have a big chance of hibernating successfully. See "image_size" in the [https://docs.kernel.org/admin-guide/pm/sleep-states.html?highlight=image_size#basic-sysfs-interfaces-for-system-suspend-and-hibernation kernel documentation] for information on the {{ic|image_size}} {{man|5|sysfs}} pseudo-file.<br />
<br />
You may either decrease the value of {{ic|/sys/power/image_size}} to make the suspend image as small as possible (for small swap partitions), or increase it to possibly speed up the hibernation process. For systems with a large amount of RAM, smaller values may drastically increase the speed of resuming a hibernating system. [[systemd#systemd-tmpfiles - temporary files]] can be used to make this change persistent:<br />
<br />
{{hc|/etc/tmpfiles.d/hibernation_image_size.conf|<br />
# Path Mode UID GID Age Argument<br />
w /sys/power/image_size - - - - 0<br />
}}<br />
<br />
The suspend image cannot span multiple swap partitions and/or swap files. It must fully fit in one swap partition or one swap file.[https://docs.kernel.org/power/swsusp.html]<br />
<br />
=== Configure the initramfs ===<br />
<br />
* When an [[initramfs]] with the {{ic|base}} hook is used, which is the default, the {{ic|resume}} hook is required in {{ic|/etc/mkinitcpio.conf}}. Whether by label or by UUID, the swap partition is referred to with a udev device node, so the {{ic|resume}} hook must go ''after'' the {{ic|udev}} hook. This example was made starting from the default hook configuration:<br />
<br />
:{{bc|1=HOOKS=(base udev autodetect keyboard modconf block filesystems '''resume''' fsck)}}<br />
<br />
:Remember to [[regenerate the initramfs]] for these changes to take effect.<br />
<br />
:{{Note|[[LVM]] users should add the {{ic|resume}} hook after {{ic|lvm2}}.}}<br />
<br />
* When an initramfs with the {{ic|systemd}} hook is used, a resume mechanism is already provided, and no further hooks need to be added.<br />
<br />
=== Required kernel parameters ===<br />
<br />
The [[kernel parameter]] {{ic|1=resume=''swap_device''}} must be used. Any of the [[persistent block device naming]] methods can be used as {{ic|''swap_device''}}. For example:<br />
<br />
* {{ic|1=resume=UUID=4209c845-f495-4c43-8a03-5363dd433153}}<br />
* {{ic|1=resume="PARTLABEL=Swap partition"}}<br />
* {{ic|1=resume=/dev/archVolumeGroup/archLogicalVolume}} -- if swap is on a [[LVM]] logical volume (UUID and Label should also work)<br />
<br />
The kernel parameters will only take effect after rebooting. To be able to hibernate right away, obtain the volume's major and minor device numbers from [[lsblk]] and echo them in format {{ic|''major'':''minor''}} to {{ic|/sys/power/resume}}. If using a swap file, additionally echo the resume offset to {{ic|/sys/power/resume_offset}}.[https://docs.kernel.org/power/swsusp.html]<br />
<br />
For example, if the swap device is {{ic|8:3}}:<br />
<br />
# echo 8:3 > /sys/power/resume<br />
<br />
Or when hibernating to a swap file, if the swap file is on volume {{ic|8:2}} and has the offset {{ic|38912}}:<br />
<br />
# echo 8:2 > /sys/power/resume<br />
# echo 38912 > /sys/power/resume_offset<br />
<br />
==== Hibernation into swap file ====<br />
<br />
{{Warning|[[Btrfs#Swap file|Btrfs]] on Linux kernel before version 5.0 does not support swap files. Failure to heed this warning may result in file system corruption. While a swap file may be used on Btrfs when mounted through a loop device, this will result in severely degraded swap performance.}}<br />
<br />
Using a [[swap#Manually|swap file]] requires also setting the {{ic|1=resume=''swap_device''}} and additionally a {{ic|1=resume_offset=''swap_file_offset''}} [[kernel parameters]]. See [https://docs.kernel.org/power/swsusp-and-swap-files.html the kernel documentation].<br />
<br />
{{ic|''swap_device''}} is the volume where the swap file resides and it follows the same format as for the [[Persistent block device naming#Kernel parameters|root parameter]]. The value of {{ic|''swap_file_offset''}} can be obtained by running {{ic|filefrag -v ''swap_file''}}, the output is in a table format and the required value is located in the first row of the {{ic|physical_offset}} column. For example:<br />
<br />
{{hc|# filefrag -v /swapfile|<br />
Filesystem type is: ef53<br />
File size of /swapfile is 4294967296 (1048576 blocks of 4096 bytes)<br />
ext: logical_offset: physical_offset: length: expected: flags:<br />
0: 0.. 0: '''38912'''.. 38912: 1: <br />
1: 1.. 22527: 38913.. 61439: 22527: unwritten<br />
2: 22528.. 53247: 899072.. 929791: 30720: 61440: unwritten<br />
...<br />
}}<br />
<br />
In the example the value of {{ic|''swap_file_offset''}} is the first {{ic|38912}} with the two periods.<br />
<br />
{{Tip|<br />
* The following command may be used to identify {{ic|''swap_device''}}: {{ic|1=findmnt -no UUID -T /swapfile}}<br />
* The following command may be used to identify {{ic|''swap_file_offset''}}: {{ic|1=filefrag -v /swapfile {{!}} awk '$1=="0:" {print substr($4, 1, length($4)-2)}'}}<br />
* The value of {{ic|''swap_file_offset''}} can also be obtained by running {{ic|swap-offset ''swap_file''}}. The ''swap-offset'' binary is provided within the set of tools [[uswsusp]]. If using this method, then these two parameters have to be provided in {{ic|/etc/suspend.conf}} via the keys {{ic|resume device}} and {{ic|resume offset}}. No reboot is required in this case.<br />
}}<br />
<br />
{{Note|<br />
* For a stacked block device such as an encrypted container (LUKS), RAID or LVM, the {{ic|resume}} parameter must point to the unlocked/mapped device that contains the file system with the swap file.<br />
* If the swap file is in {{ic|/home/}}, ''systemd-logind'' will not be able to determine its size and thus will prevent hibernation with the following message: {{ic|Failed to hibernate system via logind: Not enough swap space for hibernation}}. See [https://github.com/systemd/systemd/issues/15354 systemd issue 15354] for two workarounds.<br />
}}<br />
<br />
{{Tip|You might want to decrease the [[swappiness]] for your swap file if the only purpose is to be able to hibernate and not expand RAM.}}<br />
<br />
==== Hibernation into swap file on Btrfs ====<br />
<br />
The resume_offset number can be computed using the [https://github.com/osandov/osandov-linux/blob/master/scripts/btrfs_map_physical.c tool btrfs_map_physical.c].<br />
Do not try to use the filefrag tool, on [[Btrfs]] the "physical" offset you get from filefrag is not the real physical offset on disk; there is a virtual disk address space in order to support multiple devices. [https://bugzilla.kernel.org/show_bug.cgi?id=202803]<br />
<br />
Download or copy the [https://github.com/osandov/osandov-linux/blob/master/scripts/btrfs_map_physical.c tool btrfs_map_physical.c] into a file named {{ic|btrfs_map_physical.c}}, then compile it,<br />
<br />
$ gcc -O2 -o btrfs_map_physical btrfs_map_physical.c<br />
<br />
and run it. An example output is shown below.<br />
<br />
{{hc|# ./btrfs_map_physical ''/path/to/swapfile''|<br />
FILE OFFSET EXTENT TYPE LOGICAL SIZE LOGICAL OFFSET PHYSICAL SIZE DEVID PHYSICAL OFFSET<br />
0 regular 4096 2927632384 268435456 1 '''4009762816'''<br />
4096 prealloc 268431360 2927636480 268431360 1 4009766912<br />
268435456 prealloc 268435456 3251634176 268435456 1 4333764608<br />
536870912 prealloc 268435456 3520069632 268435456 1 4602200064<br />
805306368 prealloc 268435456 3788505088 268435456 1 4870635520<br />
1073741824 prealloc 268435456 4056940544 268435456 1 5139070976<br />
1342177280 prealloc 268435456 4325376000 268435456 1 5407506432<br />
1610612736 prealloc 268435456 4593811456 268435456 1 5675941888<br />
}}<br />
<br />
Note the the first physical offset returned by this tool. In this example, we use {{ic|4009762816}}. Also note the pagesize that can be found with {{ic|getconf PAGESIZE}}.<br />
<br />
To compute the {{ic|resume_offset}} value, divide the physical offset by the pagesize. In this example, it is {{ic|1=4009762816 / 4096 = 978946}}.<br />
<br />
==== Hibernation into a thinly-provisioned LVM volume ====<br />
<br />
Hibernation into a thinly-provisioned [[LVM]] volume is possible, but you have to make sure that the volume is fully allocated. Otherwise resuming from it will fail, see {{Bug|50703}}.<br />
<br />
You can fully allocate the LVM volume by simply filling it with zeros. E.g.:<br />
<br />
# dd if=/dev/zero of=/dev/vg0/swap bs=1M status=progress<br />
<br />
To verify the volume is fully allocated, you can use:<br />
<br />
{{hc|# lvs|<br />
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert<br />
swap vg0 Vwi-aot--- 10.00g pool 100<br />
}}<br />
<br />
A fully allocated volume will show up as having 100% data usage.<br />
<br />
{{Warning|Do not to use [[TRIM]] on thinly-provisioned swap volumes that are used for hibernation, i.e. do not use {{ic|discard}} in {{ic|/etc/fstab}} and the {{ic|-d}}/{{ic|--discard}} option of ''swapon''. Otherwise the used space will be deallocated.}}<br />
<br />
== Intel Rapid Start Technology (IRST) ==<br />
<br />
Intel Rapid Start Technology is a firmware solution to hibernation that allows hibernating from sleep after a predefined interval or battery state. This should be faster and more reliable than regular hibernation as it is done by firmware instead of at the operating system level. Generally it must enabled in the firmware and the firmware also provides support for setting the time/battery event triggering hibernation, however some devices despite supporting IRST, only allow it to be configured via Intel's windows drivers. In such cases the intel-rst kernel module described below should be able to configure the events under linux.<br />
<br />
With Intel Rapid Start Technology (IRST) enabled, resuming from a deep sleep takes "[https://mjg59.dreamwidth.org/26022.html a few seconds longer than resuming from S3 but is far faster than resuming from hibernation]".<br />
<br />
Many Intel-based systems have firmware support for IRST but require a special partition on an SSD (rather than an HDD). OEM deployments of Windows may already have a preexisting IRST partition which can be retained during the Arch Linux installation process (rather than wiping and repartitioning the whole SSD). It should show up as an unformatted partition equal in size to the system's RAM.<br />
<br />
{{Warning|The Intel Rapid Start partition is not encrypted; "Intel recommends disabling Intel Rapid Start Technology if you are using software-based disk encryption".[https://www.intel.com/content/www/us/en/support/articles/000024080/technologies.html]}}<br />
<br />
However, if you intend to wipe and repartition the whole drive (or have already done so), then the IRST partition must be recreated if you also plan on using the technology. This can be done by creating an empty partition equal in size to the system's RAM and by setting its partition type to [[Wikipedia:GUID Partition Table#Partition type GUIDs|GUID]] {{ic|D3BFE2DE-3DAF-11DF-BA40-E3A556D89593}} for a [[GPT]] partition or [[Wikipedia:Partition type|ID]] {{ic|0x84}} for an [[MBR]] partition. You may also need to enable support for IRST in your system's firmware settings.<br />
<br />
{{Tip|The duration of time before IRST kicks in (after suspending) can be adjusted in the system's firmware settings.}}<br />
<br />
The duration of the IRST hibernation process (i.e., copying the "entire contents of RAM to a special partition") is dependant on the system's RAM size and SSD speed and can thus take 20–60 seconds. Some systems may indicate the process's completion with an LED indicator, e.g., when it stops blinking.<br />
<br />
Configuring IRST hibernation events in linux requires CONFIG_INTEL_RST=y or if set to module, the intel-rst module loaded. Once loaded via <code>modprobe intel_rst</code>, it should create files wakeup_events and wakeup_time under for eg. <code>/acpi/drivers/intel_rapid_start/*/wakeup_events</code> that can be used for further configuration. This module is tersely documented, see the source [https://github.com/torvalds/linux/blob/143a6252e1b8ab424b4b293512a97cca7295c182/drivers/platform/x86/intel/rst.c drivers/platform/x86/intel/rst.c] for more details.<br />
<br />
See also the [https://www.intel.com/content/www/us/en/support/articles/000024078/technologies.html general Q&A] and [https://www.intel.com/content/www/us/en/support/articles/000005836/boards-and-kits/desktop-boards.html user guides] for Intel Rapid Start Technology.<br />
<br />
== Troubleshooting ==<br />
<br />
=== ACPI_OS_NAME ===<br />
<br />
You might want to tweak your '''DSDT table''' to make it work. See [[DSDT]].<br />
<br />
=== Suspend/hibernate does not work, or does not work consistently ===<br />
<br />
There have been many reports about the screen going black without easily viewable errors or the ability to do anything when going into and coming back from suspend and/or hibernate. These problems have been seen on both laptops and desktops. This is not an official solution, but switching to an older kernel, especially the LTS-kernel, will probably fix this.<br />
<br />
Also problem may arise when using hardware watchdog timer (disabled by default, see {{ic|1=RuntimeWatchdogSec=}} in {{man|5|systemd-system.conf|OPTIONS}}). Bugged watchdog timer may reset the computer before the system finished creating the hibernation image.<br />
<br />
Sometimes the screen goes black due to device initialization from within the initramfs. Removing any modules you might have in [[Mkinitcpio#MODULES]] and rebuilding the initramfs, can possibly solve this issue, specially graphics drivers for [[Kernel mode setting#Early KMS start|early KMS]]. Initializing such devices before resuming can cause inconsistencies that prevents the system resuming from hibernation. This does not affect resuming from RAM. Also, check the blog article [https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues best practices to debug suspend issues].<br />
<br />
Moving from the [[radeon]] video driver to the newer [[AMDGPU]] driver could also help to make the hibernation and awakening process successful.<br />
<br />
For Intel graphics drivers, enabling early KMS may help to solve the blank screen issue. Refer to [[Kernel mode setting#Early KMS start]] for details.<br />
<br />
After upgrading to kernel 4.15.3, resume may fail with a static (non-blinking) cursor on a black screen. [[Blacklisting]] the module {{ic|nvidiafb}} might help. [https://bbs.archlinux.org/viewtopic.php?id=234646]<br />
<br />
Laptops with Intel CPU that load {{ic|intel_lpss_pci}} module for touchpad, may face kernel panic on resume (blinking caps lock) [https://bbs.archlinux.org/viewtopic.php?id=231881]. The module needs to be added to [[initramfs]] as:<br />
<br />
{{hc|head=/etc/mkinitcpio.conf|output=<br />
MODULES=(... intel_lpss_pci ...)<br />
}}<br />
<br />
Then [[regenerate the initramfs]].<br />
<br />
=== Wake-on-LAN ===<br />
<br />
If [[Wake-on-LAN]] is active, the network interface card will consume power even if the computer is hibernated.<br />
<br />
=== Instantaneous wakeups from suspend ===<br />
<br />
See [[Wakeup triggers#Instantaneous wakeups from suspend]].<br />
<br />
=== System does not power off when hibernating ===<br />
<br />
When you hibernate your system, the system should power off (after saving the state on the disk). Sometimes, you might see the power LED is still glowing. If that happens, it might be instructive to set the {{ic|HibernateMode}} to {{ic|shutdown}} in {{man|5|sleep.conf.d}}:<br />
<br />
{{hc|/etc/systemd/sleep.conf.d/hibernatemode.conf|2=<br />
[Sleep]<br />
HibernateMode=shutdown<br />
}}<br />
<br />
With the above configuration, if everything else is set up correctly, on invocation of a {{ic|systemctl hibernate}} the machine will shutdown saving state to disk as it does so.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Power_management/Suspend_and_hibernate&diff=740217Power management/Suspend and hibernate2022-08-05T16:32:42Z<p>Crescent: /* Intel Rapid Start Technology (IRST) */ Add more IRST timer event config details</p>
<hr />
<div>[[Category:Power management]]<br />
[[de:Bereitschaft und Ruhezustand]]<br />
[[es:Power management (Español)/Suspend and hibernate]]<br />
[[ja:サスペンドとハイバネート]]<br />
[[ru:Power management (Русский)/Suspend and hibernate]]<br />
[[zh-hans:Power management (简体中文)/Suspend and hibernate]]<br />
{{Related articles start}}<br />
{{Related|Uswsusp}}<br />
{{Related|systemd}}<br />
{{Related|Power management}}<br />
{{Related|Wakeup triggers}}<br />
{{Related|swap}}<br />
{{Related articles end}}<br />
<br />
Currently there are three methods of suspending available:<br />
<br />
; Suspend to RAM (aka suspend, aka sleep): The '''S3''' sleeping state as defined by ACPI. Works by cutting off power to most parts of the machine aside from the RAM, which is required to restore the machine's state. Because of the large power savings, it is advisable for laptops to automatically enter this mode when the computer is running on batteries and the lid is closed (or the user is inactive for some time).<br />
; Suspend to disk (aka hibernate): The '''S4''' sleeping state as defined by ACPI. Saves the machine's state into [[swap space]] and completely powers off the machine. When the machine is powered on, the state is restored. Until then, there is [[Wikipedia:Standby power|zero]] power consumption.<br />
; Suspend to both: A hybrid of the aforementioned methods, sometimes called '''hybrid suspend'''. Saves the machine's state into swap space, but does not power off the machine. Instead, it invokes usual suspend to RAM. Therefore, if the battery is not depleted, the system can resume from RAM. If the battery is depleted, the system can be resumed from disk, which is much slower than resuming from RAM, but the machine's state has not been lost.<br />
<br />
There are multiple low level interfaces (backends) providing basic functionality, and some high level interfaces providing tweaks to handle problematic hardware drivers/kernel modules (e.g. video card re-initialization).<br />
<br />
{{Expansion|Document "suspend to idle" (called [https://docs.kernel.org/admin-guide/pm/sleep-states.html#suspend-to-idle S2Idle] by the kernel, [https://01.org/blogs/qwang59/2018/how-achieve-s0ix-states-linux S0ix] by Intel and [https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby Modern Standby] by Microsoft) and {{ic|/sys/power/mem_sleep}} values.}}<br />
<br />
== Low level interfaces ==<br />
<br />
Though these interfaces can be used directly, it is advisable to use the [[#High level interfaces|high level interfaces]] to suspend/hibernate. Using low level interfaces directly is significantly faster than using any high level interface, since running all the pre- and post-suspend hooks takes time, but hooks can properly set hardware clock, restore wireless etc.<br />
<br />
=== kernel (swsusp) ===<br />
<br />
The most straightforward approach is to directly inform the in-kernel software suspend code (swsusp) to enter a suspended state; the exact method and state depends on the level of hardware support. On modern kernels, writing appropriate strings to {{ic|/sys/power/state}} is the primary mechanism to trigger this suspend.<br />
<br />
See [https://docs.kernel.org/admin-guide/pm/sleep-states.html kernel documentation] for details.<br />
<br />
=== uswsusp ===<br />
<br />
The uswsusp ('Userspace Software Suspend') is a wrapper around the kernel's suspend-to-RAM mechanism, which performs some graphics adapter manipulations from userspace before suspending and after resuming.<br />
<br />
See main article [[Uswsusp]].<br />
<br />
== High level interfaces ==<br />
<br />
The end goal of these packages is to provide binaries/scripts that can be invoked to perform suspend/hibernate. Actually hooking them up to power buttons or menu clicks or laptop lid events is usually left to other tools. To automatically suspend/hibernate on certain power events, such as laptop lid close or battery depletion percentage, you may want to look into running [[Acpid]].<br />
<br />
=== systemd ===<br />
<br />
[[systemd]] provides native commands for suspend, hibernate and a hybrid suspend, see [[Power management#Power management with systemd]] for details. This is the default interface used in Arch Linux.<br />
<br />
See [[Power management#Sleep hooks]] for additional information on configuring suspend/hibernate hooks. Also see {{man|1|systemctl}}, {{man|8|systemd-sleep}}, and {{man|7|systemd.special}}.<br />
<br />
== Hibernation ==<br />
<br />
In order to use hibernation, you need to create a [[swap]] partition or file. You will need to point the kernel to your swap using the {{ic|1=resume=}} kernel parameter, which is configured via the boot loader. You will also need to [[#Configure the initramfs|configure the initramfs]]. This tells the kernel to attempt resuming from the specified swap in early userspace. These three steps are described in detail below.<br />
<br />
{{Note|<br />
* See [[Dm-crypt/Swap encryption#With suspend-to-disk support]] when using [[encryption]].<br />
* {{Pkg|linux-hardened}} does not support hibernation, see {{Bug|63648}}.<br />
}}<br />
<br />
=== About swap partition/file size ===<br />
<br />
Even if your swap partition is smaller than RAM, you still have a big chance of hibernating successfully. See "image_size" in the [https://docs.kernel.org/admin-guide/pm/sleep-states.html?highlight=image_size#basic-sysfs-interfaces-for-system-suspend-and-hibernation kernel documentation] for information on the {{ic|image_size}} {{man|5|sysfs}} pseudo-file.<br />
<br />
You may either decrease the value of {{ic|/sys/power/image_size}} to make the suspend image as small as possible (for small swap partitions), or increase it to possibly speed up the hibernation process. For systems with a large amount of RAM, smaller values may drastically increase the speed of resuming a hibernating system. [[systemd#systemd-tmpfiles - temporary files]] can be used to make this change persistent:<br />
<br />
{{hc|/etc/tmpfiles.d/hibernation_image_size.conf|<br />
# Path Mode UID GID Age Argument<br />
w /sys/power/image_size - - - - 0<br />
}}<br />
<br />
The suspend image cannot span multiple swap partitions and/or swap files. It must fully fit in one swap partition or one swap file.[https://docs.kernel.org/power/swsusp.html]<br />
<br />
=== Configure the initramfs ===<br />
<br />
* When an [[initramfs]] with the {{ic|base}} hook is used, which is the default, the {{ic|resume}} hook is required in {{ic|/etc/mkinitcpio.conf}}. Whether by label or by UUID, the swap partition is referred to with a udev device node, so the {{ic|resume}} hook must go ''after'' the {{ic|udev}} hook. This example was made starting from the default hook configuration:<br />
<br />
:{{bc|1=HOOKS=(base udev autodetect keyboard modconf block filesystems '''resume''' fsck)}}<br />
<br />
:Remember to [[regenerate the initramfs]] for these changes to take effect.<br />
<br />
:{{Note|[[LVM]] users should add the {{ic|resume}} hook after {{ic|lvm2}}.}}<br />
<br />
* When an initramfs with the {{ic|systemd}} hook is used, a resume mechanism is already provided, and no further hooks need to be added.<br />
<br />
=== Required kernel parameters ===<br />
<br />
The [[kernel parameter]] {{ic|1=resume=''swap_device''}} must be used. Any of the [[persistent block device naming]] methods can be used as {{ic|''swap_device''}}. For example:<br />
<br />
* {{ic|1=resume=UUID=4209c845-f495-4c43-8a03-5363dd433153}}<br />
* {{ic|1=resume="PARTLABEL=Swap partition"}}<br />
* {{ic|1=resume=/dev/archVolumeGroup/archLogicalVolume}} -- if swap is on a [[LVM]] logical volume (UUID and Label should also work)<br />
<br />
The kernel parameters will only take effect after rebooting. To be able to hibernate right away, obtain the volume's major and minor device numbers from [[lsblk]] and echo them in format {{ic|''major'':''minor''}} to {{ic|/sys/power/resume}}. If using a swap file, additionally echo the resume offset to {{ic|/sys/power/resume_offset}}.[https://docs.kernel.org/power/swsusp.html]<br />
<br />
For example, if the swap device is {{ic|8:3}}:<br />
<br />
# echo 8:3 > /sys/power/resume<br />
<br />
Or when hibernating to a swap file, if the swap file is on volume {{ic|8:2}} and has the offset {{ic|38912}}:<br />
<br />
# echo 8:2 > /sys/power/resume<br />
# echo 38912 > /sys/power/resume_offset<br />
<br />
==== Hibernation into swap file ====<br />
<br />
{{Warning|[[Btrfs#Swap file|Btrfs]] on Linux kernel before version 5.0 does not support swap files. Failure to heed this warning may result in file system corruption. While a swap file may be used on Btrfs when mounted through a loop device, this will result in severely degraded swap performance.}}<br />
<br />
Using a [[swap#Manually|swap file]] requires also setting the {{ic|1=resume=''swap_device''}} and additionally a {{ic|1=resume_offset=''swap_file_offset''}} [[kernel parameters]]. See [https://docs.kernel.org/power/swsusp-and-swap-files.html the kernel documentation].<br />
<br />
{{ic|''swap_device''}} is the volume where the swap file resides and it follows the same format as for the [[Persistent block device naming#Kernel parameters|root parameter]]. The value of {{ic|''swap_file_offset''}} can be obtained by running {{ic|filefrag -v ''swap_file''}}, the output is in a table format and the required value is located in the first row of the {{ic|physical_offset}} column. For example:<br />
<br />
{{hc|# filefrag -v /swapfile|<br />
Filesystem type is: ef53<br />
File size of /swapfile is 4294967296 (1048576 blocks of 4096 bytes)<br />
ext: logical_offset: physical_offset: length: expected: flags:<br />
0: 0.. 0: '''38912'''.. 38912: 1: <br />
1: 1.. 22527: 38913.. 61439: 22527: unwritten<br />
2: 22528.. 53247: 899072.. 929791: 30720: 61440: unwritten<br />
...<br />
}}<br />
<br />
In the example the value of {{ic|''swap_file_offset''}} is the first {{ic|38912}} with the two periods.<br />
<br />
{{Tip|<br />
* The following command may be used to identify {{ic|''swap_device''}}: {{ic|1=findmnt -no UUID -T /swapfile}}<br />
* The following command may be used to identify {{ic|''swap_file_offset''}}: {{ic|1=filefrag -v /swapfile {{!}} awk '$1=="0:" {print substr($4, 1, length($4)-2)}'}}<br />
* The value of {{ic|''swap_file_offset''}} can also be obtained by running {{ic|swap-offset ''swap_file''}}. The ''swap-offset'' binary is provided within the set of tools [[uswsusp]]. If using this method, then these two parameters have to be provided in {{ic|/etc/suspend.conf}} via the keys {{ic|resume device}} and {{ic|resume offset}}. No reboot is required in this case.<br />
}}<br />
<br />
{{Note|<br />
* For a stacked block device such as an encrypted container (LUKS), RAID or LVM, the {{ic|resume}} parameter must point to the unlocked/mapped device that contains the file system with the swap file.<br />
* If the swap file is in {{ic|/home/}}, ''systemd-logind'' will not be able to determine its size and thus will prevent hibernation with the following message: {{ic|Failed to hibernate system via logind: Not enough swap space for hibernation}}. See [https://github.com/systemd/systemd/issues/15354 systemd issue 15354] for two workarounds.<br />
}}<br />
<br />
{{Tip|You might want to decrease the [[swappiness]] for your swap file if the only purpose is to be able to hibernate and not expand RAM.}}<br />
<br />
==== Hibernation into swap file on Btrfs ====<br />
<br />
The resume_offset number can be computed using the [https://github.com/osandov/osandov-linux/blob/master/scripts/btrfs_map_physical.c tool btrfs_map_physical.c].<br />
Do not try to use the filefrag tool, on [[Btrfs]] the "physical" offset you get from filefrag is not the real physical offset on disk; there is a virtual disk address space in order to support multiple devices. [https://bugzilla.kernel.org/show_bug.cgi?id=202803]<br />
<br />
Download or copy the [https://github.com/osandov/osandov-linux/blob/master/scripts/btrfs_map_physical.c tool btrfs_map_physical.c] into a file named {{ic|btrfs_map_physical.c}}, then compile it,<br />
<br />
$ gcc -O2 -o btrfs_map_physical btrfs_map_physical.c<br />
<br />
and run it. An example output is shown below.<br />
<br />
{{hc|# ./btrfs_map_physical ''/path/to/swapfile''|<br />
FILE OFFSET EXTENT TYPE LOGICAL SIZE LOGICAL OFFSET PHYSICAL SIZE DEVID PHYSICAL OFFSET<br />
0 regular 4096 2927632384 268435456 1 '''4009762816'''<br />
4096 prealloc 268431360 2927636480 268431360 1 4009766912<br />
268435456 prealloc 268435456 3251634176 268435456 1 4333764608<br />
536870912 prealloc 268435456 3520069632 268435456 1 4602200064<br />
805306368 prealloc 268435456 3788505088 268435456 1 4870635520<br />
1073741824 prealloc 268435456 4056940544 268435456 1 5139070976<br />
1342177280 prealloc 268435456 4325376000 268435456 1 5407506432<br />
1610612736 prealloc 268435456 4593811456 268435456 1 5675941888<br />
}}<br />
<br />
Note the the first physical offset returned by this tool. In this example, we use {{ic|4009762816}}. Also note the pagesize that can be found with {{ic|getconf PAGESIZE}}.<br />
<br />
To compute the {{ic|resume_offset}} value, divide the physical offset by the pagesize. In this example, it is {{ic|1=4009762816 / 4096 = 978946}}.<br />
<br />
==== Hibernation into a thinly-provisioned LVM volume ====<br />
<br />
Hibernation into a thinly-provisioned [[LVM]] volume is possible, but you have to make sure that the volume is fully allocated. Otherwise resuming from it will fail, see {{Bug|50703}}.<br />
<br />
You can fully allocate the LVM volume by simply filling it with zeros. E.g.:<br />
<br />
# dd if=/dev/zero of=/dev/vg0/swap bs=1M status=progress<br />
<br />
To verify the volume is fully allocated, you can use:<br />
<br />
{{hc|# lvs|<br />
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert<br />
swap vg0 Vwi-aot--- 10.00g pool 100<br />
}}<br />
<br />
A fully allocated volume will show up as having 100% data usage.<br />
<br />
{{Warning|Do not to use [[TRIM]] on thinly-provisioned swap volumes that are used for hibernation, i.e. do not use {{ic|discard}} in {{ic|/etc/fstab}} and the {{ic|-d}}/{{ic|--discard}} option of ''swapon''. Otherwise the used space will be deallocated.}}<br />
<br />
== Intel Rapid Start Technology (IRST) ==<br />
<br />
Intel Rapid Start Technology is a firmware solution to hibernation that allows hibernating from sleep after a predefined internal or battery state. This should be faster and more reliable than regular hibernation as it is done by firmware instead of at the operating system level. Generally it must enabled in the firmware and the firmware also provides support for setting the time/battery event triggering hibernation, however some devices despite supporting IRST, only allow it to be configured via Intel's windows drivers. In such cases the intel-rst kernel module described below should be able to configure the events under linux.<br />
<br />
With Intel Rapid Start Technology (IRST) enabled, resuming from a deep sleep takes "[https://mjg59.dreamwidth.org/26022.html a few seconds longer than resuming from S3 but is far faster than resuming from hibernation]".<br />
<br />
Many Intel-based systems have firmware support for IRST but require a special partition on an SSD (rather than an HDD). OEM deployments of Windows may already have a preexisting IRST partition which can be retained during the Arch Linux installation process (rather than wiping and repartitioning the whole SSD). It should show up as an unformatted partition equal in size to the system's RAM.<br />
<br />
{{Warning|The Intel Rapid Start partition is not encrypted; "Intel recommends disabling Intel Rapid Start Technology if you are using software-based disk encryption".[https://www.intel.com/content/www/us/en/support/articles/000024080/technologies.html]}}<br />
<br />
However, if you intend to wipe and repartition the whole drive (or have already done so), then the IRST partition must be recreated if you also plan on using the technology. This can be done by creating an empty partition equal in size to the system's RAM and by setting its partition type to [[Wikipedia:GUID Partition Table#Partition type GUIDs|GUID]] {{ic|D3BFE2DE-3DAF-11DF-BA40-E3A556D89593}} for a [[GPT]] partition or [[Wikipedia:Partition type|ID]] {{ic|0x84}} for an [[MBR]] partition. You may also need to enable support for IRST in your system's firmware settings.<br />
<br />
{{Tip|The duration of time before IRST kicks in (after suspending) can be adjusted in the system's firmware settings.}}<br />
<br />
The duration of the IRST hibernation process (i.e., copying the "entire contents of RAM to a special partition") is dependant on the system's RAM size and SSD speed and can thus take 20–60 seconds. Some systems may indicate the process's completion with an LED indicator, e.g., when it stops blinking.<br />
<br />
Configuring IRST hibernation events in linux requires CONFIG_INTEL_RST=y or if set to module, the intel-rst module loaded. Once loaded via <code>modprobe intel_rst</code>, it should create files wakeup_events and wakeup_time under for eg. <code>/acpi/drivers/intel_rapid_start/*/wakeup_events</code> that can be used for further configuration. This module is tersely documented, see the source [https://github.com/torvalds/linux/blob/143a6252e1b8ab424b4b293512a97cca7295c182/drivers/platform/x86/intel/rst.c drivers/platform/x86/intel/rst.c] for more details.<br />
<br />
See also the [https://www.intel.com/content/www/us/en/support/articles/000024078/technologies.html general Q&A] and [https://www.intel.com/content/www/us/en/support/articles/000005836/boards-and-kits/desktop-boards.html user guides] for Intel Rapid Start Technology.<br />
<br />
== Troubleshooting ==<br />
<br />
=== ACPI_OS_NAME ===<br />
<br />
You might want to tweak your '''DSDT table''' to make it work. See [[DSDT]].<br />
<br />
=== Suspend/hibernate does not work, or does not work consistently ===<br />
<br />
There have been many reports about the screen going black without easily viewable errors or the ability to do anything when going into and coming back from suspend and/or hibernate. These problems have been seen on both laptops and desktops. This is not an official solution, but switching to an older kernel, especially the LTS-kernel, will probably fix this.<br />
<br />
Also problem may arise when using hardware watchdog timer (disabled by default, see {{ic|1=RuntimeWatchdogSec=}} in {{man|5|systemd-system.conf|OPTIONS}}). Bugged watchdog timer may reset the computer before the system finished creating the hibernation image.<br />
<br />
Sometimes the screen goes black due to device initialization from within the initramfs. Removing any modules you might have in [[Mkinitcpio#MODULES]] and rebuilding the initramfs, can possibly solve this issue, specially graphics drivers for [[Kernel mode setting#Early KMS start|early KMS]]. Initializing such devices before resuming can cause inconsistencies that prevents the system resuming from hibernation. This does not affect resuming from RAM. Also, check the blog article [https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues best practices to debug suspend issues].<br />
<br />
Moving from the [[radeon]] video driver to the newer [[AMDGPU]] driver could also help to make the hibernation and awakening process successful.<br />
<br />
For Intel graphics drivers, enabling early KMS may help to solve the blank screen issue. Refer to [[Kernel mode setting#Early KMS start]] for details.<br />
<br />
After upgrading to kernel 4.15.3, resume may fail with a static (non-blinking) cursor on a black screen. [[Blacklisting]] the module {{ic|nvidiafb}} might help. [https://bbs.archlinux.org/viewtopic.php?id=234646]<br />
<br />
Laptops with Intel CPU that load {{ic|intel_lpss_pci}} module for touchpad, may face kernel panic on resume (blinking caps lock) [https://bbs.archlinux.org/viewtopic.php?id=231881]. The module needs to be added to [[initramfs]] as:<br />
<br />
{{hc|head=/etc/mkinitcpio.conf|output=<br />
MODULES=(... intel_lpss_pci ...)<br />
}}<br />
<br />
Then [[regenerate the initramfs]].<br />
<br />
=== Wake-on-LAN ===<br />
<br />
If [[Wake-on-LAN]] is active, the network interface card will consume power even if the computer is hibernated.<br />
<br />
=== Instantaneous wakeups from suspend ===<br />
<br />
See [[Wakeup triggers#Instantaneous wakeups from suspend]].<br />
<br />
=== System does not power off when hibernating ===<br />
<br />
When you hibernate your system, the system should power off (after saving the state on the disk). Sometimes, you might see the power LED is still glowing. If that happens, it might be instructive to set the {{ic|HibernateMode}} to {{ic|shutdown}} in {{man|5|sleep.conf.d}}:<br />
<br />
{{hc|/etc/systemd/sleep.conf.d/hibernatemode.conf|2=<br />
[Sleep]<br />
HibernateMode=shutdown<br />
}}<br />
<br />
With the above configuration, if everything else is set up correctly, on invocation of a {{ic|systemctl hibernate}} the machine will shutdown saving state to disk as it does so.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Dell_XPS_17_(9720)&diff=739977Dell XPS 17 (9720)2022-08-04T01:34:57Z<p>Crescent: /* Power Management */ typo</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 17 (9720)]]<br />
{{Laptop style|Missing function keys section, hardware table needs some adjustments, some sections need to be reordered}}<br />
<br />
This page applies to the Dell XPS 17 (9720) and the Precision 5770, that are the same hardware.<br />
<br />
{| class="wikitable" style="float: right;"<br />
! Hardware !! PCI/USB ID !! Working?<br />
|-<br />
| GPU (Intel) || {{ic|8086:46a6}} || {{Yes}}<br />
|-<br />
| GPU (NVIDIA) || {{ic|10de:25a2}} || {{Yes}}<br />
|-<br />
| Wireless || {{ic|8086:51f0}} || {{Yes}}<br />
|-<br />
| Bluetooth || || {{Yes}}<br />
|-<br />
| Audio || {{ic|8086:51c8}} || {{Yes}}<br />
|-<br />
| Touchpad || || {{Y|Partial}}<br />
|-<br />
| Webcam || || {{Yes}}<br />
|-<br />
| Fingerprint sensor || || {{Y|Untested}}<br />
|-<br />
| SD Card Reader || {{ic|10ec:5260}} || {{Y|Untested}}<br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
Before installing it is necessary to modify some UEFI Settings. They can be accessed with {{ic|F2}} when booting.<br />
* Change the SATA Mode from the default "RAID" to "AHCI". This will allow Linux to detect the NVME SSD.<br />
* Disable [[Secure Boot]]. This may be re-enabled at a later point. See [[Unified Extensible Firmware Interface/Secure Boot#Using a signed boot loader|Using a signed bootloader]]<br />
<br />
=== Dual boot ===<br />
<br />
Please note that changing from "RAID" to "AHCI" can break the default Windows installation and require a complete reinstall. Usually running windows own startup repair utility however fixes this issue in most cases. Another alternative is to follow this [https://gist.github.com/chenxiaolong/4beec93c464639a19ad82eeccc828c63 guide].<br />
<br />
The reinstall can be done through the Dell recovery in the UEFI if needed.<br />
<br />
Once you used the startup repair utility or have reinstalled, Windows should boot normally in AHCI mode and without error. Then one can proceed with typical dual boot setup.<br />
<br />
== Thunderbolt ==<br />
<br />
The following thunderbolt devices have been tested:<br />
<br />
{| class="wikitable"<br />
! Device !! Working? !! Comments<br />
|-<br />
| [https://www.dell.com/en-us/shop/dell-thunderbolt-dock-wd22tb4/apd/210-bdqh/pc-accessories Dell WD22TB4 ] || {{Yes}} || {{-}}<br />
|-<br />
| Dell WD19DC || {{Yes}} || {{-}}<br />
|-<br />
|}<br />
<br />
== Audio ==<br />
<br />
See [[Advanced Linux Sound Architecture#ALSA firmware]]: {{Pkg|sof-firmware}} is required, and allows full functionality.<br />
<br />
=== Microphone ===<br />
<br />
The laptop has several mic channel and the appropriate channel has to be unmuted before the mic will work. Open ''alsamixer'', press {{ic|F6}}, then in sof-soundwire:<br />
<br />
* Select Playback ({{ic|F3}})<br />
* Under Playback, select rt714 ADC 22 Mux and set it to DMIC1<br />
* Select Capture ({{ic|F4}})<br />
* Make sure PGA5.0 5 Master is unmuted and and the two rt714 FU02 channels are unmuted.<br />
<br />
PGA5.0 only maps to either the left or right microphone channel. Other than the above mentioned channels in Playback and Capture, none of the other channels appears to able to influence recorded audio and there does not appear to be be a way to record dual channel audio or even have the recorded mono audio to be mapped to both channels.<br />
<br />
== Touchpad sluggish/sticky ==<br />
<br />
As in previous XPS 17 iterations, some users may find the touchpad is sluggish or sticky occasionally. Previous tracking bug https://gitlab.freedesktop.org/libinput/libinput/-/issues/618 but it is not root-caused yet.<br />
<br />
Touchpad is significantly more stable in X than Wayland. X will rarely exhibit an issue where only the top left quadrant of the touchpad is usable, for a short amount of time (and is fixable by a reboot). <br />
<br />
Using Wayland, if the lower 20% of the screen is exhibiting significant tearing during pointer travel in that area, add the kernel parameter {{ic|1=i915.enable_psr=0}} to resolve this.<br />
<br />
== Power Management ==<br />
<br />
See [[Hibernation]] for kernel parameters & initramfs configuration.<br />
<br />
S3 Sleep: Not supported. S0ix however works reasonably, loosing ~ 0.5% per hour. "RAID" needs to be changed to "AHCI" for S0ix to work.<br />
<br />
NVIDIA's open source driver does not support power management as of July 2022. Installing the proprietary driver is needed for [[NVIDIA Optimus]]. Once the proprietary driver is installed, no additional configuration is needed and it automatically turns the GPU off when not in use, reducing battery power usage by 7-12 watts per hour.<br />
<br />
== Firmware ==<br />
<br />
Dell [https://fwupd.org/lvfs/devices/com.dell.uefi7d606caf.firmware provides firmware updates] that can be installed automatically using [[fwupd]] (or one of its graphical frontends such as Gnome Software or KDE Discover). User reports not receiving UEFI and some other firmware updates this way when there were newer versions available for download.<br />
<br />
Alternatively, firmware updates can also be installed from the UEFI directly by connecting to WiFi, or even installed manually by downloading them from the support page and placing the ''.exe'' file on a fat32 drive or the EFI boot partition, then selecting the file in the "BIOS update" page after pressing {{ic|F12}} at boot time.<br />
<br />
It is possible to install custom [[Secure Boot]] root keys in the UEFI and use them for Secure Boot with Linux.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Dell_XPS_17_(9720)&diff=739976Dell XPS 17 (9720)2022-08-04T01:34:07Z<p>Crescent: Add note page applies to Precision 5770 and update % batt lost per hour in suspend to .5%</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 17 (9720)]]<br />
{{Laptop style|Missing function keys section, hardware table needs some adjustments, some sections need to be reordered}}<br />
<br />
This page applies to the Dell XPS 17 (9720) and the Precision 5770, that are the same hardware.<br />
<br />
{| class="wikitable" style="float: right;"<br />
! Hardware !! PCI/USB ID !! Working?<br />
|-<br />
| GPU (Intel) || {{ic|8086:46a6}} || {{Yes}}<br />
|-<br />
| GPU (NVIDIA) || {{ic|10de:25a2}} || {{Yes}}<br />
|-<br />
| Wireless || {{ic|8086:51f0}} || {{Yes}}<br />
|-<br />
| Bluetooth || || {{Yes}}<br />
|-<br />
| Audio || {{ic|8086:51c8}} || {{Yes}}<br />
|-<br />
| Touchpad || || {{Y|Partial}}<br />
|-<br />
| Webcam || || {{Yes}}<br />
|-<br />
| Fingerprint sensor || || {{Y|Untested}}<br />
|-<br />
| SD Card Reader || {{ic|10ec:5260}} || {{Y|Untested}}<br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
Before installing it is necessary to modify some UEFI Settings. They can be accessed with {{ic|F2}} when booting.<br />
* Change the SATA Mode from the default "RAID" to "AHCI". This will allow Linux to detect the NVME SSD.<br />
* Disable [[Secure Boot]]. This may be re-enabled at a later point. See [[Unified Extensible Firmware Interface/Secure Boot#Using a signed boot loader|Using a signed bootloader]]<br />
<br />
=== Dual boot ===<br />
<br />
Please note that changing from "RAID" to "AHCI" can break the default Windows installation and require a complete reinstall. Usually running windows own startup repair utility however fixes this issue in most cases. Another alternative is to follow this [https://gist.github.com/chenxiaolong/4beec93c464639a19ad82eeccc828c63 guide].<br />
<br />
The reinstall can be done through the Dell recovery in the UEFI if needed.<br />
<br />
Once you used the startup repair utility or have reinstalled, Windows should boot normally in AHCI mode and without error. Then one can proceed with typical dual boot setup.<br />
<br />
== Thunderbolt ==<br />
<br />
The following thunderbolt devices have been tested:<br />
<br />
{| class="wikitable"<br />
! Device !! Working? !! Comments<br />
|-<br />
| [https://www.dell.com/en-us/shop/dell-thunderbolt-dock-wd22tb4/apd/210-bdqh/pc-accessories Dell WD22TB4 ] || {{Yes}} || {{-}}<br />
|-<br />
| Dell WD19DC || {{Yes}} || {{-}}<br />
|-<br />
|}<br />
<br />
== Audio ==<br />
<br />
See [[Advanced Linux Sound Architecture#ALSA firmware]]: {{Pkg|sof-firmware}} is required, and allows full functionality.<br />
<br />
=== Microphone ===<br />
<br />
The laptop has several mic channel and the appropriate channel has to be unmuted before the mic will work. Open ''alsamixer'', press {{ic|F6}}, then in sof-soundwire:<br />
<br />
* Select Playback ({{ic|F3}})<br />
* Under Playback, select rt714 ADC 22 Mux and set it to DMIC1<br />
* Select Capture ({{ic|F4}})<br />
* Make sure PGA5.0 5 Master is unmuted and and the two rt714 FU02 channels are unmuted.<br />
<br />
PGA5.0 only maps to either the left or right microphone channel. Other than the above mentioned channels in Playback and Capture, none of the other channels appears to able to influence recorded audio and there does not appear to be be a way to record dual channel audio or even have the recorded mono audio to be mapped to both channels.<br />
<br />
== Touchpad sluggish/sticky ==<br />
<br />
As in previous XPS 17 iterations, some users may find the touchpad is sluggish or sticky occasionally. Previous tracking bug https://gitlab.freedesktop.org/libinput/libinput/-/issues/618 but it is not root-caused yet.<br />
<br />
Touchpad is significantly more stable in X than Wayland. X will rarely exhibit an issue where only the top left quadrant of the touchpad is usable, for a short amount of time (and is fixable by a reboot). <br />
<br />
Using Wayland, if the lower 20% of the screen is exhibiting significant tearing during pointer travel in that area, add the kernel parameter {{ic|1=i915.enable_psr=0}} to resolve this.<br />
<br />
== Power Management ==<br />
<br />
See [[Hibernation]] for kernel parameters & initramfs configuration.<br />
<br />
S3 Sleep: Not supported. S0ix however works reasonably, loosing ~ 0.5% per hour. "RAID" needs to be changed to "AHCI" for S0ix to work.<br />
<br />
NVIDIA's open source driver does not support power management as of July 2022. Installing the proprietary driver is needed for [[NVIDIA Optimus]]. Once the proprietary driver is installed, no additional configuration is needed and it automatically turns to GPU off when not in use, reducing battery power usage by 7-12 watts per hour.<br />
<br />
== Firmware ==<br />
<br />
Dell [https://fwupd.org/lvfs/devices/com.dell.uefi7d606caf.firmware provides firmware updates] that can be installed automatically using [[fwupd]] (or one of its graphical frontends such as Gnome Software or KDE Discover). User reports not receiving UEFI and some other firmware updates this way when there were newer versions available for download.<br />
<br />
Alternatively, firmware updates can also be installed from the UEFI directly by connecting to WiFi, or even installed manually by downloading them from the support page and placing the ''.exe'' file on a fat32 drive or the EFI boot partition, then selecting the file in the "BIOS update" page after pressing {{ic|F12}} at boot time.<br />
<br />
It is possible to install custom [[Secure Boot]] root keys in the UEFI and use them for Secure Boot with Linux.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Dell_XPS_17_(9720)&diff=739860Dell XPS 17 (9720)2022-08-02T18:11:22Z<p>Crescent: /* Microphone */ Fix formatting</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 17 (9720) / Precision 5770]]<br />
{{Laptop style|Missing function keys section, hardware table needs some adjustments, some sections need to be reordered}}<br />
{| class="wikitable" style="float: right;"<br />
! Hardware !! PCI/USB ID !! Working?<br />
|-<br />
| GPU (Intel) || {{ic|8086:46a6}} || {{Yes}}<br />
|-<br />
| GPU (NVIDIA) || {{ic|10de:25a2}} || {{Yes}}<br />
|-<br />
| Wireless || {{ic|8086:51f0}} || {{Yes}}<br />
|-<br />
| Bluetooth || || {{Yes}}<br />
|-<br />
| Audio || {{ic|8086:51c8}} || {{Yes}}<br />
|-<br />
| Touchpad || || {{Y|Partial}}<br />
|-<br />
| Webcam || || {{Yes}}<br />
|-<br />
| Fingerprint sensor || || {{Y|Untested}}<br />
|-<br />
| SD Card Reader || {{ic|10ec:5260}} || {{Y|Untested}}<br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
Before installing it is necessary to modify some UEFI Settings. They can be accessed with {{ic|F2}} when booting.<br />
* Change the SATA Mode from the default "RAID" to "AHCI". This will allow Linux to detect the NVME SSD.<br />
* Disable [[Secure Boot]]. This may be re-enabled at a later point. See [[Unified Extensible Firmware Interface/Secure Boot#Using a signed boot loader|Using a signed bootloader]]<br />
<br />
=== Dual boot ===<br />
<br />
Please note that changing from "RAID" to "AHCI" can break the default Windows installation and require a complete reinstall. Usually running windows own startup repair utility however fixes this issue in most cases. Another alternative is to follow this [https://gist.github.com/chenxiaolong/4beec93c464639a19ad82eeccc828c63 guide].<br />
<br />
The reinstall can be done through the Dell recovery in the UEFI if needed.<br />
<br />
Once you used the startup repair utility or have reinstalled, Windows should boot normally in AHCI mode and without error. Then one can proceed with typical dual boot setup.<br />
<br />
== Thunderbolt ==<br />
<br />
The following thunderbolt devices have been tested:<br />
<br />
{| class="wikitable"<br />
! Device !! Working? !! Comments<br />
|-<br />
| [https://www.dell.com/en-us/shop/dell-thunderbolt-dock-wd22tb4/apd/210-bdqh/pc-accessories Dell WD22TB4 ] || {{Yes}} || {{-}}<br />
|-<br />
| Dell WD19DC || {{Yes}} || {{-}}<br />
|-<br />
|}<br />
<br />
== Audio ==<br />
<br />
See [[Advanced Linux Sound Architecture#ALSA firmware]]: {{Pkg|sof-firmware}} is required, and allows full functionality.<br />
<br />
=== Microphone ===<br />
<br />
The laptop has several mic channel and the appropriate channel has to be unmuted before the mic will work. Open ''alsamixer'', press {{ic|F6}}, then in sof-soundwire:<br />
- Select Playback (F3)<br />
- Under Playback, select rt714 ADC 22 Mux and set it to DMIC1<br />
- Select Capture (F4)<br />
- Make sure PGA5.0 5 Master is unmuted and and the two rt714 FU02 channels are unmuted.<br />
PGA5.0 only maps to either the left or right microphone channel. Other than the above mentioned channels in Playback and Capture, none of the other channels appears to able to influence recorded audio and there does not appear to be be a way to record dual channel audio or even have the recorded mono audio to be mapped to both channels.<br />
<br />
== Touchpad sluggish/sticky==<br />
<br />
As in previous XPS 17 iterations, some users may find the touchpad is sluggish or sticky occasionally. Previous tracking bug https://gitlab.freedesktop.org/libinput/libinput/-/issues/618 but it is not root-caused yet.<br />
<br />
Touchpad is significantly more stable in X than Wayland. X will rarely exhibit an issue where only the top left quadrant of the touchpad is usable, for a short amount of time (and is fixable by a reboot). <br />
<br />
Using Wayland, if the lower 20% of the screen is exhibiting significant tearing during pointer travel in that area, add the kernel parameter {{ic|1=i915.enable_psr=0}} to resolve this.<br />
<br />
== Power Management ==<br />
<br />
See [[Hibernation]] for kernel parameters & initramfs configuration.<br />
<br />
S3 Sleep: Not supported. S0ix however works reasonably well, loosing < 1% per hour. "RAID" needs to be changed to "AHCI" for S0ix to work.<br />
<br />
NVIDIA's open source driver does not support power management as of July 2022. Installing the proprietary driver is needed for [[NVIDIA Optimus]]. Once the proprietary driver is installed, no additional configuration is needed and it automatically turns to GPU off when not in use, reducing battery power usage by 7-12 watts per hour.<br />
<br />
== Firmware ==<br />
<br />
Dell [https://fwupd.org/lvfs/devices/com.dell.uefi7d606caf.firmware provides firmware updates] that can be installed automatically using [[fwupd]] (or one of its graphical frontends such as Gnome Software or KDE Discover). User reports not receiving UEFI and some other firmware updates this way when there were newer versions available for download.<br />
<br />
Alternatively, firmware updates can also be installed from the UEFI directly by connecting to WiFi, or even installed manually by downloading them from the support page and placing the ''.exe'' file on a fat32 drive or the EFI boot partition, then selecting the file in the "BIOS update" page after pressing {{ic|F12}} at boot time.<br />
<br />
It is possible to install custom [[Secure Boot]] root keys in the UEFI and use them for Secure Boot with Linux.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Dell_XPS_17_(9720)&diff=739859Dell XPS 17 (9720)2022-08-02T18:10:46Z<p>Crescent: Update title to indicate same as Precision 5770 and update mic unmuting specifics</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 17 (9720) / Precision 5770]]<br />
{{Laptop style|Missing function keys section, hardware table needs some adjustments, some sections need to be reordered}}<br />
{| class="wikitable" style="float: right;"<br />
! Hardware !! PCI/USB ID !! Working?<br />
|-<br />
| GPU (Intel) || {{ic|8086:46a6}} || {{Yes}}<br />
|-<br />
| GPU (NVIDIA) || {{ic|10de:25a2}} || {{Yes}}<br />
|-<br />
| Wireless || {{ic|8086:51f0}} || {{Yes}}<br />
|-<br />
| Bluetooth || || {{Yes}}<br />
|-<br />
| Audio || {{ic|8086:51c8}} || {{Yes}}<br />
|-<br />
| Touchpad || || {{Y|Partial}}<br />
|-<br />
| Webcam || || {{Yes}}<br />
|-<br />
| Fingerprint sensor || || {{Y|Untested}}<br />
|-<br />
| SD Card Reader || {{ic|10ec:5260}} || {{Y|Untested}}<br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
Before installing it is necessary to modify some UEFI Settings. They can be accessed with {{ic|F2}} when booting.<br />
* Change the SATA Mode from the default "RAID" to "AHCI". This will allow Linux to detect the NVME SSD.<br />
* Disable [[Secure Boot]]. This may be re-enabled at a later point. See [[Unified Extensible Firmware Interface/Secure Boot#Using a signed boot loader|Using a signed bootloader]]<br />
<br />
=== Dual boot ===<br />
<br />
Please note that changing from "RAID" to "AHCI" can break the default Windows installation and require a complete reinstall. Usually running windows own startup repair utility however fixes this issue in most cases. Another alternative is to follow this [https://gist.github.com/chenxiaolong/4beec93c464639a19ad82eeccc828c63 guide].<br />
<br />
The reinstall can be done through the Dell recovery in the UEFI if needed.<br />
<br />
Once you used the startup repair utility or have reinstalled, Windows should boot normally in AHCI mode and without error. Then one can proceed with typical dual boot setup.<br />
<br />
== Thunderbolt ==<br />
<br />
The following thunderbolt devices have been tested:<br />
<br />
{| class="wikitable"<br />
! Device !! Working? !! Comments<br />
|-<br />
| [https://www.dell.com/en-us/shop/dell-thunderbolt-dock-wd22tb4/apd/210-bdqh/pc-accessories Dell WD22TB4 ] || {{Yes}} || {{-}}<br />
|-<br />
| Dell WD19DC || {{Yes}} || {{-}}<br />
|-<br />
|}<br />
<br />
== Audio ==<br />
<br />
See [[Advanced Linux Sound Architecture#ALSA firmware]]: {{Pkg|sof-firmware}} is required, and allows full functionality.<br />
<br />
=== Microphone ===<br />
<br />
The laptop has several mic channel and the appropriate channel has to be unmuted before the mic will work. Open ''alsamixer'', press {{ic|F6}}, then in sof-soundwire:<br />
- Select Playback (F3)<br />
- Under Playback, select rt714 ADC 22 Mux and set it to DMIC1<br />
- Select Capture (F4)<br />
- Make sure PGA5.0 5 Master is unmuted and and the two rt714 FU02 channels are unmuted.<br />
PGA5.0 only maps to either the left or right microphone channel. Other than the above mentioned channels in Playback and Capture, none of the other channels appears to able to influence recorded audio and there does not appear to be be a way to record dual channel audio or even have the recorded mono audio to be mapped to both channels.<br />
<br />
== Touchpad sluggish/sticky==<br />
<br />
As in previous XPS 17 iterations, some users may find the touchpad is sluggish or sticky occasionally. Previous tracking bug https://gitlab.freedesktop.org/libinput/libinput/-/issues/618 but it is not root-caused yet.<br />
<br />
Touchpad is significantly more stable in X than Wayland. X will rarely exhibit an issue where only the top left quadrant of the touchpad is usable, for a short amount of time (and is fixable by a reboot). <br />
<br />
Using Wayland, if the lower 20% of the screen is exhibiting significant tearing during pointer travel in that area, add the kernel parameter {{ic|1=i915.enable_psr=0}} to resolve this.<br />
<br />
== Power Management ==<br />
<br />
See [[Hibernation]] for kernel parameters & initramfs configuration.<br />
<br />
S3 Sleep: Not supported. S0ix however works reasonably well, loosing < 1% per hour. "RAID" needs to be changed to "AHCI" for S0ix to work.<br />
<br />
NVIDIA's open source driver does not support power management as of July 2022. Installing the proprietary driver is needed for [[NVIDIA Optimus]]. Once the proprietary driver is installed, no additional configuration is needed and it automatically turns to GPU off when not in use, reducing battery power usage by 7-12 watts per hour.<br />
<br />
== Firmware ==<br />
<br />
Dell [https://fwupd.org/lvfs/devices/com.dell.uefi7d606caf.firmware provides firmware updates] that can be installed automatically using [[fwupd]] (or one of its graphical frontends such as Gnome Software or KDE Discover). User reports not receiving UEFI and some other firmware updates this way when there were newer versions available for download.<br />
<br />
Alternatively, firmware updates can also be installed from the UEFI directly by connecting to WiFi, or even installed manually by downloading them from the support page and placing the ''.exe'' file on a fat32 drive or the EFI boot partition, then selecting the file in the "BIOS update" page after pressing {{ic|F12}} at boot time.<br />
<br />
It is possible to install custom [[Secure Boot]] root keys in the UEFI and use them for Secure Boot with Linux.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Dell_XPS_17_(9720)&diff=739489Dell XPS 17 (9720)2022-07-29T19:44:33Z<p>Crescent: /* Firmware */ Add note latest firmware updates are not sent on fwupd</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 17 (9720)]]<br />
{{Laptop style|Missing function keys section, hardware table needs some adjustments, some sections need to be reordered}}<br />
{| class="wikitable" style="float: right;"<br />
! Hardware !! PCI/USB ID !! Working?<br />
|-<br />
| GPU (Intel) || {{ic|8086:46a6}} || {{Yes}}<br />
|-<br />
| GPU (NVIDIA) || {{ic|10de:25a2}} || {{Yes}}<br />
|-<br />
| Wireless || {{ic|8086:51f0}} || {{Yes}}<br />
|-<br />
| Bluetooth || || {{Yes}}<br />
|-<br />
| Audio || {{ic|8086:51c8}} || {{Yes}}<br />
|-<br />
| Touchpad || || {{Y|Partial}}<br />
|-<br />
| Webcam || || {{Yes}}<br />
|-<br />
| Fingerprint sensor || || {{Y|Untested}}<br />
|-<br />
| SD Card Reader || {{ic|10ec:5260}} || {{Y|Untested}}<br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
Before installing it is necessary to modify some UEFI Settings. They can be accessed with {{ic|F2}} when booting.<br />
* Change the SATA Mode from the default "RAID" to "AHCI". This will allow Linux to detect the NVME SSD.<br />
* Disable [[Secure Boot]]. This may be re-enabled at a later point. See [[Unified Extensible Firmware Interface/Secure Boot#Using a signed boot loader|Using a signed bootloader]]<br />
<br />
=== Dual boot ===<br />
<br />
Please note that changing from "RAID" to "AHCI" can break the default Windows installation and require a complete reinstall. Usually running windows own startup repair utility however fixes this issue in most cases. Another alternative is to follow this [https://gist.github.com/chenxiaolong/4beec93c464639a19ad82eeccc828c63 guide].<br />
<br />
The reinstall can be done through the Dell recovery in the UEFI if needed.<br />
<br />
Once you used the startup repair utility or have reinstalled, Windows should boot normally in AHCI mode and without error. Then one can proceed with typical dual boot setup.<br />
<br />
== Thunderbolt ==<br />
<br />
The following thunderbolt devices have been tested:<br />
<br />
{| class="wikitable"<br />
! Device !! Working? !! Comments<br />
|-<br />
| [https://www.dell.com/en-us/shop/dell-thunderbolt-dock-wd22tb4/apd/210-bdqh/pc-accessories Dell WD22TB4 ] || {{Yes}} || {{-}}<br />
|-<br />
| Dell WD19DC || {{Yes}} || {{-}}<br />
|-<br />
|}<br />
<br />
== Audio ==<br />
<br />
See [[Advanced Linux Sound Architecture#ALSA firmware]]: {{Pkg|sof-firmware}} is required, and allows full functionality.<br />
<br />
=== Microphone ===<br />
<br />
The laptop has several mic channel and the appropriate channel has to be unmuted before the mic will work. Open ''alsamixer'', press {{ic|F6}} and in sof-soundwire changing rt714 and rt711 to DMIC/DMIC3/DMIC4 / MIC1/MIC2 works, though only some of those are probably needed.<br />
<br />
== Touchpad sluggish/sticky==<br />
<br />
As in previous XPS 17 iterations, some users may find the touchpad is sluggish or sticky occasionally. Previous tracking bug https://gitlab.freedesktop.org/libinput/libinput/-/issues/618 but it is not root-caused yet.<br />
<br />
Touchpad is significantly more stable in X than Wayland. X will rarely exhibit an issue where only the top left quadrant of the touchpad is usable, for a short amount of time (and is fixable by a reboot). <br />
<br />
Using Wayland, if the lower 20% of the screen is exhibiting significant tearing during pointer travel in that area, add the kernel parameter {{ic|1=i915.enable_psr=0}} to resolve this.<br />
<br />
== Power Management ==<br />
<br />
Hibernation: see [[Hibernation]] for kernel parameters & initramfs configuration.<br />
<br />
S3 Sleep: Not supported. S0ix however works reasonably well, loosing < 1% per hour. "RAID" needs to be changed to "AHCI" for S0ix to work.<br />
<br />
Nvidia's open source driver does not support power management as of Jul 30 2022. Installing the proprietary driver is needed for Nvidia optimus. Once the proprietary driver is installed, no additional configuration is needed and it automatically turns to gpu off when not in use, reducing battery power usage by 7-12 watts/hr.<br />
<br />
== Firmware ==<br />
<br />
Dell [https://fwupd.org/lvfs/devices/com.dell.uefi7d606caf.firmware provides firmware updates] that can be installed automatically using [[fwupd]] (or one of its graphical frontends such as Gnome Software or KDE Discover). Note, however I have not received BIOS and some other firmware updates this way when there were newer versions available for download.<br />
<br />
Alternatively, firmware updates can also be installed from the BIOS directly by connecting to Wifi, or even installed manually by downloading them from the support page and placing the exe file on a fat32 drive or the EFI boot partition, then selecting the file in the BIOS update page after pressing F12 at boot time.<br />
<br />
It is possible to install custom [[Secure Boot]] root keys in the BIOS and use them for Secure Boot with Linux.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Dell_XPS_17_(9720)&diff=739486Dell XPS 17 (9720)2022-07-29T19:09:35Z<p>Crescent: Copy over firmware section from 9700</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 17 (9720)]]<br />
{{Laptop style|Missing function keys section, hardware table needs some adjustments, some sections need to be reordered}}<br />
{| class="wikitable" style="float: right;"<br />
! Hardware !! PCI/USB ID !! Working?<br />
|-<br />
| GPU (Intel) || {{ic|8086:46a6}} || {{Yes}}<br />
|-<br />
| GPU (NVIDIA) || {{ic|10de:25a2}} || {{Yes}}<br />
|-<br />
| Wireless || {{ic|8086:51f0}} || {{Yes}}<br />
|-<br />
| Bluetooth || || {{Yes}}<br />
|-<br />
| Audio || {{ic|8086:51c8}} || {{Yes}}<br />
|-<br />
| Touchpad || || {{Y|Partial}}<br />
|-<br />
| Webcam || || {{Yes}}<br />
|-<br />
| Fingerprint sensor || || {{Y|Untested}}<br />
|-<br />
| SD Card Reader || {{ic|10ec:5260}} || {{Y|Untested}}<br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
Before installing it is necessary to modify some UEFI Settings. They can be accessed with {{ic|F2}} when booting.<br />
* Change the SATA Mode from the default "RAID" to "AHCI". This will allow Linux to detect the NVME SSD.<br />
* Disable [[Secure Boot]]. This may be re-enabled at a later point. See [[Unified Extensible Firmware Interface/Secure Boot#Using a signed boot loader|Using a signed bootloader]]<br />
<br />
=== Dual boot ===<br />
<br />
Please note that changing from "RAID" to "AHCI" can break the default Windows installation and require a complete reinstall. Usually running windows own startup repair utility however fixes this issue in most cases. Another alternative is to follow this [https://gist.github.com/chenxiaolong/4beec93c464639a19ad82eeccc828c63 guide].<br />
<br />
The reinstall can be done through the Dell recovery in the UEFI if needed.<br />
<br />
Once you used the startup repair utility or have reinstalled, Windows should boot normally in AHCI mode and without error. Then one can proceed with typical dual boot setup.<br />
<br />
== Thunderbolt ==<br />
<br />
The following thunderbolt devices have been tested:<br />
<br />
{| class="wikitable"<br />
! Device !! Working? !! Comments<br />
|-<br />
| [https://www.dell.com/en-us/shop/dell-thunderbolt-dock-wd22tb4/apd/210-bdqh/pc-accessories Dell WD22TB4 ] || {{Yes}} || {{-}}<br />
|-<br />
| Dell WD19DC || {{Yes}} || {{-}}<br />
|-<br />
|}<br />
<br />
== Audio ==<br />
<br />
See [[Advanced Linux Sound Architecture#ALSA firmware]]: {{Pkg|sof-firmware}} is required, and allows full functionality.<br />
<br />
=== Microphone ===<br />
<br />
The laptop has several mic channel and the appropriate channel has to be unmuted before the mic will work. Open ''alsamixer'', press {{ic|F6}} and in sof-soundwire changing rt714 and rt711 to DMIC/DMIC3/DMIC4 / MIC1/MIC2 works, though only some of those are probably needed.<br />
<br />
== Touchpad sluggish/sticky==<br />
<br />
As in previous XPS 17 iterations, some users may find the touchpad is sluggish or sticky occasionally. Previous tracking bug https://gitlab.freedesktop.org/libinput/libinput/-/issues/618 but it is not root-caused yet.<br />
<br />
Touchpad is significantly more stable in X than Wayland. X will rarely exhibit an issue where only the top left quadrant of the touchpad is usable, for a short amount of time (and is fixable by a reboot). <br />
<br />
Using Wayland, if the lower 20% of the screen is exhibiting significant tearing during pointer travel in that area, add the kernel parameter {{ic|1=i915.enable_psr=0}} to resolve this.<br />
<br />
== Power Management ==<br />
<br />
Hibernation: see [[Hibernation]] for kernel parameters & initramfs configuration.<br />
<br />
S3 Sleep: Not supported. S0ix however works reasonably well, loosing < 1% per hour. "RAID" needs to be changed to "AHCI" for S0ix to work.<br />
<br />
Nvidia's open source driver does not support power management as of Jul 30 2022. Installing the proprietary driver is needed for Nvidia optimus. Once the proprietary driver is installed, no additional configuration is needed and it automatically turns to gpu off when not in use, reducing battery power usage by 7-12 watts/hr.<br />
<br />
== Firmware ==<br />
<br />
Dell [https://fwupd.org/lvfs/devices/com.dell.uefi7d606caf.firmware provides firmware updates] that can be installed automatically using [[fwupd]] (or one of its graphical frontends such as Gnome Software or KDE Discover).<br />
<br />
Alternatively, firmware updates can also be installed manually by downloading them from the support page and placing the exe file on a fat32 drive or the EFI boot partition, then selecting the file in the BIOS update page after pressing F12 at boot time.<br />
<br />
It is possible to install custom [[Secure Boot]] root keys in the BIOS and use them for Secure Boot with Linux.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Dell_XPS_17_(9720)&diff=739485Dell XPS 17 (9720)2022-07-29T19:06:18Z<p>Crescent: /* Power Management */ Add note nvidia proprietary driver needed for power management</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 17 (9720)]]<br />
{{Laptop style|Missing function keys section, hardware table needs some adjustments, some sections need to be reordered}}<br />
{| class="wikitable" style="float: right;"<br />
! Hardware !! PCI/USB ID !! Working?<br />
|-<br />
| GPU (Intel) || {{ic|8086:46a6}} || {{Yes}}<br />
|-<br />
| GPU (NVIDIA) || {{ic|10de:25a2}} || {{Yes}}<br />
|-<br />
| Wireless || {{ic|8086:51f0}} || {{Yes}}<br />
|-<br />
| Bluetooth || || {{Yes}}<br />
|-<br />
| Audio || {{ic|8086:51c8}} || {{Yes}}<br />
|-<br />
| Touchpad || || {{Y|Partial}}<br />
|-<br />
| Webcam || || {{Yes}}<br />
|-<br />
| Fingerprint sensor || || {{Y|Untested}}<br />
|-<br />
| SD Card Reader || {{ic|10ec:5260}} || {{Y|Untested}}<br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
Before installing it is necessary to modify some UEFI Settings. They can be accessed with {{ic|F2}} when booting.<br />
* Change the SATA Mode from the default "RAID" to "AHCI". This will allow Linux to detect the NVME SSD.<br />
* Disable [[Secure Boot]]. This may be re-enabled at a later point. See [[Unified Extensible Firmware Interface/Secure Boot#Using a signed boot loader|Using a signed bootloader]]<br />
<br />
=== Dual boot ===<br />
<br />
Please note that changing from "RAID" to "AHCI" can break the default Windows installation and require a complete reinstall. Usually running windows own startup repair utility however fixes this issue in most cases. Another alternative is to follow this [https://gist.github.com/chenxiaolong/4beec93c464639a19ad82eeccc828c63 guide].<br />
<br />
The reinstall can be done through the Dell recovery in the UEFI if needed.<br />
<br />
Once you used the startup repair utility or have reinstalled, Windows should boot normally in AHCI mode and without error. Then one can proceed with typical dual boot setup.<br />
<br />
== Thunderbolt ==<br />
<br />
The following thunderbolt devices have been tested:<br />
<br />
{| class="wikitable"<br />
! Device !! Working? !! Comments<br />
|-<br />
| [https://www.dell.com/en-us/shop/dell-thunderbolt-dock-wd22tb4/apd/210-bdqh/pc-accessories Dell WD22TB4 ] || {{Yes}} || {{-}}<br />
|-<br />
| Dell WD19DC || {{Yes}} || {{-}}<br />
|-<br />
|}<br />
<br />
== Audio ==<br />
<br />
See [[Advanced Linux Sound Architecture#ALSA firmware]]: {{Pkg|sof-firmware}} is required, and allows full functionality.<br />
<br />
=== Microphone ===<br />
<br />
The laptop has several mic channel and the appropriate channel has to be unmuted before the mic will work. Open ''alsamixer'', press {{ic|F6}} and in sof-soundwire changing rt714 and rt711 to DMIC/DMIC3/DMIC4 / MIC1/MIC2 works, though only some of those are probably needed.<br />
<br />
== Touchpad sluggish/sticky==<br />
<br />
As in previous XPS 17 iterations, some users may find the touchpad is sluggish or sticky occasionally. Previous tracking bug https://gitlab.freedesktop.org/libinput/libinput/-/issues/618 but it is not root-caused yet.<br />
<br />
Touchpad is significantly more stable in X than Wayland. X will rarely exhibit an issue where only the top left quadrant of the touchpad is usable, for a short amount of time (and is fixable by a reboot). <br />
<br />
Using Wayland, if the lower 20% of the screen is exhibiting significant tearing during pointer travel in that area, add the kernel parameter {{ic|1=i915.enable_psr=0}} to resolve this.<br />
<br />
== Power Management ==<br />
<br />
Hibernation: see [[Hibernation]] for kernel parameters & initramfs configuration.<br />
<br />
S3 Sleep: Not supported. S0ix however works reasonably well, loosing < 1% per hour. "RAID" needs to be changed to "AHCI" for S0ix to work.<br />
<br />
Nvidia's open source driver does not support power management as of Jul 30 2022. Installing the proprietary driver is needed for Nvidia optimus. Once the proprietary driver is installed, no additional configuration is needed and it automatically turns to gpu off when not in use, reducing battery power usage by 7-12 watts/hr.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Dell_XPS_17_(9720)&diff=739481Dell XPS 17 (9720)2022-07-29T18:39:11Z<p>Crescent: Add note "RAID" needs to be changed to "AHCI" for S0ix to work.</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 17 (9720)]]<br />
{{Laptop style|Missing function keys section, hardware table needs some adjustments, some sections need to be reordered}}<br />
{| class="wikitable" style="float: right;"<br />
! Hardware !! PCI/USB ID !! Working?<br />
|-<br />
| GPU (Intel) || {{ic|8086:46a6}} || {{Yes}}<br />
|-<br />
| GPU (NVIDIA) || {{ic|10de:25a2}} || {{Yes}}<br />
|-<br />
| Wireless || {{ic|8086:51f0}} || {{Yes}}<br />
|-<br />
| Bluetooth || || {{Yes}}<br />
|-<br />
| Audio || {{ic|8086:51c8}} || {{Yes}}<br />
|-<br />
| Touchpad || || {{Y|Partial}}<br />
|-<br />
| Webcam || || {{Yes}}<br />
|-<br />
| Fingerprint sensor || || {{Y|Untested}}<br />
|-<br />
| SD Card Reader || {{ic|10ec:5260}} || {{Y|Untested}}<br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
Before installing it is necessary to modify some UEFI Settings. They can be accessed with {{ic|F2}} when booting.<br />
* Change the SATA Mode from the default "RAID" to "AHCI". This will allow Linux to detect the NVME SSD.<br />
* Disable [[Secure Boot]]. This may be re-enabled at a later point. See [[Unified Extensible Firmware Interface/Secure Boot#Using a signed boot loader|Using a signed bootloader]]<br />
<br />
== Dual boot ==<br />
<br />
Please note that changing from "RAID" to "AHCI" can break the default Windows installation and require a complete reinstall. Usually running windows own startup repair utility however fixes this issue in most cases. Another alternative is to follow this [https://gist.github.com/chenxiaolong/4beec93c464639a19ad82eeccc828c63 guide].<br />
<br />
The reinstall can be done through the Dell recovery in the UEFI if needed.<br />
<br />
Once you used the startup repair utility or have reinstalled, Windows should boot normally in AHCI mode and without error. Then one can proceed with typical dual boot setup.<br />
<br />
== Thunderbolt ==<br />
<br />
The following thunderbolt devices have been tested:<br />
<br />
{| class="wikitable"<br />
! Device !! Working? !! Comments<br />
|-<br />
| [https://www.dell.com/en-us/shop/dell-thunderbolt-dock-wd22tb4/apd/210-bdqh/pc-accessories Dell WD22TB4 ] || {{Yes}} || {{-}}<br />
|-<br />
| Dell WD19DC || {{Yes}} || {{-}}<br />
|-<br />
|}<br />
<br />
== Audio ==<br />
<br />
See [[Advanced Linux Sound Architecture#ALSA firmware]]: {{Pkg|sof-firmware}} is required, and allows full functionality.<br />
<br />
== Microphone ==<br />
<br />
The laptop has several mic channel and the appropriate channel has to be unmuted before the mic will work. Open alsamixer -> F6 -> sof-soundwire -> and there changing rt714 and rt711 to DMIC/DMIC3/DMIC4 / MIC1/MIC2 worked, though only some of those are probably needed.<br />
<br />
== Touchpad sluggish/sticky==<br />
<br />
As in previous XPS 17 iterations, some users may find the touchpad is sluggish or sticky occasionally. Previous tracking bug https://gitlab.freedesktop.org/libinput/libinput/-/issues/618 but it is not root-caused yet.<br />
<br />
Touchpad is significantly more stable in X than Wayland. X will rarely exhibit an issue where only the top left quadrant of the touchpad is usable, for a short amount of time (and is fixable by a reboot). <br />
<br />
Using Wayland, if the lower 20% of the screen is exhibiting significant tearing during pointer travel in that area, add the kernel parameter i915.enable_psr=0 to resolve this.<br />
<br />
== Power Management ==<br />
<br />
Hibernation: see [[Hibernation]] for kernel parameters & initramfs configuration.<br />
<br />
S3 Sleep: Not supported. S0ix however works reasonably well, loosing < 1% per hour. "RAID" needs to be changed to "AHCI" for S0ix to work.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Dell_XPS_17_(9720)&diff=739480Dell XPS 17 (9720)2022-07-29T18:35:36Z<p>Crescent: Webcam is working, tested</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 17 (9720)]]<br />
{{Laptop style|Missing function keys section, hardware table needs some adjustments, some sections need to be reordered}}<br />
{| class="wikitable" style="float: right;"<br />
! Hardware !! PCI/USB ID !! Working?<br />
|-<br />
| GPU (Intel) || {{ic|8086:46a6}} || {{Yes}}<br />
|-<br />
| GPU (NVIDIA) || {{ic|10de:25a2}} || {{Yes}}<br />
|-<br />
| Wireless || {{ic|8086:51f0}} || {{Yes}}<br />
|-<br />
| Bluetooth || || {{Yes}}<br />
|-<br />
| Audio || {{ic|8086:51c8}} || {{Yes}}<br />
|-<br />
| Touchpad || || {{Y|Partial}}<br />
|-<br />
| Webcam || || {{Yes}}<br />
|-<br />
| Fingerprint sensor || || {{Y|Untested}}<br />
|-<br />
| SD Card Reader || {{ic|10ec:5260}} || {{Y|Untested}}<br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
Before installing it is necessary to modify some UEFI Settings. They can be accessed with {{ic|F2}} when booting.<br />
* Change the SATA Mode from the default "RAID" to "AHCI". This will allow Linux to detect the NVME SSD.<br />
* Disable [[Secure Boot]]. This may be re-enabled at a later point. See [[Unified Extensible Firmware Interface/Secure Boot#Using a signed boot loader|Using a signed bootloader]]<br />
<br />
== Dual boot ==<br />
<br />
Please note that changing from "RAID" to "AHCI" can break the default Windows installation and require a complete reinstall. Usually running windows own startup repair utility however fixes this issue in most cases. Another alternative is to follow this [https://gist.github.com/chenxiaolong/4beec93c464639a19ad82eeccc828c63 guide].<br />
<br />
The reinstall can be done through the Dell recovery in the UEFI if needed.<br />
<br />
Once you used the startup repair utility or have reinstalled, Windows should boot normally in AHCI mode and without error. Then one can proceed with typical dual boot setup.<br />
<br />
== Thunderbolt ==<br />
<br />
The following thunderbolt devices have been tested:<br />
<br />
{| class="wikitable"<br />
! Device !! Working? !! Comments<br />
|-<br />
| [https://www.dell.com/en-us/shop/dell-thunderbolt-dock-wd22tb4/apd/210-bdqh/pc-accessories Dell WD22TB4 ] || {{Yes}} || {{-}}<br />
|-<br />
| Dell WD19DC || {{Yes}} || {{-}}<br />
|-<br />
|}<br />
<br />
== Audio ==<br />
<br />
See [[Advanced Linux Sound Architecture#ALSA firmware]]: {{Pkg|sof-firmware}} is required, and allows full functionality.<br />
<br />
== Microphone ==<br />
<br />
The laptop has several mic channel and the appropriate channel has to be unmuted before the mic will work. Open alsamixer -> F6 -> sof-soundwire -> and there changing rt714 and rt711 to DMIC/DMIC3/DMIC4 / MIC1/MIC2 worked, though only some of those are probably needed.<br />
<br />
== Touchpad sluggish/sticky==<br />
<br />
As in previous XPS 17 iterations, some users may find the touchpad is sluggish or sticky occasionally. Previous tracking bug https://gitlab.freedesktop.org/libinput/libinput/-/issues/618 but it is not root-caused yet.<br />
<br />
Touchpad is significantly more stable in X than Wayland. X will rarely exhibit an issue where only the top left quadrant of the touchpad is usable, for a short amount of time (and is fixable by a reboot). <br />
<br />
Using Wayland, if the lower 20% of the screen is exhibiting significant tearing during pointer travel in that area, add the kernel parameter i915.enable_psr=0 to resolve this.<br />
<br />
== Power Management ==<br />
<br />
Hibernation: see [[Hibernation]] for kernel parameters & initramfs configuration.<br />
<br />
S3 Sleep: untested</div>Crescenthttps://wiki.archlinux.org/index.php?title=Dell_XPS_17_(9720)&diff=739479Dell XPS 17 (9720)2022-07-29T18:34:14Z<p>Crescent: /* Audio */ Add note on mic not working by default until channel unmuted</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 17 (9720)]]<br />
{{Laptop style|Missing function keys section, hardware table needs some adjustments, some sections need to be reordered}}<br />
{| class="wikitable" style="float: right;"<br />
! Hardware !! PCI/USB ID !! Working?<br />
|-<br />
| GPU (Intel) || {{ic|8086:46a6}} || {{Yes}}<br />
|-<br />
| GPU (NVIDIA) || {{ic|10de:25a2}} || {{Yes}}<br />
|-<br />
| Wireless || {{ic|8086:51f0}} || {{Yes}}<br />
|-<br />
| Bluetooth || || {{Yes}}<br />
|-<br />
| Audio || {{ic|8086:51c8}} || {{Yes}}<br />
|-<br />
| Touchpad || || {{Y|Partial}}<br />
|-<br />
| Webcam || || {{Y|Untested}}<br />
|-<br />
| Fingerprint sensor || || {{Y|Untested}}<br />
|-<br />
| SD Card Reader || {{ic|10ec:5260}} || {{Y|Untested}}<br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
Before installing it is necessary to modify some UEFI Settings. They can be accessed with {{ic|F2}} when booting.<br />
* Change the SATA Mode from the default "RAID" to "AHCI". This will allow Linux to detect the NVME SSD.<br />
* Disable [[Secure Boot]]. This may be re-enabled at a later point. See [[Unified Extensible Firmware Interface/Secure Boot#Using a signed boot loader|Using a signed bootloader]]<br />
<br />
== Dual boot ==<br />
<br />
Please note that changing from "RAID" to "AHCI" can break the default Windows installation and require a complete reinstall. Usually running windows own startup repair utility however fixes this issue in most cases. Another alternative is to follow this [https://gist.github.com/chenxiaolong/4beec93c464639a19ad82eeccc828c63 guide].<br />
<br />
The reinstall can be done through the Dell recovery in the UEFI if needed.<br />
<br />
Once you used the startup repair utility or have reinstalled, Windows should boot normally in AHCI mode and without error. Then one can proceed with typical dual boot setup.<br />
<br />
== Thunderbolt ==<br />
<br />
The following thunderbolt devices have been tested:<br />
<br />
{| class="wikitable"<br />
! Device !! Working? !! Comments<br />
|-<br />
| [https://www.dell.com/en-us/shop/dell-thunderbolt-dock-wd22tb4/apd/210-bdqh/pc-accessories Dell WD22TB4 ] || {{Yes}} || {{-}}<br />
|-<br />
| Dell WD19DC || {{Yes}} || {{-}}<br />
|-<br />
|}<br />
<br />
== Audio ==<br />
<br />
See [[Advanced Linux Sound Architecture#ALSA firmware]]: {{Pkg|sof-firmware}} is required, and allows full functionality.<br />
<br />
== Microphone ==<br />
<br />
The laptop has several mic channel and the appropriate channel has to be unmuted before the mic will work. Open alsamixer -> F6 -> sof-soundwire -> and there changing rt714 and rt711 to DMIC/DMIC3/DMIC4 / MIC1/MIC2 worked, though only some of those are probably needed.<br />
<br />
== Touchpad sluggish/sticky==<br />
<br />
As in previous XPS 17 iterations, some users may find the touchpad is sluggish or sticky occasionally. Previous tracking bug https://gitlab.freedesktop.org/libinput/libinput/-/issues/618 but it is not root-caused yet.<br />
<br />
Touchpad is significantly more stable in X than Wayland. X will rarely exhibit an issue where only the top left quadrant of the touchpad is usable, for a short amount of time (and is fixable by a reboot). <br />
<br />
Using Wayland, if the lower 20% of the screen is exhibiting significant tearing during pointer travel in that area, add the kernel parameter i915.enable_psr=0 to resolve this.<br />
<br />
== Power Management ==<br />
<br />
Hibernation: see [[Hibernation]] for kernel parameters & initramfs configuration.<br />
<br />
S3 Sleep: untested</div>Crescenthttps://wiki.archlinux.org/index.php?title=Dell_XPS_17_(9720)&diff=739478Dell XPS 17 (9720)2022-07-29T18:28:54Z<p>Crescent: /* Touchpad sluggish/sticky */ i915.enable_psr=0 kernel param to rosolve touchpad issues in bottom 20% of screen</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 17 (9720)]]<br />
{{Laptop style|Missing function keys section, hardware table needs some adjustments, some sections need to be reordered}}<br />
{| class="wikitable" style="float: right;"<br />
! Hardware !! PCI/USB ID !! Working?<br />
|-<br />
| GPU (Intel) || {{ic|8086:46a6}} || {{Yes}}<br />
|-<br />
| GPU (NVIDIA) || {{ic|10de:25a2}} || {{Yes}}<br />
|-<br />
| Wireless || {{ic|8086:51f0}} || {{Yes}}<br />
|-<br />
| Bluetooth || || {{Yes}}<br />
|-<br />
| Audio || {{ic|8086:51c8}} || {{Yes}}<br />
|-<br />
| Touchpad || || {{Y|Partial}}<br />
|-<br />
| Webcam || || {{Y|Untested}}<br />
|-<br />
| Fingerprint sensor || || {{Y|Untested}}<br />
|-<br />
| SD Card Reader || {{ic|10ec:5260}} || {{Y|Untested}}<br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
Before installing it is necessary to modify some UEFI Settings. They can be accessed with {{ic|F2}} when booting.<br />
* Change the SATA Mode from the default "RAID" to "AHCI". This will allow Linux to detect the NVME SSD.<br />
* Disable [[Secure Boot]]. This may be re-enabled at a later point. See [[Unified Extensible Firmware Interface/Secure Boot#Using a signed boot loader|Using a signed bootloader]]<br />
<br />
== Dual boot ==<br />
<br />
Please note that changing from "RAID" to "AHCI" can break the default Windows installation and require a complete reinstall. Usually running windows own startup repair utility however fixes this issue in most cases. Another alternative is to follow this [https://gist.github.com/chenxiaolong/4beec93c464639a19ad82eeccc828c63 guide].<br />
<br />
The reinstall can be done through the Dell recovery in the UEFI if needed.<br />
<br />
Once you used the startup repair utility or have reinstalled, Windows should boot normally in AHCI mode and without error. Then one can proceed with typical dual boot setup.<br />
<br />
== Thunderbolt ==<br />
<br />
The following thunderbolt devices have been tested:<br />
<br />
{| class="wikitable"<br />
! Device !! Working? !! Comments<br />
|-<br />
| [https://www.dell.com/en-us/shop/dell-thunderbolt-dock-wd22tb4/apd/210-bdqh/pc-accessories Dell WD22TB4 ] || {{Yes}} || {{-}}<br />
|-<br />
| Dell WD19DC || {{Yes}} || {{-}}<br />
|-<br />
|}<br />
<br />
== Audio ==<br />
<br />
See [[Advanced Linux Sound Architecture#ALSA firmware]]: {{Pkg|sof-firmware}} is required, and allows full functionality.<br />
<br />
== Touchpad sluggish/sticky==<br />
<br />
As in previous XPS 17 iterations, some users may find the touchpad is sluggish or sticky occasionally. Previous tracking bug https://gitlab.freedesktop.org/libinput/libinput/-/issues/618 but it is not root-caused yet.<br />
<br />
Touchpad is significantly more stable in X than Wayland. X will rarely exhibit an issue where only the top left quadrant of the touchpad is usable, for a short amount of time (and is fixable by a reboot). <br />
<br />
Using Wayland, if the lower 20% of the screen is exhibiting significant tearing during pointer travel in that area, add the kernel parameter i915.enable_psr=0 to resolve this.<br />
<br />
== Power Management ==<br />
<br />
Hibernation: see [[Hibernation]] for kernel parameters & initramfs configuration.<br />
<br />
S3 Sleep: untested</div>Crescenthttps://wiki.archlinux.org/index.php?title=Acer_Chromebook_CX5500&diff=729933Acer Chromebook CX55002022-05-16T16:32:46Z<p>Crescent: Add notes on what doesn't work</p>
<hr />
<div>{{Laptop style|Stub}}<br />
<br />
Note: Sound did not work consistently (would stop after a few minutes). Microphone did not work (No audio picked up). External mic did not work. External USB-C monitor did not work. USB-C dock did not work.<br />
<br />
MrChromebox's firmware only provide the ability to flash SeaBIOS, not remove Google's firmware.<br />
<br />
Suspend and poweroff cause the system to hang with up to the latest kernel on git on 2022-05-14.<br />
<br />
To get suspend and resume to work, blacklist the atmel_mxt_ts and cros_ec_typec modules.<br />
<br />
To do this in grub, edit /etc/default/grub<br />
<br />
Add them to GRUB_CMDLINE_LINUX_DEFAULT.<br />
<br />
GRUB_CMDLINE_LINUX_DEFAULT=".. modprobe.blacklist=atmel_mxt_ts modprobe.blacklist=cros_ec_typec"<br />
<br />
And then regenerate grub.cfg<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg</div>Crescenthttps://wiki.archlinux.org/index.php?title=Chrome_OS_devices&diff=729520Chrome OS devices2022-05-14T08:49:58Z<p>Crescent: /* With kernel parameters */ Add note on needing to blacklist atmel_mxt_ts and cros_ec_typec for my chromebook with 11th gen intel and seabios</p>
<hr />
<div>[[Category:Chrome OS devices]]<br />
[[ja:Chrome OS デバイス]]<br />
{{Related articles start}}<br />
{{Related|Chrome OS devices/Crostini}}<br />
{{Related|Chrome OS devices/Chromebook}}<br />
{{Related|Chrome OS devices/Custom firmware}}<br />
{{Related|Installation guide}}<br />
{{Related|Laptop}}<br />
{{Related articles end}}<br />
{{Warning|This article relies on third-party scripts and modifications, and may irreparably damage your hardware or data. Proceed at your own risk.}}<br />
This article was created to provide information on how to get Arch installed on the series of Chrome OS devices built by Acer, HP, Samsung, Toshiba, and Google. Currently this page is being overhauled, and more model specific pages are being built with some of the information listed below. <br />
<br />
{{Note|This article describes how to install Arch Linux by activating developer mode. For instructions on how to install Arch Linux in a ChromeOS container without having to enable developer mode see [[Crostini]]}}<br />
<br />
== Introduction ==<br />
<br />
=== Legacy Boot Mode ===<br />
<br />
All recent Intel-based Chrome OS devices (starting with the 2013 Chromebook Pixel) feature a Legacy Boot Mode, designed to allow the user to boot Linux. Legacy Boot Mode has a dedicated firmware region, {{ic|RW_LEGACY}}, which is designed to be user-writeable (hence the 'RW' notation) and is completely separate from the ChromeOS portion of the firmware (ie, it is safe to update and cannot brick the device). It is enabled by the [https://www.coreboot.org/SeaBIOS SeaBIOS] payload of [https://www.coreboot.org/ coreboot], the open-source firmware used for all Chrome OS devices (with the exception of the first generation of Chromebooks and a few early ARM models). SeaBIOS behaves like a traditional BIOS that boots into the MBR of the disk, and from there into standard bootloaders like Syslinux and GRUB.<br />
<br />
Models with a Core-i based SoC (Haswell, Broadwell, Skylake, KabyLake) mostly ship with a functional Legacy Boot Mode payload; updating to a 3rd party build can provide bug fixes and additional features. Models with an Atom-based SoC (Baytrail, Braswell, Apollolake) have Legacy Boot Mode capability, but do not ship with a RW_LEGACY/SeaBIOS payload (that part of the firmware is blank). These models require a 3rd party RW_LEGACY firmware to be loaded for Legacy Boot Mode to be functional.<br />
<br />
==== Models without Legacy Boot Mode/SeaBIOS ====<br />
<br />
One of the following approaches can be taken in order to install Arch Linux on Chrome OS devices which did not ship with SeaBIOS as part of the installed firmware:<br />
<br />
* If the device supports Legacy Boot Mode, but does not ship with a functional {{ic|RW_LEGACY}} payload (or does not ship with one at all), one can flash a SeaBIOS payload to the {{ic|RW_LEGACY}} part of the firmware. This is 100% safe, as it writes to a user-writeable area of the firmware image which is completely separate from/does not affect ChromeOS. The easiest way to install/update the RW_LEGACY firmware on your ChromeOS device is via MrChromebox's [[Chrome_OS_devices/Custom_firmware#Flashing_with_MrChromebox.27s_Firmware_Utility_Script|Firmware Utility Script]], which supports the widest range of devices and offers the most up-to-date SeaBIOS builds; one can also update the {{ic|RW_LEGACY}} firmware manually with Chrome OS' {{ic|flashrom}} (requires downloading/compiling your own build), or use John Lewis' {{ic|flash_chromebook_rom.sh}} script (no longer supported).<br />
<br />
* Flash a full [[Custom firmware for Chrome OS devices|custom firmware]] which includes either a SeaBIOS or UEFI payload, and removes all the ChromeOS-specific parts.<br />
<br />
* Flash the {{ic|BOOT_STUB}} part of the firmware. This method replaces the stock ChromeOS payload (depthcharge) with SeaBIOS. This is theoretically a safer approach than flashing the full firmware but there might be some limitations (e.g. no support in suspend or VMX). This is the {{ic|Modify ROM to run SeaBIOS exclusively}} option in John Lewis' {{ic|flash_chromebook_rom.sh}} script and {{ic|Flash BOOT_STUB firmware}} option in MrChromebox's.<br />
<br />
* Take the ChrUbuntu approach which uses the Chrome OS kernel and modules.<br />
<br />
* Build and sign your own kernel, see [https://plus.google.com/+OlofJohansson/posts/34PYU79eUqP] [https://github.com/drsn0w/chromebook_kernel_tools/blob/master/install_arch_linux.md].<br />
<br />
The [[#Installation|Installation]] process described on this page tries to cover the method of installing Arch Linux on models without SeaBIOS by flashing a custom firmware.<br />
<br />
=== Firmware write protection intro ===<br />
<br />
All Chrome OS devices features firmware write protection, which restricts write access to certain regions of the flash chip. It is important to be aware of it as one might need to disable the hardware write protection as part of the installation process (to update GBB flags or flash a custom firmware).<br />
<br />
For more details see [[Custom firmware for Chrome OS devices#Firmware write protection|Firmware write protection]].<br />
<br />
=== Prerequisites ===<br />
<br />
* You should claim your free 100GB-1TB of Google Drive space before you install Arch. This needs to happen from ChromeOS(version > 23), not linux. This will sync/backup ChromeOS, as designed<br />
* Visit the ArchWiki page for your [[#Chrome OS devices|Chrome OS device]].<br />
* If there is no ArchWiki page for your device then before proceeding, gather information about the device and if you succeed in installing Arch Linux, then consider adding a new ArchWiki page for your model (you can use the [[Acer C720]] as an example for device shipped with SeaBios or the [[Acer_C710_Chromebook|Acer C710]] as device that did not ship with it).<br />
* Read this guide completely and make sure you understand all the steps before making any changes.<br />
<br />
== Chrome OS devices ==<br />
<br />
See [[Chrome_OS_devices/Chromebook|Chromebook models]] for hardware comparison with details about SeaBIOS availability and storage expansion.<br />
<br />
=== General hardware recommendations and remarks ===<br />
<br />
* MyDigitalSSD M.2 NGFF SSD drives are probably the most popular choice when upgrading the internal SSD of a Chrome OS device. There are multiple accounts of failing MyDigitalSSD SSD drives at the Acer C720 topic on the Arch forums [https://bbs.archlinux.org/viewtopic.php?pid=1461993#p1461993] [https://bbs.archlinux.org/viewtopic.php?pid=1474680#p1474680] [https://bbs.archlinux.org/viewtopic.php?pid=1460460#p1460460] and much more on the web. If the SSD was upgraded to a MyDigitalSSD model then it is highly recommended to backup the system and data frequently. It might be advisable to upgrade the SSD with a different brand. Notice that this might be due to a SSD firmware issue so updating the SSD firmware is highly recommended.<br />
* Transcend MTS400 M.2 NGFF SSD drives are failing (at least with stock Coreboot firmware) when ALPM is enabled, ATM there is no SSD firmware update that fixing this bug, so it is highly advisable to disabled ALPM if a power management daemon has been installed (which enabled it), see [[Solid_State_Drives#Resolving_SATA_power_management_related_errors|Resolving SATA power management related errors]] and [https://superuser.com/questions/887916/transcend-mts400-ssd-crashes-my-acer-c720-chromebook-how-to-disable-sata-power how to disable ALPM in Chrome OS].<br />
<br />
== Installation ==<br />
<br />
{{Warning|Installation on ChromeOS devices that do not ship with SeaBIOS requires flashing a custom firmware, certain types of which have the potential to brick your device. Proceed at your own risk.}}<br />
<br />
{{Note|While the following information should fit all the ChromeOS devices with coreboot firmware (shipped with SeaBIOS payload or without), it is possible that with some models you may need to make further adjustments.}}<br />
<br />
The general installation procedure:<br />
* Enable developer mode.<br />
* ChromeOS device with functional Legacy Boot Mode/SeaBIOS:<br />
** Enable Legacy Boot Mode.<br />
** Set SeaBIOS as default (optional but highly recommended, requires disabling the write protection).<br />
* ChromeOS device without functional Legacy Boot Mode:<br />
** Flash one of the following types of custom firmware<br />
*** Flash RW_LEGACY firmware (zero risk)<br />
*** Flash BOOT_STUB firmware (very low risk).<br />
*** Flash Full custom firmware (low risk).<br />
* Prepare the installation media.<br />
* Boot Arch Linux installation media and install Arch.<br />
<br />
=== Enabling developer mode ===<br />
<br />
[https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/acer-c720-chromebook#TOC-Developer-Mode Developer Mode] is necessary in order to access the superuser shell inside ChromeOS, which is required for making changes to the system like allow booting through SeaBIOS.<br />
<br />
{{Warning|Enabling Developer Mode will wipe all of your data.}}<br />
<br />
To enable developer mode: <br />
<br />
* Press and hold the {{ic|Esc + F3 (Refresh)}} keys, then press the {{ic|Power}} button. This enters Recovery Mode.<br />
** Chromeboxes have a dedicated Recovery button, which should be pressed/held while powering on<br />
* Press {{ic|Ctrl + D}} (no prompt). It will ask you to confirm, then the system will revert its state and enable Developer Mode.<br />
{{Note|Press {{ic|Ctrl + D}} (or wait 30 seconds for the beep and boot) at the white boot splash screen to enter ChromeOS.}}<br />
<br />
=== Accessing the superuser shell ===<br />
<br />
After you have enabled the Developer Mode you will need to access the superuser shell. How you do this depends on whether you have configured ChromeOS or not.<br />
<br />
==== Accessing the superuser shell without logging into ChromeOS ====<br />
<br />
If you have not configured ChromeOS, just press {{ic|Ctrl + Alt + F2}} (F2 is the "forward" arrow on the top row, →), you will see a login prompt.<br />
<br />
* Use {{ic|chronos}} as the username, it should not prompt you for a password.<br />
* Become superuser with [[sudo]], use the command {{ic|sudo su -}}.<br />
<br />
==== Accessing the superuser shell when logged into ChromeOS ====<br />
<br />
If you have configured ChromeOS already:<br />
<br />
* Open a crosh window with {{ic|Ctrl + Alt + T}}.<br />
* Open a bash shell with the {{ic|shell}} command.<br />
* Become superuser with [[sudo]], use the command {{ic|sudo su -}} to accomplish that.<br />
<br />
=== Enabling Legacy Boot Mode ===<br />
<br />
If your ChromeOS device did not ship with Legacy Boot Mode support via SeaBIOS, or you prefer to install a custom firmware, then continue to [[#Flashing a custom firmware|Flashing a custom firmware]].<br />
<br />
This will enable the pre-installed version of SeaBIOS through the Developer Mode screen in coreboot.<br />
<br />
* Inside your superuser shell enter:<br />
# crossystem dev_boot_legacy=1<br />
* Reboot the machine.<br />
<br />
You can now start SeaBIOS by pressing {{ic|Ctrl + L}} at the white boot splash screen.<br />
<br />
{{Note|If you intend to stay using pre-installed SeaBIOS route and think you will not appreciate having to press {{ic|Ctrl + L}} every time you boot to reach SeaBIOS, then you can set coreboot to boot to SeaBIOS by default. This requires disabling the hardware firmware write protection.}}<br />
<br />
You should now have SeaBIOS enabled on your ChromeOS device, if you choose to not set it as default then you can continue to [[#Installing Arch Linux|Installing Arch Linux]].<br />
<br />
==== Boot to SeaBIOS by default ====<br />
<br />
To boot SeaBIOS by default, you will need to run the [https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/master/scripts/image_signing/set_gbb_flags.sh {{ic|set_gbb_flags.sh}}] script, which is part of ChromeOS. The script uses flashrom and gbb_utility to read the RO_GBB firmware region, modify the flags, and write it back to flash. The GBB flags can also be set using MrChromebox's [https://mrchromebox.tech/#fwscript Firmware Utility Script] under either ChromeOS or Arch (the latter requiring booting with specific kernel parameters to relax memory access restrictions).<br />
<br />
{{Warning|If you do not set the GBB flags, then a fully discharged or disconnected battery will reset {{ic|dev_boot_legacy}} crossystem flag to its default value, removing the ability to boot in Legacy Boot Mode. While this used to require you to recover Chrome OS and wipe your Arch Linux installation on the internal storage, the GalliumOS developers have created a set of "fixflags" recovery images, which rather than wiping internal storage, will instead simply re-set the {{ic|dev_boot_legacy}} crossystem flag. See [https://galliumos.org/fixflags galliumos.org/fixflags]}}<br />
<br />
* Disable the hardware write protection.<br />
<br />
To find the location of the hardware write-protect screw/switch/jumper and how to disable it visit the ArchWiki page for your [[#Chrome OS devices|ChromeOS device]]. If there is no information about your device on the ArchWiki then turn to [https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices Developer Information for ChromeOS Devices] and [https://web.archive.org/web/20190203184547/https://www.coreboot.org/Chromebooks coreboot's Chromebooks page].<br />
<br />
More information about the firmware protection available in [[Chrome OS devices/Custom firmware#Firmware write protection]].<br />
<br />
* Switch to the [[#Accessing the superuser shell|superuser shell]].<br />
<br />
* Disable the software write protection.<br />
# flashrom --wp-disable<br />
<br />
* Check that write protection is disabled.<br />
# flashrom --wp-status<br />
<br />
* Run {{ic|set_gbb_flags.sh}} with no parameters.<br />
# /usr/share/vboot/bin/set_gbb_flags.sh<br />
<br />
* This will list all of the available flags. The ones of interest to us are:<br />
GBB_FLAG_DEV_SCREEN_SHORT_DELAY 0x00000001<br />
GBB_FLAG_FORCE_DEV_SWITCH_ON 0x00000008<br />
GBB_FLAG_FORCE_DEV_BOOT_LEGACY 0x00000080<br />
GBB_FLAG_DEFAULT_DEV_BOOT_LEGACY 0x00000400<br />
<br />
* So, to set SeaBIOS as default, with a 1s timeout, prevent accidentally exiting Developer Mode via spacebar, and ensure Legacy Boot Mode remains enabled in the event of battery drain/disconnect, we set the flags as such:<br />
# /usr/share/vboot/bin/set_gbb_flags.sh 0x489<br />
<br />
* Enable back the software write protection.<br />
# flashrom --wp-enable<br />
<br />
{{Note|All of these steps are automated by MrChromebox's Firmware Utility Script, so if using that to install/update your RW_LEGACY firmware, easiest to just set the flags via the script as well.}}<br />
<br />
Your ChromeOS device now will boot to SeaBIOS by default, you can continue to [[#Installing Arch Linux|Installing Arch Linux]], if your device is booting correctly then you can optionally re-enable the hardware write protection.<br />
<br />
=== Flashing a custom firmware ===<br />
<br />
{{Note|The following steps explain how to flash a custom firmware from ChromeOS, for information on how to flash a custom firmware from Arch Linux visit the [[Chrome OS devices/Custom firmware]] page}}<br />
<br />
* Disable the hardware write protection.<br />
<br />
To find the location of the hardware write-protect screw/switch/jumper and how to disable it visit the ArchWiki page for your [[#Chrome OS devices|ChromeOS device]]. If there is no information about your device on the ArchWiki then turn to [https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices Developer Information for ChromeOS Devices] and [https://web.archive.org/web/20190203184547/https://www.coreboot.org/Chromebooks coreboot's Chromebooks page].<br />
<br />
More information about the firmware protection available in [[Chrome OS devices/Custom firmware#Firmware write protection]].<br />
<br />
* Enter the command to run either MrChromebox's or John Lewis's firmware script.<br />
<br />
{{Note|The reason for not posting here is to force you to visit the site and read the instructions before proceeding.}}<br />
<br />
* After the exiting the script, be sure to copy the backed up firmware to an external storage before rebooting the system (if the script does not provide that option for you).<br />
<br />
You should now have a custom firmware installed on your device, cross your fingers and reboot.<br />
<br />
After flashing the firmware you can continue to [[#Installing Arch Linux|Installing Arch Linux]].<br />
<br />
=== Installing Arch Linux ===<br />
<br />
==== Preparing the installation media ====<br />
<br />
Create an [[USB flash installation media|Arch Linux Installer USB drive]].<br />
<br />
{{Note|If the USB loads but fails to boot into Arch, it may be due a bug in the syslinux the current (2017.03.01) installer uses. The 2016.11.01 version from the [[Arch Linux Archive]] will work until the issue is resolved.}}<br />
<br />
==== Booting the installation media ====<br />
<br />
* Plug the USB drive to the ChromeOS device and start SeaBIOS with {{ic|Ctrl + L}} at the white boot splash screen (if SeaBIOS is not set as default).<br />
* Press {{ic|Esc}} to get a boot menu and select the number corresponding to your USB drive.<br />
<br />
The Arch Linux installer boot menu should appear and the [[Installation guide|installation]] process can proceed as normal.<br />
<br />
{{Note|For now choose [[GRUB]] as your bootloader: you can choose MBR or GPT: [[Partitioning]]. If you choose GPT then do not forget to add a [[GRUB#GUID_Partition_Table_.28GPT.29_specific_instructions|BIOS Boot Partition]]. Also see [[#Syslinux|Known Issues]].}}<br />
<br />
After finishing installing Arch Linux continue by following the [[#Post installation configuration|Post Installation Configuration]].<br />
<br />
== Post installation configuration ==<br />
<br />
=== Patched kernels ===<br />
<br />
{{Note|You can most likely ignore this section unless your device requires patched kernel support.}}<br />
<br />
It is recommended to use the official {{Pkg|linux}} package for most Chrome OS devices with the exception being newer devices which might need patched kernel support.<br />
<br />
If your devices requires a patched kernel, it is advised to review the list of patches and decide if the patch list is getting decidedly small enough that you no longer require a patched kernel and instead you can use the official {{Pkg|linux}} package instead. <br />
<br />
See [[kernels]] for more information.<br />
<br />
=== Video driver ===<br />
<br />
See [[Intel graphics]].<br />
<br />
=== Touchpad and touchscreen ===<br />
<br />
See [[Touchpad Synaptics]], [[libinput]], and [[Touchscreen]].<br />
<br />
==== Touchpad and touchscreen kernel modules ====<br />
<br />
Since kernel 3.17 all the related patches merged into the upstream sources, meaning the {{Pkg|linux}} package in core supports these devices.<br />
<br />
===== What to do if your touchpad or touchscreen is not supported? =====<br />
<br />
* Do not worry as the developers should be able to add it by request as the Chromium OS sources includes the related changes.<br />
* You can also try to find the related commits by yourself and create a proper patch, some hints:<br />
** Dig into your Chrome OS system, look at the obvious suspects like boot log, {{ic|/proc/bus/input/devices}} and {{ic|/sys/devices}}.<br />
** The Linux kernel sources for Chromium OS are at [https://chromium.googlesource.com/chromiumos/third_party/kernel].<br />
** Each kernel source for the latest Chromium OS release has its own branch, name convention: {{ic|release-R*-*-chromeos-KERNELVER}}, where {{ic|R*-*}} is the Chromium OS release and {{ic|KERNELVER}} is the kernel version.<br />
** Review the git log of {{ic|drivers/platform}}, {{ic|drivers/i2c/busses}} and {{ic|drivers/input/touchscreen}}.<br />
<br />
==== Touchpad configuration ====<br />
<br />
There are few options how to set the touchpad:<br />
<br />
* Visit the ArchWiki page for your Chromebook model (see [[Chrome_OS_devices/Chromebook|Chromebook models]]) for touchpad xorg.conf.d file.<br />
* Use a [[Touchpad_Synaptics#Configuration_on_the_fly|touchpad configuration tool]].<br />
<br />
==== Chromium OS input drivers ====<br />
<br />
{{Out of date|{{ic|xf86-input-cmt}} development is not active and it is probably not needed anymore in any case since [[libinput]]'s compatibility with Chrome OS devices's touchpads is fairly good.}}<br />
<br />
{{AUR|xf86-input-cmt}} offers a port of the Chromium OS input driver: [https://github.com/hugegreenbug/xf86-input-cmt xf86-input-cmt] as an alternative for the [[Synaptics|Synaptics input driver]]. It provides tweaked configuration files for most devices, and provides functionality that the [[Synaptics|Synaptics input driver]] does not such as palm rejection. Additionally, it enables functionality not enabled by default in the Chromium OS input driver such as tap-to-drag.<br />
<br />
Please note, the input driver does not work under [https://github.com/hugegreenbug/xf86-input-cmt/issues/5 some circumstances] where you have insufficient permissions to access {{ic|/dev/input/event}}<br />
This will affect you if you use [[startx]] to load a DE/WM session.<br />
If this is the case or if the driver does not load for any other cases, you should run:<br />
# usermod -a -G input $USER<br />
Where $USER is the current user wanting to use the input driver.<br />
<br />
It should also be noted that some users have reported the driver does not work in [[GDM]] but works normally after log in.<br />
If you are affected by this, you should run:<br />
# usermod -a -G input gdm<br />
<br />
After reboot, you should be able to use the touchpad normally.<br />
<br />
=== Fixing suspend ===<br />
<br />
{{Note|Lid suspend might not work directly after boot, you might need to wait a little.}}<br />
<br />
The following are instructions to fix the suspend functionality.<br />
Users of a pre-installed SeaBIOS or John Lewis' pre-built SeaBIOS you will need this fix.<br />
This procedure is not needed with Matt DeVillier's custom firmware since problematic ACPI wake devices (such as {{ic|TPAD}}) are firmware-disabled.<br />
<br />
There have been a few alternatives discussed and those may work better for some. [https://bbs.archlinux.org/viewtopic.php?pid=1364376#p1364376] [https://bbs.archlinux.org/viewtopic.php?pid=1364521#p1364521]<br />
<br />
To fix suspend, the general idea is to disable the EHCI_PCI module, which interferes with the suspend cycle. There are multiple ways to achieve this.<br />
<br />
==== With kernel parameters ====<br />
<br />
Add the following to your GRUB configuration:-<br />
<br />
{{hc|head=/etc/default/grub|<br />
output=GRUB_CMDLINE_LINUX_DEFAULT="modprobe.blacklist=ehci_pci"}}<br />
<br />
Then [[GRUB#Generate_the_main_configuration_file|rebuild your grub config]]. After rebuilding your GRUB config, reboot your computer.<br />
<br />
Note (2022-05-14): I had to blacklist atmel_mxt_ts and cros_ec_typec instead of the above module to get suspend & resume my 11th gen Acer Chromebook CX5500 running arch linux via SeaBIOS to work.<br />
<br />
==== With systemd ====<br />
<br />
Sometimes the synaptics touchpad, and various other parts of the laptop are used as wakeup devices causing certain movements of the laptop during suspend to end suspend. In order to disable all wakeup devices except for the laptop lid sensor, create the following {{ic|suspend-device-fix.sh}} file. <br />
<br />
{{hc|head=/usr/local/sbin/suspend-device-fix.sh|<br />
output=<nowiki>#!/bin/bash<br />
<br />
awk '{if ($1 != "LID0" && $3 == "*enabled") print $1}' < /proc/acpi/wakeup | while read NAME<br />
do echo "$NAME" > /proc/acpi/wakeup<br />
done<br />
<br />
exit 0<br />
</nowiki>}}<br />
<br />
Now make the file [[executable]]<br />
<br />
Create a systemd service to execute the script on every boot. <br />
{{hc|head=/etc/systemd/system/suspend-fix.service|<br />
output=[Unit]<br />
Description=Suspend Fix<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=/usr/local/sbin/suspend-device-fix.sh<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
First [[start]] {{ic|suspend-fix.service}}. If it properly starts, then [[enable]] it to be started on bootup.<br />
<br />
Add the following line at the end of {{ic|/etc/rc.d/rc.local}} (if it does not exist, just create it) to prevent bad handling of EHCI USB:<br />
<br />
{{hc|head=/etc/rc.d/rc.local|<br />
output=<nowiki><br />
echo 1 > /sys/devices/pci0000\:00/0000\:00\:1d.0/remove<br />
</nowiki>}}<br />
<br />
Then, create the following {{ic|cros-sound-suspend.sh}} file. Only the Ath9k binding/unbinding lines are listed below; see the alternatives linked above for additional sound suspend handling if you experience issues.<br />
<br />
{{hc|head=/usr/lib/systemd/system-sleep/cros-sound-suspend.sh|<br />
output=<nowiki>#!/bin/bash<br />
<br />
case $1/$2 in<br />
pre/*)<br />
# Unbind ath9k for preventing error and full sleep mode (wakeup by LID after hibernating) <br />
echo -n "0000:01:00.0" | tee /sys/bus/pci/drivers/ath9k/unbind<br />
# Unbind snd_hda_intel for sound<br />
echo -n "0000:00:1b.0" | tee /sys/bus/pci/drivers/snd_hda_intel/unbind<br />
echo -n "0000:00:03.0" | tee /sys/bus/pci/drivers/snd_hda_intel/unbind<br />
;;<br />
post/*)<br />
# Bind ath9k for preventing error and and full sleep mode (wakeup by LID after hibernating) <br />
echo -n "0000:01:00.0" | tee /sys/bus/pci/drivers/ath9k/bind<br />
# bind snd_hda_intel for sound<br />
echo -n "0000:00:1b.0" | tee /sys/bus/pci/drivers/snd_hda_intel/bind<br />
echo -n "0000:00:03.0" | tee /sys/bus/pci/drivers/snd_hda_intel/bind<br />
;;<br />
esac</nowiki>}}<br />
<br />
Make sure to make the script [[executable]]. <br />
<br />
Then [[GRUB#Generate_the_main_configuration_file|rebuild your grub config]].<br />
<br />
=== Fixing audio ===<br />
<br />
==== Baytrail based models ====<br />
<br />
Audio on most baytrail models should work on {{Pkg|linux}} since fix merged into 4.19.7 [https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.19.7&id=f35f68c68ce48a8b70a4c3674663513825b7a1bc], to fix regression in 4.18.15, see bug report [https://lore.kernel.org/lkml/20181030143836.feo7zcxiestylxoo@picard/].<br />
<br />
It is likely that you will also need to use {{ic|alsamixer}} from {{Pkg|alsa-utils}} to turn on "Left Speaker Mixer Left DAC" and "Right Speaker Mixer Right DAC". For more information, see {{Bug|48936}}.<br />
<br />
If you use max98090, you may also need to install [[Advanced Linux Sound Architecture#ALSA firmware]] and symbolically link {{ic|/usr/lib/firmware/sof-cht-max98090.tplg}} to {{ic|/usr/lib/firmware/sof-byt-max98090.tplg}}.<br />
<br />
==== Haswell based models ====<br />
<br />
One or more of followings might help solving audio related issues, setting {{ic|snd_hda_intel}} module index reported the most useful. It is highly possible that you will not need to make any change.<br />
<br />
* Create {{ic|/etc/modprobe.d/alsa.conf}}, the option {{ic|index}} will make sure the analog output is the default (and not HDMI), the option {{ic|model}} will notify the driver our board model which will make the built-in microphone usable (you can try instead {{ic|<nowiki>model=alc283-sense-combo</nowiki>}} or {{ic|<nowiki>model=,alc283-dac-wcaps</nowiki>}}). <br />
<br />
{{hc|head=/etc/modprobe.d/alsa.conf|<br />
output=options snd_hda_intel index=1 model=,alc283-chrome}}<br />
<br />
* Use the {{ic|~/.asoundrc}} file from [https://gist.githubusercontent.com/dhead666/52d6d7d97eff76935713/raw/5b32ee11a2ebbe7a3ee0f928e49b980361a57548/.asoundrc].<br />
<br />
* If having problems with headphones (perhaps no audio playing), try {{ic|alsactl restore}} (requires {{Pkg|alsa-utils}}) in terminal. Now, ALSA should automatically switch between channels when using headphones/speakers. <br />
<br />
* To fix [[Flash]] audio with PulseAudio, use the {{ic|~/.asoundrc}} file from [https://gist.githubusercontent.com/dhead666/0eebff16cd9578c5e035/raw/d4c974fcd50565bf116c57b1884170ecb47f8bf6/.asoundrc].<br />
<br />
=== Hotkeys ===<br />
<br />
[https://support.google.com/chromebook/answer/1047364?hl=en The Chromebook function keys] recognized as standard F1-F10 by the kernel, it is preferable to map them accordingly to their appearance. It would also be nice to get the keys {{ic|Delete, Home, End, PgUp, PgDown}} which in Chrome OS mapped to {{ic|Alt + : BackSpace, Right, Left, Up, Down}}.<br />
<br />
==== xkeyboard configuration ====<br />
<br />
{{Pkg|xkeyboard-config}} 2.16-1 added a {{ic|chromebook}} model that enables the Chrome OS style functions for the function keys. You can, for example, set this using {{ic|localectl set-x11-keymap us chromebook}}. See the {{ic|chromebook}} definition in {{ic|/usr/share/X11/xkb/symbols/inet}} for the full mappings.<br />
<br />
==== Sxhkd configuration ====<br />
<br />
One way to set the hotkeys would be by using the [[Sxhkd]] daemon. Besides {{Pkg|sxhkd}}, this also requires [[Advanced Linux Sound Architecture|amixer]], {{Pkg|xorg-xbacklight}}, and {{Pkg|xautomation}}.<br />
<br />
* See [https://gist.github.com/dhead666/191722ec04842d8d330b] for an example configuration in {{ic|~/.config/sxhkd/sxhkdrc}}.<br />
<br />
==== Xbindkeys configuration ====<br />
<br />
Another way to configure hotkeys would be by using [[Xbindkeys]]. Besides {{Pkg|xbindkeys}} this requires [[Advanced Linux Sound Architecture|amixer]] and {{Pkg|xorg-xbacklight}} and {{AUR|xvkbd}}.<br />
<br />
* See [https://gist.github.com/dhead666/08562a9a760b18b6e758] for an example configuration in {{ic|~/.xbindkeysrc}}.<br />
* See [https://bbs.archlinux.org/viewtopic.php?id=173418&p=3 vilefridge's xbindkeys configuration] for another example.<br />
<br />
===== Alternate xbindkeys configuration =====<br />
<br />
[https://archive.today/2014.10.06-110657/http://pastie.org/9550960 Volchange] (originated in the [https://archive.today/2014.10.06-110659/http://www.debianuserforums.org/viewtopic.php?f=55&t=1453%23p14351 Debian User Forums])) can manipulate the volume with PulseAudio instead of using [[Advanced Linux Sound Architecture|amixer]]. Besides [https://archive.today/2014.10.06-110657/http://pastie.org/9550960 Volchange] this requires {{Pkg|xorg-xbacklight}} and {{AUR|xvkbd}}.<br />
<br />
* Download the script from [https://archive.today/2014.10.06-110657/http://pastie.org/9550960].<br />
* Make it [[executable]]<br />
<br />
See [https://gist.github.com/dhead666/4e23b506441ad424e26e] for a matching {{ic|~/.xbindkeysrc}}.<br />
<br />
==== Patch xkeyboard-config ====<br />
<br />
Another option is to install {{AUR|xkeyboard-config-chromebook}}, for more details visit [https://github.com/dhead666/archlinux-pkgbuilds/tree/master/xkeyboard-config-chromebook].<br />
<br />
==== Mapping in Gnome with gsettings set ====<br />
<br />
Some of the function keys can be mapped in Gnome with the advantage of HUD notifications on changes (like volume and brightness changes) which can supplement one of the mapping methods mentioned above. This [https://gist.github.com/dhead666/0b9c1cc9def939705594 linked example] maps the brightness and volume actions. Notice that {{Pkg|xdotool}} is required.<br />
<br />
=== Power key and lid switch handling ===<br />
<br />
==== Ignore using logind ====<br />
<br />
Out of the box, {{ic|systemd-logind}} will catch power key and lid switch events and handle them: it will shut down the Chromebook on a power key press, and a suspend on a lid close. However, this policy might be a bit harsh given that the power key is an ordinary key at the top right of the keyboard that might be pressed accidentally.<br />
<br />
To configure logind to ignore power key presses and lid switches, add the lines to {{ic|logind.conf}} below.<br />
<br />
{{hc|head=/etc/systemd/logind.conf|<br />
output=HandlePowerKey=ignore<br />
HandleLidSwitch=ignore}}<br />
<br />
Then [[restart]] logind for the changes to take effect.<br />
<br />
Power key and lid switch events will still be logged to journald by logind. See [[Power management#ACPI events]].<br />
<br />
==== Ignore by Gnome ====<br />
<br />
[[Install]] {{Pkg|gnome-tweaks}}, open the Tweak Tool and under Power change the Power Button Action.<br />
<br />
== Known issues ==<br />
<br />
=== Syslinux ===<br />
<br />
Follow Syslinux installation instructions carefully. Try manual installation to see where the problem comes from. If you see [[Syslinux#Missing_operating_system|Missing Operation System]] then it may be because you need to use correct bootloader binary. If syslinux does not work try another [[bootloader]] such as [[GRUB]].<br />
<br />
== See also ==<br />
<br />
* [https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices Developer Information for Chrome OS Devices at the Chromium Projects site]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=173418 BBS topic about the Acer C720] which include generic information on Haswell Based Chromebooks.<br />
* Re-partitioning in Chrome OS [https://chromeos-cr48.blogspot.co.uk/2012/04/chrubuntu-1204-now-with-double-bits.html], [https://web.archive.org/web/20151230152834/http://cr-48-ubuntu.googlecode.com/files/install-ubuntu-1204-7.sh]<br />
* [https://bit.ly/NewChromebooks Brent Sullivan's the always updated list of Chrome OS devices]<br />
* [https://prodct.info/chromebooks/ Google Chromebook Comparison Chart]</div>Crescenthttps://wiki.archlinux.org/index.php?title=Acer_Chromebook_CX5500&diff=729519Acer Chromebook CX55002022-05-14T08:47:43Z<p>Crescent: Add note of modules to blacklist for Acer Chromebook CX5500</p>
<hr />
<div>MrChromebox's firmware only provide the ability to flash SeaBIOS, not remove Google's firmware.<br />
<br />
Suspend and poweroff cause the system to hang with up to the latest kernel on git on 2022-05-14.<br />
<br />
To get suspend and resume to work, blacklist the atmel_mxt_ts and cros_ec_typec modules.<br />
<br />
To do this in grub, edit /etc/default/grub<br />
<br />
Add them to GRUB_CMDLINE_LINUX_DEFAULT.<br />
<br />
GRUB_CMDLINE_LINUX_DEFAULT=".. modprobe.blacklist=atmel_mxt_ts modprobe.blacklist=cros_ec_typec"<br />
<br />
And then regenerate grub.cfg<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg</div>Crescenthttps://wiki.archlinux.org/index.php?title=Chrome_OS_devices/Chromebook&diff=729518Chrome OS devices/Chromebook2022-05-14T08:43:03Z<p>Crescent: /* Hardware comparisons */ Add Acer_Chromebook_CX5500</p>
<hr />
<div>[[Category:Chrome OS devices]]<br />
[[ja:Chromebook]]<br />
Main article: [[Chrome OS devices]].<br />
<br />
== Introduction ==<br />
<br />
=== First generation of Chromebooks ===<br />
<br />
The first generation of Chromebooks: Google Cr-48, Samsung Series 5 500 and Acer AC700 use [https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/custom-firmware#TOC-H2C Insyde H2O firmware] and not Coreboot firmware. There are three approaches how to install Arch Linux on these devices:<br />
* Flash a custom H2C firmware (only available for Google Cr-48) and install Arch as on any other UEFI laptop.<br />
* Take the ChrUbuntu approach which uses the Chrome OS kernel and modules.<br />
* Build and sign your own kernel, see [https://plus.google.com/+OlofJohansson/posts/34PYU79eUqP].<br />
<br />
== Hardware comparisons ==<br />
<br />
{{Warning|The availability of SeaBIOS does not promise device compatibility for Linux or that the pre-installed SeaBIOS works properly. Before purchasing a device visit its page on the ArchWiki and look for Linux users' posts about that model.}}<br />
<br />
<center><br />
{| class="wikitable"<br />
|-<br />
! colspan=11 {{B|Chromebook Models}}<br />
|-<br />
! Available<br />
! Brand<br />
! Model<br />
! Processor<br />
! RAM<br />
! Storage<br />
! Upgradable<br />
! Screen<br />
! Resolution<br />
! SeaBIOS<br />
! Remarks<br />
|-<br />
| Dec 2010<br />
| Google <br />
| Cr-48<br />
| 1.66 GHz Intel Atom N455<br />
| rowspan="3"|2GB<br>DDR3<br />
| rowspan="4"|16GB SSD<br />
| {{G|mSATA}}<br />
| rowspan="2"|12.1 in<br>(30.7 cm)<br />
| rowspan="2"|1280x800<br>(16:10)<br />
| {{R|Unavailable for<br>1st generation}}<br />
| {{G|[https://web.archive.org/web/20180720194838/http://cr-48.wikispaces.com/Flash+BIOS Custom H2C<br>firmware available]}}<br />
|-<br />
| Jun 2011<br />
| Samsung<br />
| Series 5<br>XE500C21<br />
| rowspan="2"|1.66 GHz Intel Atom N570<br />
| {{G|mSATA}}<br />
| {{R|Unavailable for<br>1st generation}}<br />
|<br />
|-<br />
| Jul 2011<br />
| Acer<br />
| AC700<br />
| {{G|mSATA<br>Mini}}<br />
| 11.6 in<br>(29.5 cm)<br />
| 1366x768<br>(16:9)<br />
| {{R|Unavailable for<br>1st generation}}<br />
|<br />
|-<br />
| May 2012<br />
| Samsung<br />
| Series 5<br>XE550C22<br />
| 1.3 GHz Intel Celeron 867<br>1.6 Ghz Intel Core i5 2467M<br />
| 4GB<br>DDR3<br />
| {{G|mSATA}}<br />
| 12.1 in<br>(30.7 cm)<br />
| 1280x800<br>(16:10)<br />
| {{G|In custom<br>firmware only}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| Nov 2012<br />
| Acer<br />
| [[Acer_C710_Chromebook|C710]]<br />
| 1.1 GHz Intel Celeron 847<br/>1.5 GHz Intel Celeron 1007U<br />
| rowspan="2"|2-4GB<br>DDR3<br />
| rowspan="2"|320GB HDD<br>16GB SSD<br />
| {{G|SATA<br>2.5" 7,9.5mm}}<br />
| 11.6 in<br>(29.5 cm)<br />
| rowspan="3"|1366x768<br>(16:9)<br />
| {{G|In custom<br>firmware only}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| rowspan="3"|Feb 2013<br />
| HP<br />
| Pavilion 14<br>Chromebook<br />
| 1.1 GHz Intel Celeron 847<br />
| {{G|SATA<br>2.5" 7,9.5mm}}<br />
| 14 in<br>(35.6 cm)<br />
| {{G|In custom<br>firmware only}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| Lenovo<br />
| ThinkPad X131e<br>Chromebook<br />
| 1.5 GHz Intel Celeron 1007U<br />
| 4GB<br>DDR3<br />
| 16GB SSD<br />
| {{G|mSATA}}<br />
| 11.6 in<br>(29.5 cm)<br />
| {{G|In custom<br>firmware only}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| Google<br />
| Chromebook<br>Pixel<br />
| 1.8 GHz Intel Core i5 3427U<br />
| 4GB<br>DDR3<br />
| 32GB iSSD<br>64GB iSSD<br />
| {{No}}<br />
| 12.85 in<br>(32.6 cm)<br />
| 2560x1700<br>(3:2)<br />
| {{Yes}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| rowspan="2"|Nov 2013<br />
| HP<br />
| [[HP_Chromebook_14|Chromebook 14]]<br />
| 1.4 GHz Intel Celeron 2955U<br />
| rowspan="2"|2GB DDR3<br>4GB DDR3<br />
| rowspan="2"|16GB SSD<br>32GB SSD<br />
| {{G|42mm M.2<br>NGFF}}<br />
| 14 in<br>( 35.6 cm)<br />
| rowspan="9"|1366x768<br>(16:9)<br />
| {{Yes}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| Acer<br />
| [[Acer_C720_Chromebook|C720/C720P<br>Chromebook]]<br />
| 1.4 GHz Intel Celeron 2955U<br>1.7 GHz Intel Core i3-4005U<br />
| {{G|42mm M.2<br>NGFF}}<br />
| 11.6 in<br>(29.5 cm)<br />
| {{Yes}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| Jan 2014<br />
| Toshiba<br />
| CB30/CB35<br>Chromebook<br />
| 1.4 GHz Intel Celeron 2955U<br />
| 2GB DDR3<br />
| 16GB eMMC<br />
| {{No}}<br />
| 13.3 in<br>(33.8 cm)<br />
| {{Yes}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| Apr 2014<br />
| Dell<br />
| [[Dell Chromebook 11|Chromebook 11]]<br />
| 1.4 GHz Intel Celeron 2955U<br>1.7 GHz Intel Core i3-4005U<br />
| 2GB DDR3<br>4GB DDR3<br />
| rowspan="2"| 16GB eMMC<br />
| {{No}}<br />
| rowspan="2"| 11.6 in<br>(29.5 cm)<br />
| {{G|Requires stock<br>SeaBIOS patching}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| rowspan="4"|Jun 2014<br />
| Lenovo<br />
| N20/N20P<br>Chromebook<br />
| rowspan="2"|2.1 GHz Intel BayTrail-M N2830<br />
| 2GB DDR3<br />
| {{No}}<br />
| {{G|Requires writing<br>SeaBIOS}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| Asus<br />
| Chromebook <br>C200/C300<br />
| 2GB DDR3<br>4GB DDR3<br />
| 16GB eMMC<br>32GB eMMC<br />
| {{No}}<br />
| 11.6 in<br>(29.5 cm)<br>13.3 in<br>(33.8 cm)<br />
| {{G|Requires writing<br>SeaBIOS}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| rowspan="2"|Lenovo<br />
| ThinkPad 11e<br>Chromebook<br />
| rowspan="2"|1.83 GHz Intel BayTrail-M N2930<br />
| rowspan="3"|4GB DDR3<br />
| rowspan="2"|16GB eMMC<br />
| {{No}}<br />
| rowspan="3"|11.6 in<br>(29.5 cm)<br />
| {{G|Requires writing<br>SeaBIOS}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| ThinkPad Yoga 11e<br>Chromebook<br />
| {{No}}<br />
| {{G|Requires writing<br>SeaBIOS}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| Jul 2014<br />
| HEXA<br />
| Chromebook Pi<br />
| 2.1 GHz Intel BayTrail-M N2830<br />
| 32GB eMMC<br />
| {{No}}<br />
| {{No}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| rowspan="2"|Sep 2014<br />
| Toshiba<br />
| CB30/CB35<br>Chromebook 2<br />
| 2.16 GHz Intel BayTrail-M N2840<br />
| 2GB DDR3<br>4GB DDR3<br />
| rowspan="2"| 16GB eMMC<br />
| {{No}}<br />
| 13.3 in<br>(33.8 cm)<br />
| 1366x768<br>(16:9)<br>1920x1080<br>(16:9)<br />
| {{G|Requires writing<br>SeaBIOS}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| rowspan="2"|Acer<br />
| [[Acer CB3-111 Chromebook|CB3-111]]<br>Chromebook 11<br />
| 2.1 GHz Intel BayTrail-M N2830<br />
| 2GB DDR3<br />
| {{No}}<br />
| rowspan="6"|11.6 in<br>(29.5 cm)<br />
| rowspan="6"|1366x768<br>(16:9)<br />
| {{G|Requires writing<br>SeaBIOS}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| rowspan="3"|Oct 2014<br />
| C730<br>Chromebook 11<br />
| rowspan="4"|2.16 GHz Intel BayTrail-M N2840<br />
| rowspan="2"|2GB DDR3<br>4GB DDR3<br />
| 16GB eMMC<br>32GB eMMC<br />
| {{No}}<br />
| {{G|Requires writing<br>SeaBIOS}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| HP<br />
| Chromebook 11<br>G3<br />
| rowspan="3"|16GB eMMC<br />
| {{No}}<br />
| {{G|Requires writing<br>SeaBIOS}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| Samsung<br />
| Chromebook 2<br>XE500C12<br />
| 2GB DDR3<br />
| {{No}}<br />
| {{G|Requires writing<br>SeaBIOS}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| rowspan="3"|Feb 2015<br />
| Dell<br />
| Chromebook 11<br>3120<br />
| rowspan="3"| 2GB DDR3<br>4GB DDR3<br />
| {{No}}<br />
| {{G|Requires writing<br>SeaBIOS}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| rowspan="3"|Acer<br />
| C740 (EDU)<br>Chromebook 11<br />
| rowspan="2"|1.5 GHz Intel Celeron 3205U<br>2.00 GHz Intel Core i3-5005U<br />
| 16GB SSD<br>32GB SSD<br />
| {{G|42mm M.2<br>NGFF}}<br />
| {{G|Requires writing<br>SeaBIOS}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| CB5-571<br>Chromebook 15<br />
| 16GB<br>32GB<br />
| {{G|42mm M.2<br>NGFF}}<br />
| rowspan="2"|15.6 in<br>(39.6 cm)<br />
| rowspan="2"|1366x768<br>(16:9)<br>1920x1080<br>(16:9)<br />
| {{G|Requires writing<br>SeaBIOS}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| rowspan="3"|Mar 2015<br />
| C910 (EDU)<br>Chromebook 15<br />
| 1.5 GHz Intel Celeron 3205U<br>2.00 GHz Intel Core i3-5005U<br>2.2 GHz Intel Core i5-5200U<br />
| 4GB DDR3<br />
| 16GB SSD<br>32GB SSD<br />
| {{G|[https://www.reddit.com/r/chromeos/comments/3asc4f/no_physical_differences_beteen_acer_chromebook/ 42mm M.2<br>NGFF]}}<br />
| {{G|Requires writing<br>SeaBIOS}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| Google<br />
| [[Chromebook Pixel 2|Chromebook<br>Pixel 2]]<br />
| 2.2 GHz Intel Core i5-5200U<br>2.4 GHz Intel Core i7-5500U<br />
| 8GB DDR3<br>16GB DDR3<br />
| 32GB<br>64GB<br />
| {{No}}<br />
| 12.85 in<br>(32.6 cm)<br />
| 2560x1700<br> (3:2)<br />
| {{Yes}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| Lenovo<br />
| N21<br>Chromebook<br />
| rowspan="2"|2.16 GHz Intel BayTrail-M N2840<br />
| 2GB DDR3<br>4GB DDR3<br />
| rowspan="2"|16GB eMMC<br />
| {{No}}<br />
| rowspan="2"|11.6 in<br>(29.5 cm)<br />
| rowspan="2"|1366x768<br>(16:9)<br />
| {{G|Requires writing<br>SeaBIOS}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| Jan 2016<br />
| Acer<br />
| [[Acer_CB3-131_Chromebook|CB3-131-C8GZ<br>(Chromebook 11)]]<br />
| 4GB<br>DDR3<br />
| {{No}}<br />
| {{G|Requires writing<br>SeaBIOS}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| Oct 2017<br />
| Google<br />
| [[Pixelbook]]<br />
| Intel Core i5-7Y57<br>Intel Core i5-7Y57<br>Intel Core i7-7Y75<br />
| 8GB DDR3<br>8GB DDR3<br>16GB DDR3<br />
| 128GB<br>256GB<br>512GB<br />
| {{No}}<br />
| 12.3 in<br>(31.2 cm)<br />
| 2400x1600<br> (3:2)<br />
| {{Yes}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| March 2018<br />
| Acer<br />
| [[Acer Chromebook 11 (C732)|Chromebook 11 (C732)]] <br/>Astronaut<br />
| Intel(R) Celeron(R) CPU N3450 @ 1.10GHz<br />
| 4GB LPDDR4<br/>8GB LPDDR4<br />
| 32GB<br/>64GB<br />
| {{No}}<br />
| 11.6 in <br/> (29.5 cm)<br />
| 1366 x 768<br />
| {{Yes}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| March 2020<br />
| Lenovo<br />
| [[Lenovo_IdeaPad_Flex_5_13IML05_Chromebook|IdeaPad Flex 5 13IML05 Chromebook]]<br />
| Intel Celeron 5205U<br>Intel Core i3-10110U<br>Intel Core i5-10210U<br />
| 4GB DDR4<br>8GB DDR4<br />
| 32GB eMMC<br>64GB eMMC<br>128GB SSD<br>256GB SSD<br><br />
| {{Y|?}}<br />
| 13.3 in <br> (33.8 cm)<br />
| 1920 x 1080 (16:9)<br />
| {{Y|?}}<br />
| {{G|Custom firmware<br>available}}<br />
|-<br />
| Q4 2021<br />
| Acer<br />
| [[Acer_Chromebook_CX5500|Acer_Chromebook_CX5500]]<br />
| Intel Core i5-1135G7<br />
| 16GB DDR3<br />
| 128GB SSD<br />
| <br />
| 15.6 in<br />
| 1920 x 1080 (16:9)<br />
| <br />
| <br />
|}<br />
</center><br />
<br />
== See also ==<br />
<br />
* [https://wiki.galliumos.org/Hardware_Compatibility Gallium OS hardware compatibility] for Chromebooks</div>Crescenthttps://wiki.archlinux.org/index.php?title=Intel_GVT-g&diff=578390Intel GVT-g2019-07-30T09:28:34Z<p>Crescent: typo</p>
<hr />
<div>[[Category:Virtualization]]<br />
[[ja:Intel GVT-g]]<br />
{{Related articles start}}<br />
{{Related|PCI passthrough via OVMF}}<br />
{{Related|QEMU}}<br />
{{Related|Intel graphics}}<br />
{{Related articles end}}<br />
<br />
[https://github.com/intel/gvt-linux/wiki/GVTg_Setup_Guide Intel GVT-g] is a technology that provides mediated device passthrough for Intel GPUs (Broadwell and newer). It can be used to virtualize the GPU for multiple guest VMs, effectively providing near-native graphics performance in the VM and still letting your host use the virtualized GPU normally. This is useful if you want accelerated graphics in Windows VMs running on ultrabooks without dedicated GPUs for [[PCI_passthrough_via_OVMF|full device passthrough]]. (Similar technologies exist for NVIDIA and AMD GPUs, but they're available only in the "professional" GPU lines like Quadro, Radeon Pro and so on.)<br />
<br />
There is also a variant of this technology called GVT-d - it is essentially Intel's name for full device passthrough with the vfio-pci driver. With GVT-d, the host cannot use the virtualized GPU.<br />
<br />
== Configuration ==<br />
<br />
You'll have to create a virtual GPU (vGPU) first, then assign it to your VM. The guest with a vGPU sees it as a "regular" GPU - just install the latest native drivers. (The vGPU actually does need specialized drivers to work correctly, but all the required changes are present in the latest upstream Linux/Windows drivers.)<br />
<br />
You'll need to:<br />
<br />
* Use at least Linux 4.16 and [[QEMU]] 2.12.<br />
* [[Mkinitcpio#MODULES|Enable]] kernel modules {{ic|kvmgt vfio-iommu-type1 vfio-mdev}}.<br />
* Add {{ic|1=i915.enable_gvt=1}} to your [[kernel parameters]] to enable GPU virtualization.<br />
* Find the PCI address and domain number of your GPU ({{ic|$GVT_PCI}} and {{ic|$GVT_DOM}} in commands below), as it resides in {{ic|/sys/bus/pci/devices}}. It looks like this: {{ic|0000:00:02.0}} - you can look it up by running {{ic|lspci -D -nn}}, looking for {{ic|VGA compatible controller: Intel Corporation HD Graphics ...}} and noting down the address on the left.<br />
* Generate the vGPU GUID ({{ic|$GVT_GUID}} in commands below) which you'll use to create and assign the vGPU. A single virtual GPU can be assigned only to a single VM - create as many GUIDs as you want vGPUs. (You can do so by running {{ic|uuidgen}}.)<br />
<br />
After rebooting with the {{ic|1=i915.enable_gvt=1}} flag, you should be able to create vGPUs - there are multiple vGPU types you can create, which mainly differ in the amount of resources dedicated to that vGPU. You can look up what types are available in your system (and {{ic|cat description}} inside of each type to discover what it's capable of) like this:<br />
<br />
# ls /sys/devices/pci${GVT_DOM}/$GVT_PCI/mdev_supported_types<br />
i915-GVTg_V5_1 # Video memory: <512MB, 2048MB>, resolution: up to 1920x1200<br />
i915-GVTg_V5_2 # Video memory: <256MB, 1024MB>, resolution: up to 1920x1200<br />
i915-GVTg_V5_4 # Video memory: <128MB, 512MB>, resolution: up to 1920x1200<br />
i915-GVTg_V5_8 # Video memory: <64MB, 384MB>, resolution: up to 1024x768<br />
<br />
Pick a type you want to use - we'll refer to it as {{ic|$GVT_TYPE}} below. Use the GUID you've created to create a vGPU with a chosen type:<br />
<br />
# echo "$GVT_GUID" > "/sys/devices/pci${GVT_DOM}/$GVT_PCI/mdev_supported_types/$GVT_TYPE/create"<br />
<br />
You can repeat this as many times as you want with different GUIDs. All created vGPUs will land in {{ic|/sys/bus/pci/devices/$GVT_PCI/}} - if you'd like to remove a vGPU, you can do:<br />
<br />
# echo 1 > /sys/bus/pci/devices/$GVT_PCI/$GVT_GUID/remove<br />
<br />
=== Using QEMU CLI ===<br />
<br />
To create a VM with the virtualized GPU, add this parameter to the QEMU command line:<br />
<br />
-device vfio-pci,sysfsdev=/sys/bus/pci/devices/$GVT_PCI/$GVT_GUID,rombar=0<br />
<br />
=== Using libvirt ===<br />
<br />
With libvirt, add the following device to the {{ic|<devices>}} element of the VM definition:<br />
<br />
{{hc|$ virsh edit [vmname]|2=<br />
...<br />
<hostdev mode='subsystem' type='mdev' managed='no' model='vfio-pci' display='off'><br />
<source><br />
<address uuid=''''GVT_GUID''''/><br />
</source><br />
</hostdev><br />
...<br />
}}<br />
<br />
Replace '''GVT_GUID''' with the UUID of your vGPU.<br />
<br />
==== Getting vGPU display contents ====<br />
<br />
There are several possible ways to retrieve the display contents from the vGPU.<br />
<br />
===== Using DMA-BUF display =====<br />
<br />
{{Warning|According to this [https://github.com/intel/gvt-linux/issues/20 issue], this method will not work with UEFI guests using (unmodified) OVMF. See below for patches/workarounds. }}<br />
<br />
First, modify the XML schema of the VM definition so that we can use QEMU-specific elements later, changing<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
<domain type='kvm'><br />
</nowiki>}}<br />
<br />
to<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'><br />
</nowiki>}}<br />
<br />
Then add this configuration to the end of the {{ic|<domain>}} element, i. e. insert this text right above the closing {{ic|</domain>}} tag:<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
...<br />
<qemu:commandline><br />
<qemu:arg value='-set'/><br />
<qemu:arg value='device.hostdev0.x-igd-opregion=on'/><br />
</qemu:commandline><br />
...<br />
</nowiki>}}<br />
<br />
====== Using DMA-BUF with UEFI/OVMF ======<br />
<br />
As stated above, DMA-BUF display will not work with UEFI-based guests using (unmodified) OVMF because it won't create the necessary ACPI OpRegion exposed via QEMU's nonstandard fw_cfg interface. See [https://bugzilla.tianocore.org/show_bug.cgi?id=935 this OVMF bug] for details of this issue.<br />
<br />
According to [https://github.com/intel/gvt-linux/issues/23#issuecomment-468125999 this GitHub comment], the OVMF bug report suggests several solutions to the problem. It is possible to:<br />
<br />
* [https://bugzilla.tianocore.org/attachment.cgi?id=165 patch] OVMF ([https://bugzilla.tianocore.org/show_bug.cgi?id=935#c4 details]) to add an Intel-specific quirk (most straightforward but non-upstreamable solution);<br />
* [https://bugzilla.tianocore.org/attachment.cgi?id=168 patch] the host kernel ([https://bugzilla.tianocore.org/show_bug.cgi?id=935#c12 details]) to automatically provide an option ROM for the vGPU containing basically the same code but in option ROM format;<br />
* [http://120.25.59.132:3000/vbios_gvt_uefi.rom extract the OpROM] from the kernel patch ([https://www.reddit.com/r/VFIO/comments/av736o/creating_a_clover_bios_nonuefi_install_for_qemu/ehdz6mf/ source]) and feed it to QEMU as an override.<br />
<br />
We will go with the last option because it does not involve patching anything. (Note: if the link goes down, the OpROM can be extracted from the kernel patch by hand.)<br />
<br />
Download {{ic|vbios_gvt_uefi.rom}} and place it somewhere world-accessible (we will use {{ic|/}} to make an example). Then edit the VM definition, appending this configuration to the {{ic|<qemu:commandline>}} element we added earlier:<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
...<br />
<qemu:arg value='-set'/><br />
<qemu:arg value='device.hostdev0.romfile=</nowiki>'''/vbios_gvt_uefi.rom'''<nowiki>'/><br />
...<br />
</nowiki>}}<br />
<br />
===== Using RAMFB display =====<br />
<br />
This can be combined with the above DMA-BUF configuration in order to also display everything that happens before the guest Intel driver is loaded (i. e. POST, the firmware interface and the guest initialization).<br />
<br />
First, modify the XML schema of the VM definition so that we can use QEMU-specific elements later, changing<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
<domain type='kvm'><br />
</nowiki>}}<br />
<br />
to<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'><br />
</nowiki>}}<br />
<br />
Then add this configuration to the end of the {{ic|<domain>}} element, i. e. insert this text right above the closing {{ic|</domain>}} tag:<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
...<br />
<qemu:commandline><br />
<qemu:arg value='-set'/><br />
<qemu:arg value='device.hostdev0.ramfb=on'/><br />
<qemu:arg value='-set'/><br />
<qemu:arg value='device.hostdev0.driver=vfio-pci-nohotplug'/><br />
</qemu:commandline><br />
...<br />
</nowiki>}}<br />
<br />
==== Display vGPU output ====<br />
<br />
Due to an [https://gitlab.freedesktop.org/spice/spice-gtk/issues/100 issue] with spice-gtk the configuration is different depending of the SPICE client EGL implementation.<br />
<br />
===== Output using SPICE with MESA EGL =====<br />
<br />
$ virsh edit [vmname]<br />
<br />
# Ensure the above added <hostdev> device have the display attribute set to 'on'.<br />
# Remove all <graphics> and <video> devices.<br />
# Add the following devices:<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
...<br />
<graphics type='spice'><br />
<listen type='none'/><br />
<gl enable='yes'/><br />
</graphics><br />
<video><br />
<model type='none'/><br />
</video><br />
...<br />
</nowiki>}}<br />
The are an optional attribute rendernode in gl tag to allow specify the renderer, example:<br />
<gl enable='yes' rendernode='/dev/dri/by-path/pci-0000:00:02.0-render'/><br />
<br />
===== Output using SPICE with NVIDIA EGL or VNC =====<br />
<br />
$ virsh edit [vmname]<br />
<br />
# Ensure the above added <hostdev> device have the display attribute set to 'on'.<br />
# Remove all <graphics> and <video> devices.<br />
# Add the following devices:<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
...<br />
<graphics type='spice' autoport='yes'><br />
<listen type='address'/><br />
</graphics><br />
<graphics type='egl-headless'/><br />
<video><br />
<model type='none'/><br />
</video><br />
...<br />
</nowiki>}}<br />
The <graphics type='spice'> type can be changed to 'vnc' to use VNC instead.<br />
<br />
Also there are an ''optional'' tag <gl> inside <graphics type='egl-headless'> tag to force a specific renderer, do not put inside the 'spice' graphics due the mentioned bug, example:<br />
<graphics type='egl-headless'><br />
<gl rendernode='/dev/dri/by-path/pci-0000:00:02.0-render'/><br />
</graphics><br />
<br />
===== Disable all output =====<br />
<br />
To ensure no emulated GPU is added one can edit the VM configuration and do the following changes:<br />
<br />
$ virsh edit [vmname]<br />
<br />
# Remove all <graphics> devices.<br />
# Change the <video> device to be type 'none'.<br />
# Ensure the above added <hostdev> device have the display attribute set to 'off'.<br />
<br />
Then the only way to see the display output would be using a software server like RDP, VNC or Looking Glass.<br />
To see more details in [[PCI_passthrough_via_OVMF#Using_Looking_Glass_to_stream_guest_screen_to_the_host|using Looking Glass to stream guest screen to the host]].<br />
<br />
== Troubleshooting ==<br />
=== Missing mdev_supported_types directory ===<br />
If you have followed instructions and added {{ic|1=i915.enable_gvt=1}} kernel parameter, but there is still no {{ic|/sys/bus/pci/devices/0000:02:00.0/mdev_supported_types}} directory, probably your hardware is not supported. Check dmesg log for this message:<br />
{{hc|$ dmesg {{!}} grep -i gvt |2=<br />
[ 4.227468] [drm] Unsupported device. GVT-g is disabled<br />
}}<br />
<br />
If that is the case, you may want to check upstream for support plans.<br />
For example, for the "Coffee Lake" (CFL) platform support, see https://github.com/intel/gvt-linux/issues/53<br />
<br />
=== Windows hanging with bad memory error ===<br />
<br />
If Windows is hanging due to a Bad Memory error look for more details via dmesg. If the logs show something like rlimit memory exceeded, you may need to increase the max memory linux allows qemu to allocate. Assuming you are in the group kvm, adding the following to /etc/security/limits.conf and restarting the PC fixed the errors for me.<br />
<br />
# qemu kvm, need high memlock to allocate mem for vga-passthrough<br />
@kvm hard memlock 8388608<br />
@kvm soft memlock 8388608<br />
<br />
== See also ==<br />
<br />
* [https://github.com/intel/gvt-linux/wiki/GVTg_Setup_Guide Official GVT-g Setup Guide]<br />
* [https://github.com/intel/gvt-linux/wiki/Dma_Buf_User_Guide Official GVT-g DMA-BUF User Guide].<br />
* [https://www.reddit.com/r/VFIO/comments/8h352p/guide_running_windows_via_qemukvm_and_intel_gvtg/ Running Windows via QEMU/KVM and Intel GVT-g]<br />
* [https://blog.bepbep.co/posts/gvt/ Blog post about using GVT]</div>Crescenthttps://wiki.archlinux.org/index.php?title=Intel_GVT-g&diff=578389Intel GVT-g2019-07-30T09:28:15Z<p>Crescent: Add section on fixing bad memory errors</p>
<hr />
<div>[[Category:Virtualization]]<br />
[[ja:Intel GVT-g]]<br />
{{Related articles start}}<br />
{{Related|PCI passthrough via OVMF}}<br />
{{Related|QEMU}}<br />
{{Related|Intel graphics}}<br />
{{Related articles end}}<br />
<br />
[https://github.com/intel/gvt-linux/wiki/GVTg_Setup_Guide Intel GVT-g] is a technology that provides mediated device passthrough for Intel GPUs (Broadwell and newer). It can be used to virtualize the GPU for multiple guest VMs, effectively providing near-native graphics performance in the VM and still letting your host use the virtualized GPU normally. This is useful if you want accelerated graphics in Windows VMs running on ultrabooks without dedicated GPUs for [[PCI_passthrough_via_OVMF|full device passthrough]]. (Similar technologies exist for NVIDIA and AMD GPUs, but they're available only in the "professional" GPU lines like Quadro, Radeon Pro and so on.)<br />
<br />
There is also a variant of this technology called GVT-d - it is essentially Intel's name for full device passthrough with the vfio-pci driver. With GVT-d, the host cannot use the virtualized GPU.<br />
<br />
== Configuration ==<br />
<br />
You'll have to create a virtual GPU (vGPU) first, then assign it to your VM. The guest with a vGPU sees it as a "regular" GPU - just install the latest native drivers. (The vGPU actually does need specialized drivers to work correctly, but all the required changes are present in the latest upstream Linux/Windows drivers.)<br />
<br />
You'll need to:<br />
<br />
* Use at least Linux 4.16 and [[QEMU]] 2.12.<br />
* [[Mkinitcpio#MODULES|Enable]] kernel modules {{ic|kvmgt vfio-iommu-type1 vfio-mdev}}.<br />
* Add {{ic|1=i915.enable_gvt=1}} to your [[kernel parameters]] to enable GPU virtualization.<br />
* Find the PCI address and domain number of your GPU ({{ic|$GVT_PCI}} and {{ic|$GVT_DOM}} in commands below), as it resides in {{ic|/sys/bus/pci/devices}}. It looks like this: {{ic|0000:00:02.0}} - you can look it up by running {{ic|lspci -D -nn}}, looking for {{ic|VGA compatible controller: Intel Corporation HD Graphics ...}} and noting down the address on the left.<br />
* Generate the vGPU GUID ({{ic|$GVT_GUID}} in commands below) which you'll use to create and assign the vGPU. A single virtual GPU can be assigned only to a single VM - create as many GUIDs as you want vGPUs. (You can do so by running {{ic|uuidgen}}.)<br />
<br />
After rebooting with the {{ic|1=i915.enable_gvt=1}} flag, you should be able to create vGPUs - there are multiple vGPU types you can create, which mainly differ in the amount of resources dedicated to that vGPU. You can look up what types are available in your system (and {{ic|cat description}} inside of each type to discover what it's capable of) like this:<br />
<br />
# ls /sys/devices/pci${GVT_DOM}/$GVT_PCI/mdev_supported_types<br />
i915-GVTg_V5_1 # Video memory: <512MB, 2048MB>, resolution: up to 1920x1200<br />
i915-GVTg_V5_2 # Video memory: <256MB, 1024MB>, resolution: up to 1920x1200<br />
i915-GVTg_V5_4 # Video memory: <128MB, 512MB>, resolution: up to 1920x1200<br />
i915-GVTg_V5_8 # Video memory: <64MB, 384MB>, resolution: up to 1024x768<br />
<br />
Pick a type you want to use - we'll refer to it as {{ic|$GVT_TYPE}} below. Use the GUID you've created to create a vGPU with a chosen type:<br />
<br />
# echo "$GVT_GUID" > "/sys/devices/pci${GVT_DOM}/$GVT_PCI/mdev_supported_types/$GVT_TYPE/create"<br />
<br />
You can repeat this as many times as you want with different GUIDs. All created vGPUs will land in {{ic|/sys/bus/pci/devices/$GVT_PCI/}} - if you'd like to remove a vGPU, you can do:<br />
<br />
# echo 1 > /sys/bus/pci/devices/$GVT_PCI/$GVT_GUID/remove<br />
<br />
=== Using QEMU CLI ===<br />
<br />
To create a VM with the virtualized GPU, add this parameter to the QEMU command line:<br />
<br />
-device vfio-pci,sysfsdev=/sys/bus/pci/devices/$GVT_PCI/$GVT_GUID,rombar=0<br />
<br />
=== Using libvirt ===<br />
<br />
With libvirt, add the following device to the {{ic|<devices>}} element of the VM definition:<br />
<br />
{{hc|$ virsh edit [vmname]|2=<br />
...<br />
<hostdev mode='subsystem' type='mdev' managed='no' model='vfio-pci' display='off'><br />
<source><br />
<address uuid=''''GVT_GUID''''/><br />
</source><br />
</hostdev><br />
...<br />
}}<br />
<br />
Replace '''GVT_GUID''' with the UUID of your vGPU.<br />
<br />
==== Getting vGPU display contents ====<br />
<br />
There are several possible ways to retrieve the display contents from the vGPU.<br />
<br />
===== Using DMA-BUF display =====<br />
<br />
{{Warning|According to this [https://github.com/intel/gvt-linux/issues/20 issue], this method will not work with UEFI guests using (unmodified) OVMF. See below for patches/workarounds. }}<br />
<br />
First, modify the XML schema of the VM definition so that we can use QEMU-specific elements later, changing<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
<domain type='kvm'><br />
</nowiki>}}<br />
<br />
to<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'><br />
</nowiki>}}<br />
<br />
Then add this configuration to the end of the {{ic|<domain>}} element, i. e. insert this text right above the closing {{ic|</domain>}} tag:<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
...<br />
<qemu:commandline><br />
<qemu:arg value='-set'/><br />
<qemu:arg value='device.hostdev0.x-igd-opregion=on'/><br />
</qemu:commandline><br />
...<br />
</nowiki>}}<br />
<br />
====== Using DMA-BUF with UEFI/OVMF ======<br />
<br />
As stated above, DMA-BUF display will not work with UEFI-based guests using (unmodified) OVMF because it won't create the necessary ACPI OpRegion exposed via QEMU's nonstandard fw_cfg interface. See [https://bugzilla.tianocore.org/show_bug.cgi?id=935 this OVMF bug] for details of this issue.<br />
<br />
According to [https://github.com/intel/gvt-linux/issues/23#issuecomment-468125999 this GitHub comment], the OVMF bug report suggests several solutions to the problem. It is possible to:<br />
<br />
* [https://bugzilla.tianocore.org/attachment.cgi?id=165 patch] OVMF ([https://bugzilla.tianocore.org/show_bug.cgi?id=935#c4 details]) to add an Intel-specific quirk (most straightforward but non-upstreamable solution);<br />
* [https://bugzilla.tianocore.org/attachment.cgi?id=168 patch] the host kernel ([https://bugzilla.tianocore.org/show_bug.cgi?id=935#c12 details]) to automatically provide an option ROM for the vGPU containing basically the same code but in option ROM format;<br />
* [http://120.25.59.132:3000/vbios_gvt_uefi.rom extract the OpROM] from the kernel patch ([https://www.reddit.com/r/VFIO/comments/av736o/creating_a_clover_bios_nonuefi_install_for_qemu/ehdz6mf/ source]) and feed it to QEMU as an override.<br />
<br />
We will go with the last option because it does not involve patching anything. (Note: if the link goes down, the OpROM can be extracted from the kernel patch by hand.)<br />
<br />
Download {{ic|vbios_gvt_uefi.rom}} and place it somewhere world-accessible (we will use {{ic|/}} to make an example). Then edit the VM definition, appending this configuration to the {{ic|<qemu:commandline>}} element we added earlier:<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
...<br />
<qemu:arg value='-set'/><br />
<qemu:arg value='device.hostdev0.romfile=</nowiki>'''/vbios_gvt_uefi.rom'''<nowiki>'/><br />
...<br />
</nowiki>}}<br />
<br />
===== Using RAMFB display =====<br />
<br />
This can be combined with the above DMA-BUF configuration in order to also display everything that happens before the guest Intel driver is loaded (i. e. POST, the firmware interface and the guest initialization).<br />
<br />
First, modify the XML schema of the VM definition so that we can use QEMU-specific elements later, changing<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
<domain type='kvm'><br />
</nowiki>}}<br />
<br />
to<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'><br />
</nowiki>}}<br />
<br />
Then add this configuration to the end of the {{ic|<domain>}} element, i. e. insert this text right above the closing {{ic|</domain>}} tag:<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
...<br />
<qemu:commandline><br />
<qemu:arg value='-set'/><br />
<qemu:arg value='device.hostdev0.ramfb=on'/><br />
<qemu:arg value='-set'/><br />
<qemu:arg value='device.hostdev0.driver=vfio-pci-nohotplug'/><br />
</qemu:commandline><br />
...<br />
</nowiki>}}<br />
<br />
==== Display vGPU output ====<br />
<br />
Due to an [https://gitlab.freedesktop.org/spice/spice-gtk/issues/100 issue] with spice-gtk the configuration is different depending of the SPICE client EGL implementation.<br />
<br />
===== Output using SPICE with MESA EGL =====<br />
<br />
$ virsh edit [vmname]<br />
<br />
# Ensure the above added <hostdev> device have the display attribute set to 'on'.<br />
# Remove all <graphics> and <video> devices.<br />
# Add the following devices:<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
...<br />
<graphics type='spice'><br />
<listen type='none'/><br />
<gl enable='yes'/><br />
</graphics><br />
<video><br />
<model type='none'/><br />
</video><br />
...<br />
</nowiki>}}<br />
The are an optional attribute rendernode in gl tag to allow specify the renderer, example:<br />
<gl enable='yes' rendernode='/dev/dri/by-path/pci-0000:00:02.0-render'/><br />
<br />
===== Output using SPICE with NVIDIA EGL or VNC =====<br />
<br />
$ virsh edit [vmname]<br />
<br />
# Ensure the above added <hostdev> device have the display attribute set to 'on'.<br />
# Remove all <graphics> and <video> devices.<br />
# Add the following devices:<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
...<br />
<graphics type='spice' autoport='yes'><br />
<listen type='address'/><br />
</graphics><br />
<graphics type='egl-headless'/><br />
<video><br />
<model type='none'/><br />
</video><br />
...<br />
</nowiki>}}<br />
The <graphics type='spice'> type can be changed to 'vnc' to use VNC instead.<br />
<br />
Also there are an ''optional'' tag <gl> inside <graphics type='egl-headless'> tag to force a specific renderer, do not put inside the 'spice' graphics due the mentioned bug, example:<br />
<graphics type='egl-headless'><br />
<gl rendernode='/dev/dri/by-path/pci-0000:00:02.0-render'/><br />
</graphics><br />
<br />
===== Disable all output =====<br />
<br />
To ensure no emulated GPU is added one can edit the VM configuration and do the following changes:<br />
<br />
$ virsh edit [vmname]<br />
<br />
# Remove all <graphics> devices.<br />
# Change the <video> device to be type 'none'.<br />
# Ensure the above added <hostdev> device have the display attribute set to 'off'.<br />
<br />
Then the only way to see the display output would be using a software server like RDP, VNC or Looking Glass.<br />
To see more details in [[PCI_passthrough_via_OVMF#Using_Looking_Glass_to_stream_guest_screen_to_the_host|using Looking Glass to stream guest screen to the host]].<br />
<br />
== Troubleshooting ==<br />
=== Missing mdev_supported_types directory ===<br />
If you have followed instructions and added {{ic|1=i915.enable_gvt=1}} kernel parameter, but there is still no {{ic|/sys/bus/pci/devices/0000:02:00.0/mdev_supported_types}} directory, probably your hardware is not supported. Check dmesg log for this message:<br />
{{hc|$ dmesg {{!}} grep -i gvt |2=<br />
[ 4.227468] [drm] Unsupported device. GVT-g is disabled<br />
}}<br />
<br />
If that is the case, you may want to check upstream for support plans.<br />
For example, for the "Coffee Lake" (CFL) platform support, see https://github.com/intel/gvt-linux/issues/53<br />
<br />
=== Windows hanging with bad memory error ==<br />
<br />
If Windows is hanging due to a Bad Memory error look for more details via dmesg. If the logs show something like rlimit memory exceeded, you may need to increase the max memory linux allows qemu to allocate. Assuming you are in the group kvm, adding the following to /etc/security/limits.conf and restarting the PC fixed the errors for me.<br />
<br />
# qemu kvm, need high memlock to allocate mem for vga-passthrough<br />
@kvm hard memlock 8388608<br />
@kvm soft memlock 8388608<br />
<br />
== See also ==<br />
<br />
* [https://github.com/intel/gvt-linux/wiki/GVTg_Setup_Guide Official GVT-g Setup Guide]<br />
* [https://github.com/intel/gvt-linux/wiki/Dma_Buf_User_Guide Official GVT-g DMA-BUF User Guide].<br />
* [https://www.reddit.com/r/VFIO/comments/8h352p/guide_running_windows_via_qemukvm_and_intel_gvtg/ Running Windows via QEMU/KVM and Intel GVT-g]<br />
* [https://blog.bepbep.co/posts/gvt/ Blog post about using GVT]</div>Crescenthttps://wiki.archlinux.org/index.php?title=Solid_state_drive&diff=578383Solid state drive2019-07-30T08:06:56Z<p>Crescent: Remove section I added on WD drives, seems common problem with multiple brands to have to add nvme_core.default_ps_max_latency_us=5500</p>
<hr />
<div>[[Category:Storage]]<br />
[[it:Solid state drive]]<br />
[[ja:ソリッドステートドライブ]]<br />
[[ru:Solid state drive]]<br />
[[zh-hans:Solid state drive]]<br />
[[zh-hant:Solid state drive]]<br />
{{Related articles start}}<br />
{{Related|Solid state drive/NVMe}}<br />
{{Related|Solid state drive/Memory cell clearing}}<br />
{{Related|Benchmarking/Data storage devices}}<br />
{{Related|Improving performance#Storage devices}}<br />
{{Related|Flashcache}}<br />
{{Related articles end}}<br />
This article covers special topics for operating [[Wikipedia:Solid-state drive|solid state drives]] (SSDs) and other flash-memory based storage devices. If you want to partition an SSD for a specific purpose, it may be useful to consider the [[Wikipedia:List of file systems#File systems optimized for flash memory, solid state media|List of file systems optimized for flash memory]]. For general usage, you should simply choose your preferred [[filesystem]].<br />
<br />
== Usage ==<br />
<br />
=== TRIM ===<br />
<br />
Most SSDs support the [[wikipedia:TRIM|ATA_TRIM command]] for sustained long-term performance and wear-leveling. A [https://www.techspot.com/review/737-ocz-vector-150-ssd/page9.html techspot article] shows performance benchmark examples of before and after filling an SSD with data.<br />
<br />
As of Linux kernel version 3.8 onwards, support for TRIM was continually added for the different [[filesystems]]. See the following table for an indicative overview:<br />
<br />
{| class="wikitable"<br />
! File system !! Continuous TRIM <br> ({{ic|discard}} option) !! Periodic TRIM <br> (''fstrim'') !! References<br> and notes<br />
|-<br />
| [[Ext3]] || {{No}} || {{META Table cell|?}} || <br />
|-<br />
| [[Ext4]] || {{Yes}} || {{Yes}} || [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/ext4.txt?id=5012284700775a4e6e3fbe7eac4c543c4874b559#n342]<br />
|-<br />
| [[Btrfs]] || {{Yes}} || {{Yes}} ||<br />
|-<br />
| [[JFS]] || {{Yes}} || {{Yes}} || [https://www.phoronix.com/scan.php?page=news_item&px=MTE5ODY]<br />
|-<br />
| [[XFS]] || {{Yes}} || {{Yes}} || [http://xfs.org/index.php/FITRIM/discard]<br />
|-<br />
| [[F2FS]] || {{Yes}} || {{Yes}} ||<br />
|-<br />
| [[VFAT]] || {{Yes}} || {{Yes}} || ''fstrim'' is supported since kernel 4.19<br />
|-<br />
| [[NTFS-3G]] || {{No}} || {{Yes}} || since version 2015.3.14, [http://permalink.gmane.org/gmane.comp.file-systems.ntfs-3g.devel/1101]<br />
|}<br />
<br />
{{Warning|Users need to be certain that their SSD supports TRIM before attempting to use it. Data loss can occur otherwise!}}<br />
<br />
To verify TRIM support, run:<br />
<br />
$ lsblk --discard<br />
<br />
And check the values of DISC-GRAN (discard granularity) and DISC-MAX (discard max bytes) columns. Non-zero values indicate TRIM support.<br />
<br />
Alternatively, [[install]] {{Pkg|hdparm}} package and run:<br />
<br />
{{hc|# hdparm -I /dev/sda {{!}} grep TRIM|<br />
* Data Set Management TRIM supported (limit 1 block)<br />
}}<br />
<br />
{{Note|There are different types of TRIM support defined by the specification. Hence, the output may differ depending what the drive supports. See [[Wikipedia:TRIM#ATA]] for more information.}}<br />
<br />
==== Periodic TRIM ====<br />
<br />
The {{Pkg|util-linux}} package provides {{ic|fstrim.service}} and {{ic|fstrim.timer}} [[systemd]] unit files. [[Enabling]] the timer will activate the service weekly. The service executes {{man|8|fstrim}} on all mounted filesystems on devices that support the ''discard'' operation.<br />
<br />
The timer relies on the timestamp of {{ic|/var/lib/systemd/timers/stamp-fstrim.timer}} (which it will create upon first invocation) to know whether a week has elapsed since it last ran. Therefore there is no need to worry about too frequent invocations, in an ''anacron''-like fashion.<br />
<br />
To query the units activity and status, see [[journalctl]]. To change the periodicity of the timer or the command run, [[edit]] the provided unit files.<br />
<br />
==== Continuous TRIM ====<br />
<br />
{{Note|There is no need to enable continuous TRIM if you run {{ic|fstrim}} periodically. If you want to use TRIM, use either periodic TRIM or continuous TRIM.}}<br />
<br />
Instead of issuing TRIM commands once in a while (by default once a week if using {{ic|fstrim.timer}}), it is also possible to issue TRIM commands each time files are deleted instead. The latter is known as the continuous TRIM.<br />
<br />
{{Warning|Before [[Wikipedia:Serial ATA#SATA revision 3.1|SATA 3.1]] all TRIM commands were non-queued, so continuous trimming would produce frequent system freezes. In this case, applying [[#Periodic TRIM]] less often is better alternative. Similar issue holds also for a [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c#n4522 number of devices], for which queued TRIM command execution was blacklisted due to [https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/ serious data corruption]. In such case, depending on the device, the system may be forced to send non-queued TRIM commands the SSD instead of queued TRIM. See [[Wikipedia:Trim_(computing)#Disadvantages]] for details.}}<br />
<br />
{{Note|Continuous TRIM is not the most preferred way to issue TRIM commands among the Linux community. For example, Ubuntu enables periodic TRIM by default [https://askubuntu.com/questions/1034169/is-trim-enabled-on-my-ubuntu-18-04-installation], Debian does not recommend using continuous TRIM [https://wiki.debian.org/SSDOptimization#Mounting_SSD_filesystems] and Red Hat recommends using periodic TRIM over using continuous TRIM if feasible. [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/ch02s04.html]}}<br />
<br />
Using the {{ic|discard}} option for a mount in {{ic|/etc/fstab}} enables continuous TRIM in device operations:<br />
<br />
/dev/sda1 / ext4 defaults,'''discard''' 0 1<br />
<br />
{{Note|1=Specifying the discard mount option in {{ic|/etc/fstab}} does not work with an XFS {{ic|/}} partition. According to [https://bbs.archlinux.org/viewtopic.php?id=143254 this thread], it has to be set using the {{ic|1=rootflags=discard}} [[kernel parameter]].}}<br />
<br />
On the ext4 filesystem, the {{ic|discard}} flag can also be set as a [[Access_Control_Lists#Enabling_ACL|default mount option]] using ''tune2fs'':<br />
<br />
# tune2fs -o discard /dev/sd'''XY'''<br />
<br />
Using the default mount options instead of an entry in {{ic|/etc/fstab}} is particularly useful for external drives, because such partition will be mounted with the default options also on other machines. This way, there is no need to edit {{ic|/etc/fstab}} on every machine.<br />
<br />
{{Note|The default mount options are not listed in {{ic|/proc/mounts}}.}}<br />
<br />
==== Trim an entire device ====<br />
<br />
If you want to trim your entire SSD at once, e.g. for a new install, or you want to sell your SSD, you can use the blkdiscard command, which will instantly discard all blocks on a device. <br />
<br />
{{Warning|all data on the device will be lost!}}<br />
<br />
# blkdiscard /dev/sd''X''<br />
<br />
==== LVM ====<br />
<br />
Change the value of {{ic|issue_discards}} option from 0 to 1 in {{ic|/etc/lvm/lvm.conf}}.<br />
<br />
{{Note|Enabling this option will "issue discards to a logical volumes's underlying physical volume(s) when the logical volume is no longer using the physical volumes' space (e.g. ''lvremove'', ''lvreduce'', etc)" (see {{man|5|lvm.conf}} and/or inline comments in {{ic|/etc/lvm/lvm.conf}}). As such it does not seem to be required for "regular" TRIM requests (file deletions inside a filesystem) to be functional.}}<br />
<br />
==== dm-crypt ====<br />
<br />
{{Warning|The discard option allows discard requests to be passed through the encrypted block device. This improves performance on SSD storage but has security implications. See [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)]] for more information.}}<br />
<br />
For non-root filesystems, configure {{ic|/etc/crypttab}} to include {{ic|discard}} in the list of options for encrypted block devices located on an SSD (see [[dm-crypt/System configuration#crypttab]]).<br />
<br />
For the root filesystem, follow the instructions from [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)]] to add the right kernel parameter to the bootloader configuration.<br />
<br />
=== Maximizing performance ===<br />
<br />
Follow the tips in [[Improving performance#Storage devices]] to maximize the performance of your drives.<br />
<br />
=== Security ===<br />
<br />
==== Hdparm shows "frozen" state ====<br />
<br />
Some motherboard BIOS' issue a "security freeze" command to attached storage devices on initialization. Likewise some SSD (and HDD) BIOS' are set to "security freeze" in the factory already. Both result in the device's password security settings to be set to '''frozen''', as shown in below output: <br />
<br />
{{hc|head=# hdparm -I /dev/sda |output=<br />
Security: <br />
Master password revision code = 65534<br />
supported<br />
not enabled<br />
'''not locked'''<br />
'''frozen'''<br />
not expired: security count<br />
supported: enhanced erase<br />
4min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.<br />
}}<br />
<br />
Operations like formatting the device or installing operating systems are not affected by the "security freeze". <br />
<br />
The above output shows the device is '''not locked''' by a HDD-password on boot and the '''frozen''' state safeguards the device against malwares which may try to lock it by setting a password to it at runtime. <br />
<br />
If you intend to set a password to a "frozen" device yourself, a motherboard BIOS with support for it is required. A lot of notebooks have support, because it is required for [[Wikipedia:Hardware-based_full_disk_encryption|hardware encryption]], but support may not be trivial for a desktop/server board. For the Intel DH67CL/BL motherboard, for example, the motherboard has to be set to "maintenance mode" by a physical jumper to access the settings (see [https://sstahlman.blogspot.in/2014/07/hardware-fde-with-intel-ssd-330-on.html?showComment=1411193181867#c4579383928221016762], [https://communities.intel.com/message/251978#251978]). <br />
<br />
{{Warning|Do not try to change the above '''lock''' security settings with {{ic|hdparm}} unless you know exactly what you are doing.}}<br />
<br />
If you intend to erase the SSD, see [[Securely wipe disk#hdparm]] and [[#SSD memory cell clearing]] below.<br />
<br />
==== SSD memory cell clearing ====<br />
<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time the device was installed thus restoring it to its [https://www.anandtech.com/show/2738/8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD memory cell clearing]] wiki article. If the reason for the reset is to wipe data, you may not want to rely on the SSD bios to perform it securely. See [[Securely wipe disk#Flash memory]] for further information and examples to perform a wipe.<br />
<br />
==== Hardware encryption ====<br />
<br />
As noted in [[#Hdparm shows "frozen" state]] setting a password for a storage device (SSD/HDD) in the BIOS may also initialize the hardware encryption of devices supporting it. If the device also conforms to the OPAL standard, this may also be achieved without a respective BIOS feature to set the passphrase, see [[Self-Encrypting Drives]].<br />
<br />
== Troubleshooting ==<br />
<br />
It is possible that the issue you are encountering is a firmware bug which is not Linux specific, so before trying to troubleshoot an issue affecting the SSD device, you should first check if updates are available for:<br />
<br />
* The [[#Firmware|SSD's firmware]]<br />
* The [[Flashing_BIOS_from_Linux|motherboard's BIOS/UEFI firmware]]<br />
<br />
Even if it is a firmware bug it might be possible to avoid it, so if there are no updates to the firmware or you hesitant on updating firmware then the following might help.<br />
<br />
=== Resolving NCQ errors ===<br />
<br />
Some SSDs and SATA chipsets do not work properly with Linux Native Command Queueing (NCQ). The tell-tale dmesg errors look like this:<br />
<br />
[ 9.115544] ata9: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x10 frozen<br />
[ 9.115550] ata9.00: failed command: READ FPDMA QUEUED<br />
[ 9.115556] ata9.00: cmd 60/04:00:d4:82:85/00:00:1f:00:00/40 tag 0 ncq 2048 in<br />
[ 9.115557] res 40/00:18:d3:82:85/00:00:1f:00:00/40 Emask 0x4 (timeout)<br />
<br />
To disable NCQ on boot, add {{ic|1=libata.force=noncq}} to the kernel command line in the [[bootloader]] configuration. To disable NCQ only for disk 0 on port 9 use: {{ic|1=libata.force=9.00:noncq}}<br />
<br />
Alternatively, you may disable NCQ for a specific drive without rebooting via sysfs:<br />
<br />
# echo 1 > /sys/block/sdX/device/queue_depth<br />
<br />
If this (and also updating the firmware) does not resolves the problem or cause other issues, then [[Reporting bug guidelines|file a bug report]].<br />
<br />
=== Resolving SATA power management related errors ===<br />
<br />
Some SSDs (e.g. Transcend MTS400) are failing when SATA Active Link Power Management, [[wikipedia:Aggressive Link Power Management|ALPM]], is enabled.<br />
ALPM is disabled by default and enabled by a power saving daemon (e.g. [[TLP]], [[Laptop Mode Tools]]).<br />
<br />
If you are starting to encounter SATA related errors when using such a daemon, you should try to disable ALPM by setting its state to {{ic|max_performance}} for both battery and AC powered profiles.<br />
<br />
=== External SSD with TRIM support ===<br />
<br />
Several USB-SATA Bridge Chips, like VL715, VL716 etc, support TRIM. But {{ic|lsblk --discard}} may return:<br />
<br />
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO<br />
sdX 0 0B 0B 0<br />
<br />
According to https://www.dpreview.com/forums/thread/4302710, in this situation, a [[udev]] rule is needed:<br />
<br />
ACTION=="add|change", ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="61f5", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"<br />
<br />
{{Tip|Vendor and product IDs can be easily found from {{ic|lsusb}}.}}<br />
<br />
== Firmware ==<br />
<br />
=== ADATA ===<br />
<br />
ADATA has a utility available for Linux (i686) on their [http://www.adata.com.tw/index.php?action=ss_main&page=ss_content_driver&lan=en support page]. The link to latest firmware will appear after selecting the model. The latest Linux update utility is packed with firmware and needs to be run as root. One may need to set correct permissions for binary file first.<br />
<br />
=== Crucial ===<br />
<br />
Crucial provides an option for updating the firmware with an ISO image. These images can be found after selecting the product on their [http://www.crucial.com/usa/en/support-ssd SSD support page] and downloading the "Manual Boot File." <br />
<br />
{{Note|ISO images provided by Crucial do not seem to be hybrid. If you will use just the {{ic|dd}} command to copy the image to some device, the [[MBR]] will not be present, making such device unbootable.}}<br />
<br />
Owners of an M4 Crucial model, may check if a firmware upgrade is needed with {{ic|smartctl}}.<br />
<br />
{{hc|$ smartctl --all /dev/sd'''X'''|<br />
==> WARNING: This drive may hang after 5184 hours of power-on time:<br />
http://www.tomshardware.com/news/Crucial-m4-Firmware-BSOD,14544.html<br />
See the following web pages for firmware updates:<br />
http://www.crucial.com/support/firmware.aspx<br />
http://www.micron.com/products/solid-state-storage/client-ssd#software<br />
}}<br />
<br />
Users seeing this warning are advised to backup all sensible data and '''consider upgrading immediately'''. Check [http://www.rojtberg.net/1008/updating-crucial-mx100-firmware-with-ubuntu/ this instructions] to update Crucial MX100 firmware by using the ISO image and Grub.<br />
<br />
=== Intel ===<br />
<br />
Intel has a Linux live system based [https://downloadcenter.intel.com/download/18363 Firmware Update Tool] for operating systems that are not compatible with its [https://downloadcenter.intel.com/download/18455 Intel® Solid-State Drive Toolbox] software.<br />
<br />
=== Kingston ===<br />
<br />
KFU tool is available on the AUR for the Sandforce based drives, {{AUR|kingston_fw_updater}}.<br />
<br />
=== Mushkin ===<br />
<br />
The lesser known Mushkin brand solid state drives also use Sandforce controllers, and have a Linux utility (nearly identical to Kingston's) to update the firmware.<br />
<br />
=== OCZ ===<br />
<br />
OCZ has a [https://www.ocz.com/us/download/clout Command Line Online Update Tool (CLOUT)] available for Linux. The AUR provides {{AUR|ocz-ssd-utility}}, {{AUR|ocztoolbox}} and {{AUR|oczclout}}.<br />
<br />
=== Samsung ===<br />
<br />
Samsung notes that update methods other than using their Magician Software are "not supported", but it is possible. The Magician Software can be used to make a USB drive bootable with the firmware update. Samsung provides pre-made [https://www.samsung.com/semiconductor/minisite/ssd/download/tools.html bootable ISO images] that can be used to update the firmware. Another option is to use Samsung's {{AUR|samsung_magician-consumer-ssd}}, which is available in the AUR. Magician only supports Samsung-branded SSDs; those manufactured by Samsung for OEMs (e.g., Lenovo) are not supported.<br />
<br />
{{Note|Samsung does not make it obvious at all that they actually provide these. They seem to have 4 different firmware update pages, and each references different ways of doing things.}}<br />
<br />
Users preferring to run the firmware update from a live USB created under Linux (without using Samsung's "Magician" software under Microsoft Windows) can refer to [https://web.archive.org/web/20160322230114/fomori.org/blog/?p=933 this post] for reference.<br />
<br />
==== Upgrade under Linux ====<br />
<br />
{{Style|Assumes use of [[udisks]]; loop mounts can be done directly via [[mount]]}}<br />
<br />
Alternatively, the firmware can be upgraded natively, without making a bootable USB stick, as shown below. First visit the [https://www.samsung.com/semiconductor/minisite/ssd/download/tools.html Samsung downloads page] and download the latest firmware for Windows, which is available as a disk image. In the following, {{ic|Samsung_SSD_840_EVO_EXT0DB6Q.iso}} is used as an example file name, adjust it accordingly.<br />
<br />
Setup the disk image:<br />
<br />
$ udisksctl loop-setup -r -f Samsung_SSD_840_EVO_EXT0DB6Q.iso<br />
<br />
This will make the ISO available as a loop device, and display the device path. Assuming it was {{ic|/dev/loop0}}:<br />
<br />
$ udisksctl mount -b /dev/loop0<br />
<br />
Get the contents of the disk:<br />
<br />
$ mkdir Samsung_SSD_840_EVO_EXT0DB6Q<br />
$ cp -r /run/media/$USER/CDROM/isolinux/ Samsung_SSD_840_EVO_EXT0DB6Q<br />
<br />
Unmount the iso:<br />
<br />
$ udisksctl unmount -b /dev/loop0<br />
$ cd Samsung_SSD_840_EVO_EXT0DB6Q/isolinux<br />
<br />
There is a FreeDOS image here that contains the firmware. Mount the image as before:<br />
<br />
$ udisksctl loop-setup -r -f btdsk.img<br />
$ udisksctl mount -b /dev/loop1<br />
$ cp -r /run/media/$USER/C04D-1342/ Samsung_SSD_840_EVO_EXT0DB6Q<br />
$ cd Samsung_SSD_840_EVO_EXT0DB6Q/C04D-1342/samsung<br />
<br />
Get the disk number from magician:<br />
<br />
# magician -L<br />
<br />
Assuming it was 0:<br />
<br />
# magician --disk 0 -F -p DSRD<br />
<br />
Verify that the latest firmware has been installed:<br />
<br />
# magician -L<br />
<br />
Finally reboot.<br />
<br />
=== SanDisk ===<br />
<br />
SanDisk makes ISO firmware images to allow SSD firmware update on operating systems that are unsupported by their SanDisk SSD Toolkit.<br />
<br />
One must choose the firmware for the correct ''SSD model'', '''and''' the correct ''capacity'' that it has (e.g. 60GB, '''or''' 256GB). After burning the ISO firmware image, simply restart the PC to boot with the newly created CD/DVD boot disk (may work from a USB stick).<br />
<br />
The iso images just contain a linux kernel and an initrd. Extract them to {{ic|/boot}} partition and boot them with [[GRUB]] or [[Syslinux]] to update the firmware.<br />
<br />
See also:<br />
<br />
SanDisk Extreme SSD [https://kb.sandisk.com/app/answers/detail/a_id/10127 Firmware Release notes] and [https://kb.sandisk.com/app/answers/detail/a_id/10476 Manual Firmware update version R211] <br />
<br />
SanDisk Ultra SSD [https://kb.sandisk.com/app/answers/detail/a_id/10192 Firmware release notes] and [https://kb.sandisk.com/app/answers/detail/a_id/10477 Manual Firmware update version 365A13F0]<br />
<br />
SanDisk Ultra+ SSD [https://kb.sandisk.com/app/answers/detail/a_id/12763 Firmware release notes] and [https://kb.sandisk.com/app/answers/detail/a_id/12762 Manual Firmware update version X2316RL] - use {{ic|smartctl -a /dev/sdX}} to determine if a "H2" or "HP" model is used.<br />
<br />
== See also ==<br />
<br />
* [https://www.reddit.com/r/archlinux/comments/rkwjm/what_should_i_keep_in_mind_when_installing_on_ssd/ Discussion on Reddit about installing Arch on an SSD]<br />
* [http://permalink.gmane.org/gmane.comp.file-systems.btrfs/19446 Re: Varying Leafsize and Nodesize in Btrfs]<br />
* [http://thread.gmane.org/gmane.comp.file-systems.btrfs/19650/focus=19667 Re: SSD alignment and Btrfs sector size]<br />
* [https://forums.anandtech.com/threads/erase-block-alignment-misinformation.2266113/ Erase Block (Alignment) Misinformation?]<br />
* [https://superuser.com/questions/492084/is-alignment-to-erase-block-size-needed-for-modern-ssds Is alignment to erase block size needed for modern SSD's?]<br />
* [http://thread.gmane.org/gmane.comp.file-systems.btrfs/15646 Btrfs support for efficient SSD operation (data blocks alignment)]<br />
* [https://serverfault.com/questions/356534/ssd-erase-block-size-lvm-pv-on-raw-device-alignment SSD, Erase Block Size & LVM: PV on raw device, Alignment]</div>Crescenthttps://wiki.archlinux.org/index.php?title=Solid_state_drive&diff=576681Solid state drive2019-07-01T06:31:35Z<p>Crescent: /* Western Digital */ typo</p>
<hr />
<div>[[Category:Storage]]<br />
[[it:Solid state drive]]<br />
[[ja:ソリッドステートドライブ]]<br />
[[ru:Solid state drive]]<br />
[[zh-hans:Solid state drive]]<br />
[[zh-hant:Solid state drive]]<br />
{{Related articles start}}<br />
{{Related|Solid state drive/NVMe}}<br />
{{Related|Solid state drive/Memory cell clearing}}<br />
{{Related|Benchmarking/Data storage devices}}<br />
{{Related|Improving performance#Storage devices}}<br />
{{Related|Flashcache}}<br />
{{Related articles end}}<br />
This article covers special topics for operating [[Wikipedia:Solid-state drive|solid state drives]] (SSDs) and other flash-memory based storage devices. If you want to partition an SSD for a specific purpose, it may be useful to consider the [[Wikipedia:List of file systems#File systems optimized for flash memory, solid state media|List of file systems optimized for flash memory]]. For general usage, you should simply choose your preferred [[filesystem]].<br />
<br />
== Usage ==<br />
<br />
=== TRIM ===<br />
<br />
Most SSDs support the [[wikipedia:TRIM|ATA_TRIM command]] for sustained long-term performance and wear-leveling. A [https://www.techspot.com/review/737-ocz-vector-150-ssd/page9.html techspot article] shows performance benchmark examples of before and after filling an SSD with data.<br />
<br />
As of Linux kernel version 3.8 onwards, support for TRIM was continually added for the different [[filesystems]]. See the following table for an indicative overview:<br />
<br />
{| class="wikitable"<br />
! File system !! Continuous TRIM <br> ({{ic|discard}} option) !! Periodic TRIM <br> (''fstrim'') !! References<br> and notes<br />
|-<br />
| [[Ext3]] || {{No}} || {{META Table cell|?}} || <br />
|-<br />
| [[Ext4]] || {{Yes}} || {{Yes}} || [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/ext4.txt?id=5012284700775a4e6e3fbe7eac4c543c4874b559#n342]<br />
|-<br />
| [[Btrfs]] || {{Yes}} || {{Yes}} ||<br />
|-<br />
| [[JFS]] || {{Yes}} || {{Yes}} || [https://www.phoronix.com/scan.php?page=news_item&px=MTE5ODY]<br />
|-<br />
| [[XFS]] || {{Yes}} || {{Yes}} || [http://xfs.org/index.php/FITRIM/discard]<br />
|-<br />
| [[F2FS]] || {{Yes}} || {{Yes}} ||<br />
|-<br />
| [[VFAT]] || {{Yes}} || {{Yes}} || ''fstrim'' is supported since kernel 4.19<br />
|-<br />
| [[NTFS-3G]] || {{No}} || {{Yes}} || since version 2015.3.14, [http://permalink.gmane.org/gmane.comp.file-systems.ntfs-3g.devel/1101]<br />
|}<br />
<br />
{{Warning|Users need to be certain that their SSD supports TRIM before attempting to use it. Data loss can occur otherwise!}}<br />
<br />
To verify TRIM support, run:<br />
<br />
$ lsblk --discard<br />
<br />
And check the values of DISC-GRAN (discard granularity) and DISC-MAX (discard max bytes) columns. Non-zero values indicate TRIM support.<br />
<br />
Alternatively, [[install]] {{Pkg|hdparm}} package and run:<br />
<br />
{{hc|# hdparm -I /dev/sda {{!}} grep TRIM|<br />
* Data Set Management TRIM supported (limit 1 block)<br />
}}<br />
<br />
{{Note|There are different types of TRIM support defined by the specification. Hence, the output may differ depending what the drive supports. See [[Wikipedia:TRIM#ATA]] for more information.}}<br />
<br />
==== Periodic TRIM ====<br />
<br />
The {{Pkg|util-linux}} package provides {{ic|fstrim.service}} and {{ic|fstrim.timer}} [[systemd]] unit files. [[Enabling]] the timer will activate the service weekly. The service executes {{man|8|fstrim}} on all mounted filesystems on devices that support the ''discard'' operation.<br />
<br />
The timer relies on the timestamp of {{ic|/var/lib/systemd/timers/stamp-fstrim.timer}} (which it will create upon first invocation) to know whether a week has elapsed since it last ran. Therefore there is no need to worry about too frequent invocations, in an ''anacron''-like fashion.<br />
<br />
To query the units activity and status, see [[journalctl]]. To change the periodicity of the timer or the command run, [[edit]] the provided unit files.<br />
<br />
==== Continuous TRIM ====<br />
<br />
{{Note|There is no need to enable continuous TRIM if you run {{ic|fstrim}} periodically. If you want to use TRIM, use either periodic TRIM or continuous TRIM.}}<br />
<br />
Instead of issuing TRIM commands once in a while (by default once a week if using {{ic|fstrim.timer}}), it is also possible to issue TRIM commands each time files are deleted instead. The latter is known as the continuous TRIM.<br />
<br />
{{Warning|Before [[Wikipedia:Serial ATA#SATA revision 3.1|SATA 3.1]] all TRIM commands were non-queued, so continuous trimming would produce frequent system freezes. In this case, applying [[#Periodic TRIM]] less often is better alternative. Similar issue holds also for a [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c#n4522 number of devices], for which queued TRIM command execution was blacklisted due to [https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/ serious data corruption]. In such case, depending on the device, the system may be forced to send non-queued TRIM commands the SSD instead of queued TRIM. See [[Wikipedia:Trim_(computing)#Disadvantages]] for details.}}<br />
<br />
{{Note|Continuous TRIM is not the most preferred way to issue TRIM commands among the Linux community. For example, Ubuntu enables periodic TRIM by default [https://askubuntu.com/questions/1034169/is-trim-enabled-on-my-ubuntu-18-04-installation], Debian does not recommend using continuous TRIM [https://wiki.debian.org/SSDOptimization#Mounting_SSD_filesystems] and Red Hat recommends using periodic TRIM over using continuous TRIM if feasible. [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/ch02s04.html]}}<br />
<br />
Using the {{ic|discard}} option for a mount in {{ic|/etc/fstab}} enables continuous TRIM in device operations:<br />
<br />
/dev/sda1 / ext4 defaults,'''discard''' 0 1<br />
<br />
{{Note|1=Specifying the discard mount option in {{ic|/etc/fstab}} does not work with an XFS {{ic|/}} partition. According to [https://bbs.archlinux.org/viewtopic.php?id=143254 this thread], it has to be set using the {{ic|1=rootflags=discard}} [[kernel parameter]].}}<br />
<br />
On the ext4 filesystem, the {{ic|discard}} flag can also be set as a [[Access_Control_Lists#Enabling_ACL|default mount option]] using ''tune2fs'':<br />
<br />
# tune2fs -o discard /dev/sd'''XY'''<br />
<br />
Using the default mount options instead of an entry in {{ic|/etc/fstab}} is particularly useful for external drives, because such partition will be mounted with the default options also on other machines. This way, there is no need to edit {{ic|/etc/fstab}} on every machine.<br />
<br />
{{Note|The default mount options are not listed in {{ic|/proc/mounts}}.}}<br />
<br />
==== Trim an entire device ====<br />
<br />
If you want to trim your entire SSD at once, e.g. for a new install, or you want to sell your SSD, you can use the blkdiscard command, which will instantly discard all blocks on a device. <br />
<br />
{{Warning|all data on the device will be lost!}}<br />
<br />
# blkdiscard /dev/sd''X''<br />
<br />
==== LVM ====<br />
<br />
Change the value of {{ic|issue_discards}} option from 0 to 1 in {{ic|/etc/lvm/lvm.conf}}.<br />
<br />
{{Note|Enabling this option will "issue discards to a logical volumes's underlying physical volume(s) when the logical volume is no longer using the physical volumes' space (e.g. ''lvremove'', ''lvreduce'', etc)" (see {{man|5|lvm.conf}} and/or inline comments in {{ic|/etc/lvm/lvm.conf}}). As such it does not seem to be required for "regular" TRIM requests (file deletions inside a filesystem) to be functional.}}<br />
<br />
==== dm-crypt ====<br />
<br />
{{Warning|The discard option allows discard requests to be passed through the encrypted block device. This improves performance on SSD storage but has security implications. See [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)]] for more information.}}<br />
<br />
For non-root filesystems, configure {{ic|/etc/crypttab}} to include {{ic|discard}} in the list of options for encrypted block devices located on an SSD (see [[dm-crypt/System configuration#crypttab]]).<br />
<br />
For the root filesystem, follow the instructions from [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)]] to add the right kernel parameter to the bootloader configuration.<br />
<br />
=== Maximizing performance ===<br />
<br />
Follow the tips in [[Improving performance#Storage devices]] to maximize the performance of your drives.<br />
<br />
=== Security ===<br />
<br />
==== Hdparm shows "frozen" state ====<br />
<br />
Some motherboard BIOS' issue a "security freeze" command to attached storage devices on initialization. Likewise some SSD (and HDD) BIOS' are set to "security freeze" in the factory already. Both result in the device's password security settings to be set to '''frozen''', as shown in below output: <br />
<br />
{{hc|head=# hdparm -I /dev/sda |output=<br />
Security: <br />
Master password revision code = 65534<br />
supported<br />
not enabled<br />
'''not locked'''<br />
'''frozen'''<br />
not expired: security count<br />
supported: enhanced erase<br />
4min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.<br />
}}<br />
<br />
Operations like formatting the device or installing operating systems are not affected by the "security freeze". <br />
<br />
The above output shows the device is '''not locked''' by a HDD-password on boot and the '''frozen''' state safeguards the device against malwares which may try to lock it by setting a password to it at runtime. <br />
<br />
If you intend to set a password to a "frozen" device yourself, a motherboard BIOS with support for it is required. A lot of notebooks have support, because it is required for [[Wikipedia:Hardware-based_full_disk_encryption|hardware encryption]], but support may not be trivial for a desktop/server board. For the Intel DH67CL/BL motherboard, for example, the motherboard has to be set to "maintenance mode" by a physical jumper to access the settings (see [https://sstahlman.blogspot.in/2014/07/hardware-fde-with-intel-ssd-330-on.html?showComment=1411193181867#c4579383928221016762], [https://communities.intel.com/message/251978#251978]). <br />
<br />
{{Warning|Do not try to change the above '''lock''' security settings with {{ic|hdparm}} unless you know exactly what you are doing.}}<br />
<br />
If you intend to erase the SSD, see [[Securely wipe disk#hdparm]] and [[#SSD memory cell clearing]] below.<br />
<br />
==== SSD memory cell clearing ====<br />
<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time the device was installed thus restoring it to its [https://www.anandtech.com/show/2738/8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD memory cell clearing]] wiki article. If the reason for the reset is to wipe data, you may not want to rely on the SSD bios to perform it securely. See [[Securely wipe disk#Flash memory]] for further information and examples to perform a wipe.<br />
<br />
==== Hardware encryption ====<br />
<br />
As noted in [[#Hdparm shows "frozen" state]] setting a password for a storage device (SSD/HDD) in the BIOS may also initialize the hardware encryption of devices supporting it. If the device also conforms to the OPAL standard, this may also be achieved without a respective BIOS feature to set the passphrase, see [[Self-Encrypting Drives]].<br />
<br />
== Troubleshooting ==<br />
<br />
It is possible that the issue you are encountering is a firmware bug which is not Linux specific, so before trying to troubleshoot an issue affecting the SSD device, you should first check if updates are available for:<br />
<br />
* The [[#Firmware|SSD's firmware]]<br />
* The [[Flashing_BIOS_from_Linux|motherboard's BIOS/UEFI firmware]]<br />
<br />
Even if it is a firmware bug it might be possible to avoid it, so if there are no updates to the firmware or you hesitant on updating firmware then the following might help.<br />
<br />
=== Resolving NCQ errors ===<br />
<br />
Some SSDs and SATA chipsets do not work properly with Linux Native Command Queueing (NCQ). The tell-tale dmesg errors look like this:<br />
<br />
[ 9.115544] ata9: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x10 frozen<br />
[ 9.115550] ata9.00: failed command: READ FPDMA QUEUED<br />
[ 9.115556] ata9.00: cmd 60/04:00:d4:82:85/00:00:1f:00:00/40 tag 0 ncq 2048 in<br />
[ 9.115557] res 40/00:18:d3:82:85/00:00:1f:00:00/40 Emask 0x4 (timeout)<br />
<br />
To disable NCQ on boot, add {{ic|1=libata.force=noncq}} to the kernel command line in the [[bootloader]] configuration. To disable NCQ only for disk 0 on port 9 use: {{ic|1=libata.force=9.00:noncq}}<br />
<br />
Alternatively, you may disable NCQ for a specific drive without rebooting via sysfs:<br />
<br />
# echo 1 > /sys/block/sdX/device/queue_depth<br />
<br />
If this (and also updating the firmware) does not resolves the problem or cause other issues, then [[Reporting bug guidelines|file a bug report]].<br />
<br />
=== Resolving SATA power management related errors ===<br />
<br />
Some SSDs (e.g. Transcend MTS400) are failing when SATA Active Link Power Management, [[wikipedia:Aggressive Link Power Management|ALPM]], is enabled.<br />
ALPM is disabled by default and enabled by a power saving daemon (e.g. [[TLP]], [[Laptop Mode Tools]]).<br />
<br />
If you are starting to encounter SATA related errors when using such a daemon, you should try to disable ALPM by setting its state to {{ic|max_performance}} for both battery and AC powered profiles.<br />
<br />
== Firmware ==<br />
<br />
=== ADATA ===<br />
<br />
ADATA has a utility available for Linux (i686) on their [http://www.adata.com.tw/index.php?action=ss_main&page=ss_content_driver&lan=en support page]. The link to latest firmware will appear after selecting the model. The latest Linux update utility is packed with firmware and needs to be run as root. One may need to set correct permissions for binary file first.<br />
<br />
=== Crucial ===<br />
<br />
Crucial provides an option for updating the firmware with an ISO image. These images can be found after selecting the product on their [http://www.crucial.com/usa/en/support-ssd SSD support page] and downloading the "Manual Boot File." <br />
<br />
{{Note|ISO images provided by Crucial do not seem to be hybrid. If you will use just the {{ic|dd}} command to copy the image to some device, the [[MBR]] will not be present, making such device unbootable.}}<br />
<br />
Owners of an M4 Crucial model, may check if a firmware upgrade is needed with {{ic|smartctl}}.<br />
<br />
{{hc|$ smartctl --all /dev/sd'''X'''|<br />
==> WARNING: This drive may hang after 5184 hours of power-on time:<br />
http://www.tomshardware.com/news/Crucial-m4-Firmware-BSOD,14544.html<br />
See the following web pages for firmware updates:<br />
http://www.crucial.com/support/firmware.aspx<br />
http://www.micron.com/products/solid-state-storage/client-ssd#software<br />
}}<br />
<br />
Users seeing this warning are advised to backup all sensible data and '''consider upgrading immediately'''. Check [http://www.rojtberg.net/1008/updating-crucial-mx100-firmware-with-ubuntu/ this instructions] to update Crucial MX100 firmware by using the ISO image and Grub.<br />
<br />
=== Intel ===<br />
<br />
Intel has a Linux live system based [https://downloadcenter.intel.com/download/18363 Firmware Update Tool] for operating systems that are not compatible with its [https://downloadcenter.intel.com/download/18455 Intel® Solid-State Drive Toolbox] software.<br />
<br />
=== Kingston ===<br />
<br />
KFU tool is available on the AUR for the Sandforce based drives, {{AUR|kingston_fw_updater}}.<br />
<br />
=== Mushkin ===<br />
<br />
The lesser known Mushkin brand solid state drives also use Sandforce controllers, and have a Linux utility (nearly identical to Kingston's) to update the firmware.<br />
<br />
=== OCZ ===<br />
<br />
OCZ has a [https://www.ocz.com/us/download/clout Command Line Online Update Tool (CLOUT)] available for Linux. The AUR provides {{AUR|ocz-ssd-utility}}, {{AUR|ocztoolbox}} and {{AUR|oczclout}}.<br />
<br />
=== Samsung ===<br />
<br />
Samsung notes that update methods other than using their Magician Software are "not supported," but it is possible. The Magician Software can be used to make a USB drive bootable with the firmware update. Samsung provides pre-made [https://www.samsung.com/semiconductor/minisite/ssd/download/tools.html bootable ISO images] that can be used to update the firmware. Another option is to use Samsung's {{AUR|samsung_magician-consumer-ssd}}, which is available in the AUR. Magician only supports Samsung-branded SSDs; those manufactured by Samsung for OEMs (e.g., Lenovo) are not supported.<br />
<br />
{{Note|Samsung does not make it obvious at all that they actually provide these. They seem to have 4 different firmware update pages, and each references different ways of doing things.}}<br />
<br />
Users preferring to run the firmware update from a live USB created under Linux (without using Samsung's "Magician" software under Microsoft Windows) can refer to [http://fomori.org/blog/?p=933 this post] for reference.<br />
<br />
==== Native upgrade ====<br />
<br />
{{Style|Assumes use of [[udisks]]; loop mounts can be done directly via [[mount]]}}<br />
<br />
Alternatively, the firmware can be upgraded natively, without making a bootable USB stick, as shown below.<br />
<br />
First visit the [https://www.samsung.com/semiconductor/minisite/ssd/download/tools.html Samsung downloads page] and download the latest firmware for Windows, which is available as a disk image. In the following, {{ic|Samsung_SSD_840_EVO_EXT0DB6Q.iso}} is used as an example file name, adjust it accordingly.<br />
<br />
Setup the disk image:<br />
<br />
$ udisksctl loop-setup -r -f Samsung_SSD_840_EVO_EXT0DB6Q.iso<br />
<br />
This will make the ISO available as a loop device, and display the device path. Assuming it was {{ic|/dev/loop0}}:<br />
<br />
$ udisksctl mount -b /dev/loop0<br />
<br />
Get the contents of the disk:<br />
<br />
$ mkdir Samsung_SSD_840_EVO_EXT0DB6Q<br />
$ cp -r /run/media/$USER/CDROM/isolinux/ Samsung_SSD_840_EVO_EXT0DB6Q<br />
<br />
Unmount the iso:<br />
<br />
$ udisksctl unmount -b /dev/loop0<br />
$ cd Samsung_SSD_840_EVO_EXT0DB6Q/isolinux<br />
<br />
There is a FreeDOS image here that contains the firmware. Mount the image as before:<br />
<br />
$ udisksctl loop-setup -r -f btdsk.img<br />
$ udisksctl mount -b /dev/loop1<br />
$ cp -r /run/media/$USER/C04D-1342/ Samsung_SSD_840_EVO_EXT0DB6Q<br />
$ cd Samsung_SSD_840_EVO_EXT0DB6Q/C04D-1342/samsung<br />
<br />
Get the disk number from magician:<br />
<br />
# magician -L<br />
<br />
Assuming it was 0:<br />
<br />
# magician --disk 0 -F -p DSRD<br />
<br />
Verify that the latest firmware has been installed:<br />
<br />
# magician -L<br />
<br />
Finally reboot.<br />
<br />
=== SanDisk ===<br />
<br />
SanDisk makes ISO firmware images to allow SSD firmware update on operating systems that are unsupported by their SanDisk SSD Toolkit.<br />
<br />
One must choose the firmware for the correct ''SSD model'', '''and''' the correct ''capacity'' that it has (e.g. 60GB, '''or''' 256GB). After burning the ISO firmware image, simply restart the PC to boot with the newly created CD/DVD boot disk (may work from a USB stick).<br />
<br />
The iso images just contain a linux kernel and an initrd. Extract them to {{ic|/boot}} partition and boot them with [[GRUB]] or [[Syslinux]] to update the firmware.<br />
<br />
See also:<br />
<br />
SanDisk Extreme SSD [https://kb.sandisk.com/app/answers/detail/a_id/10127 Firmware Release notes] and [https://kb.sandisk.com/app/answers/detail/a_id/10476 Manual Firmware update version R211] <br />
<br />
SanDisk Ultra SSD [https://kb.sandisk.com/app/answers/detail/a_id/10192 Firmware release notes] and [https://kb.sandisk.com/app/answers/detail/a_id/10477 Manual Firmware update version 365A13F0]<br />
<br />
SanDisk Ultra+ SSD [https://kb.sandisk.com/app/answers/detail/a_id/12763 Firmware release notes] and [https://kb.sandisk.com/app/answers/detail/a_id/12762 Manual Firmware update version X2316RL] - use {{ic|smartctl -a /dev/sdX}} to determine if a "H2" or "HP" model is used.<br />
<br />
=== Western Digital ===<br />
<br />
Western Digital drives have issues that may cause the system to freeze when read from. See [https://askubuntu.com/questions/1051205/wd-black-nvme-ssd-2018-is-not-working-under-linux-ubuntu askubuntu]. This may have something to do with low power state latencies, and some people have been able to resolve it by adding nvme_core.default_ps_max_latency_us=52000 to grub. However, the other people have reported that the parameter has not worked. Also note that Western Digital only supplies firmware updates via its Windows software that does not run in wine.<br />
<br />
== See also ==<br />
<br />
* [https://www.reddit.com/r/archlinux/comments/rkwjm/what_should_i_keep_in_mind_when_installing_on_ssd/ Discussion on Reddit about installing Arch on an SSD]<br />
* [http://permalink.gmane.org/gmane.comp.file-systems.btrfs/19446 Re: Varying Leafsize and Nodesize in Btrfs]<br />
* [http://thread.gmane.org/gmane.comp.file-systems.btrfs/19650/focus=19667 Re: SSD alignment and Btrfs sector size]<br />
* [https://forums.anandtech.com/threads/erase-block-alignment-misinformation.2266113/ Erase Block (Alignment) Misinformation?]<br />
* [https://superuser.com/questions/492084/is-alignment-to-erase-block-size-needed-for-modern-ssds Is alignment to erase block size needed for modern SSD's?]<br />
* [http://thread.gmane.org/gmane.comp.file-systems.btrfs/15646 Btrfs support for efficient SSD operation (data blocks alignment)]<br />
* [https://serverfault.com/questions/356534/ssd-erase-block-size-lvm-pv-on-raw-device-alignment SSD, Erase Block Size & LVM: PV on raw device, Alignment]</div>Crescenthttps://wiki.archlinux.org/index.php?title=Solid_state_drive&diff=576680Solid state drive2019-07-01T06:30:43Z<p>Crescent: Add note on WD drive issues in linux</p>
<hr />
<div>[[Category:Storage]]<br />
[[it:Solid state drive]]<br />
[[ja:ソリッドステートドライブ]]<br />
[[ru:Solid state drive]]<br />
[[zh-hans:Solid state drive]]<br />
[[zh-hant:Solid state drive]]<br />
{{Related articles start}}<br />
{{Related|Solid state drive/NVMe}}<br />
{{Related|Solid state drive/Memory cell clearing}}<br />
{{Related|Benchmarking/Data storage devices}}<br />
{{Related|Improving performance#Storage devices}}<br />
{{Related|Flashcache}}<br />
{{Related articles end}}<br />
This article covers special topics for operating [[Wikipedia:Solid-state drive|solid state drives]] (SSDs) and other flash-memory based storage devices. If you want to partition an SSD for a specific purpose, it may be useful to consider the [[Wikipedia:List of file systems#File systems optimized for flash memory, solid state media|List of file systems optimized for flash memory]]. For general usage, you should simply choose your preferred [[filesystem]].<br />
<br />
== Usage ==<br />
<br />
=== TRIM ===<br />
<br />
Most SSDs support the [[wikipedia:TRIM|ATA_TRIM command]] for sustained long-term performance and wear-leveling. A [https://www.techspot.com/review/737-ocz-vector-150-ssd/page9.html techspot article] shows performance benchmark examples of before and after filling an SSD with data.<br />
<br />
As of Linux kernel version 3.8 onwards, support for TRIM was continually added for the different [[filesystems]]. See the following table for an indicative overview:<br />
<br />
{| class="wikitable"<br />
! File system !! Continuous TRIM <br> ({{ic|discard}} option) !! Periodic TRIM <br> (''fstrim'') !! References<br> and notes<br />
|-<br />
| [[Ext3]] || {{No}} || {{META Table cell|?}} || <br />
|-<br />
| [[Ext4]] || {{Yes}} || {{Yes}} || [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/ext4.txt?id=5012284700775a4e6e3fbe7eac4c543c4874b559#n342]<br />
|-<br />
| [[Btrfs]] || {{Yes}} || {{Yes}} ||<br />
|-<br />
| [[JFS]] || {{Yes}} || {{Yes}} || [https://www.phoronix.com/scan.php?page=news_item&px=MTE5ODY]<br />
|-<br />
| [[XFS]] || {{Yes}} || {{Yes}} || [http://xfs.org/index.php/FITRIM/discard]<br />
|-<br />
| [[F2FS]] || {{Yes}} || {{Yes}} ||<br />
|-<br />
| [[VFAT]] || {{Yes}} || {{Yes}} || ''fstrim'' is supported since kernel 4.19<br />
|-<br />
| [[NTFS-3G]] || {{No}} || {{Yes}} || since version 2015.3.14, [http://permalink.gmane.org/gmane.comp.file-systems.ntfs-3g.devel/1101]<br />
|}<br />
<br />
{{Warning|Users need to be certain that their SSD supports TRIM before attempting to use it. Data loss can occur otherwise!}}<br />
<br />
To verify TRIM support, run:<br />
<br />
$ lsblk --discard<br />
<br />
And check the values of DISC-GRAN (discard granularity) and DISC-MAX (discard max bytes) columns. Non-zero values indicate TRIM support.<br />
<br />
Alternatively, [[install]] {{Pkg|hdparm}} package and run:<br />
<br />
{{hc|# hdparm -I /dev/sda {{!}} grep TRIM|<br />
* Data Set Management TRIM supported (limit 1 block)<br />
}}<br />
<br />
{{Note|There are different types of TRIM support defined by the specification. Hence, the output may differ depending what the drive supports. See [[Wikipedia:TRIM#ATA]] for more information.}}<br />
<br />
==== Periodic TRIM ====<br />
<br />
The {{Pkg|util-linux}} package provides {{ic|fstrim.service}} and {{ic|fstrim.timer}} [[systemd]] unit files. [[Enabling]] the timer will activate the service weekly. The service executes {{man|8|fstrim}} on all mounted filesystems on devices that support the ''discard'' operation.<br />
<br />
The timer relies on the timestamp of {{ic|/var/lib/systemd/timers/stamp-fstrim.timer}} (which it will create upon first invocation) to know whether a week has elapsed since it last ran. Therefore there is no need to worry about too frequent invocations, in an ''anacron''-like fashion.<br />
<br />
To query the units activity and status, see [[journalctl]]. To change the periodicity of the timer or the command run, [[edit]] the provided unit files.<br />
<br />
==== Continuous TRIM ====<br />
<br />
{{Note|There is no need to enable continuous TRIM if you run {{ic|fstrim}} periodically. If you want to use TRIM, use either periodic TRIM or continuous TRIM.}}<br />
<br />
Instead of issuing TRIM commands once in a while (by default once a week if using {{ic|fstrim.timer}}), it is also possible to issue TRIM commands each time files are deleted instead. The latter is known as the continuous TRIM.<br />
<br />
{{Warning|Before [[Wikipedia:Serial ATA#SATA revision 3.1|SATA 3.1]] all TRIM commands were non-queued, so continuous trimming would produce frequent system freezes. In this case, applying [[#Periodic TRIM]] less often is better alternative. Similar issue holds also for a [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c#n4522 number of devices], for which queued TRIM command execution was blacklisted due to [https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/ serious data corruption]. In such case, depending on the device, the system may be forced to send non-queued TRIM commands the SSD instead of queued TRIM. See [[Wikipedia:Trim_(computing)#Disadvantages]] for details.}}<br />
<br />
{{Note|Continuous TRIM is not the most preferred way to issue TRIM commands among the Linux community. For example, Ubuntu enables periodic TRIM by default [https://askubuntu.com/questions/1034169/is-trim-enabled-on-my-ubuntu-18-04-installation], Debian does not recommend using continuous TRIM [https://wiki.debian.org/SSDOptimization#Mounting_SSD_filesystems] and Red Hat recommends using periodic TRIM over using continuous TRIM if feasible. [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/ch02s04.html]}}<br />
<br />
Using the {{ic|discard}} option for a mount in {{ic|/etc/fstab}} enables continuous TRIM in device operations:<br />
<br />
/dev/sda1 / ext4 defaults,'''discard''' 0 1<br />
<br />
{{Note|1=Specifying the discard mount option in {{ic|/etc/fstab}} does not work with an XFS {{ic|/}} partition. According to [https://bbs.archlinux.org/viewtopic.php?id=143254 this thread], it has to be set using the {{ic|1=rootflags=discard}} [[kernel parameter]].}}<br />
<br />
On the ext4 filesystem, the {{ic|discard}} flag can also be set as a [[Access_Control_Lists#Enabling_ACL|default mount option]] using ''tune2fs'':<br />
<br />
# tune2fs -o discard /dev/sd'''XY'''<br />
<br />
Using the default mount options instead of an entry in {{ic|/etc/fstab}} is particularly useful for external drives, because such partition will be mounted with the default options also on other machines. This way, there is no need to edit {{ic|/etc/fstab}} on every machine.<br />
<br />
{{Note|The default mount options are not listed in {{ic|/proc/mounts}}.}}<br />
<br />
==== Trim an entire device ====<br />
<br />
If you want to trim your entire SSD at once, e.g. for a new install, or you want to sell your SSD, you can use the blkdiscard command, which will instantly discard all blocks on a device. <br />
<br />
{{Warning|all data on the device will be lost!}}<br />
<br />
# blkdiscard /dev/sd''X''<br />
<br />
==== LVM ====<br />
<br />
Change the value of {{ic|issue_discards}} option from 0 to 1 in {{ic|/etc/lvm/lvm.conf}}.<br />
<br />
{{Note|Enabling this option will "issue discards to a logical volumes's underlying physical volume(s) when the logical volume is no longer using the physical volumes' space (e.g. ''lvremove'', ''lvreduce'', etc)" (see {{man|5|lvm.conf}} and/or inline comments in {{ic|/etc/lvm/lvm.conf}}). As such it does not seem to be required for "regular" TRIM requests (file deletions inside a filesystem) to be functional.}}<br />
<br />
==== dm-crypt ====<br />
<br />
{{Warning|The discard option allows discard requests to be passed through the encrypted block device. This improves performance on SSD storage but has security implications. See [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)]] for more information.}}<br />
<br />
For non-root filesystems, configure {{ic|/etc/crypttab}} to include {{ic|discard}} in the list of options for encrypted block devices located on an SSD (see [[dm-crypt/System configuration#crypttab]]).<br />
<br />
For the root filesystem, follow the instructions from [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)]] to add the right kernel parameter to the bootloader configuration.<br />
<br />
=== Maximizing performance ===<br />
<br />
Follow the tips in [[Improving performance#Storage devices]] to maximize the performance of your drives.<br />
<br />
=== Security ===<br />
<br />
==== Hdparm shows "frozen" state ====<br />
<br />
Some motherboard BIOS' issue a "security freeze" command to attached storage devices on initialization. Likewise some SSD (and HDD) BIOS' are set to "security freeze" in the factory already. Both result in the device's password security settings to be set to '''frozen''', as shown in below output: <br />
<br />
{{hc|head=# hdparm -I /dev/sda |output=<br />
Security: <br />
Master password revision code = 65534<br />
supported<br />
not enabled<br />
'''not locked'''<br />
'''frozen'''<br />
not expired: security count<br />
supported: enhanced erase<br />
4min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.<br />
}}<br />
<br />
Operations like formatting the device or installing operating systems are not affected by the "security freeze". <br />
<br />
The above output shows the device is '''not locked''' by a HDD-password on boot and the '''frozen''' state safeguards the device against malwares which may try to lock it by setting a password to it at runtime. <br />
<br />
If you intend to set a password to a "frozen" device yourself, a motherboard BIOS with support for it is required. A lot of notebooks have support, because it is required for [[Wikipedia:Hardware-based_full_disk_encryption|hardware encryption]], but support may not be trivial for a desktop/server board. For the Intel DH67CL/BL motherboard, for example, the motherboard has to be set to "maintenance mode" by a physical jumper to access the settings (see [https://sstahlman.blogspot.in/2014/07/hardware-fde-with-intel-ssd-330-on.html?showComment=1411193181867#c4579383928221016762], [https://communities.intel.com/message/251978#251978]). <br />
<br />
{{Warning|Do not try to change the above '''lock''' security settings with {{ic|hdparm}} unless you know exactly what you are doing.}}<br />
<br />
If you intend to erase the SSD, see [[Securely wipe disk#hdparm]] and [[#SSD memory cell clearing]] below.<br />
<br />
==== SSD memory cell clearing ====<br />
<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time the device was installed thus restoring it to its [https://www.anandtech.com/show/2738/8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD memory cell clearing]] wiki article. If the reason for the reset is to wipe data, you may not want to rely on the SSD bios to perform it securely. See [[Securely wipe disk#Flash memory]] for further information and examples to perform a wipe.<br />
<br />
==== Hardware encryption ====<br />
<br />
As noted in [[#Hdparm shows "frozen" state]] setting a password for a storage device (SSD/HDD) in the BIOS may also initialize the hardware encryption of devices supporting it. If the device also conforms to the OPAL standard, this may also be achieved without a respective BIOS feature to set the passphrase, see [[Self-Encrypting Drives]].<br />
<br />
== Troubleshooting ==<br />
<br />
It is possible that the issue you are encountering is a firmware bug which is not Linux specific, so before trying to troubleshoot an issue affecting the SSD device, you should first check if updates are available for:<br />
<br />
* The [[#Firmware|SSD's firmware]]<br />
* The [[Flashing_BIOS_from_Linux|motherboard's BIOS/UEFI firmware]]<br />
<br />
Even if it is a firmware bug it might be possible to avoid it, so if there are no updates to the firmware or you hesitant on updating firmware then the following might help.<br />
<br />
=== Resolving NCQ errors ===<br />
<br />
Some SSDs and SATA chipsets do not work properly with Linux Native Command Queueing (NCQ). The tell-tale dmesg errors look like this:<br />
<br />
[ 9.115544] ata9: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x10 frozen<br />
[ 9.115550] ata9.00: failed command: READ FPDMA QUEUED<br />
[ 9.115556] ata9.00: cmd 60/04:00:d4:82:85/00:00:1f:00:00/40 tag 0 ncq 2048 in<br />
[ 9.115557] res 40/00:18:d3:82:85/00:00:1f:00:00/40 Emask 0x4 (timeout)<br />
<br />
To disable NCQ on boot, add {{ic|1=libata.force=noncq}} to the kernel command line in the [[bootloader]] configuration. To disable NCQ only for disk 0 on port 9 use: {{ic|1=libata.force=9.00:noncq}}<br />
<br />
Alternatively, you may disable NCQ for a specific drive without rebooting via sysfs:<br />
<br />
# echo 1 > /sys/block/sdX/device/queue_depth<br />
<br />
If this (and also updating the firmware) does not resolves the problem or cause other issues, then [[Reporting bug guidelines|file a bug report]].<br />
<br />
=== Resolving SATA power management related errors ===<br />
<br />
Some SSDs (e.g. Transcend MTS400) are failing when SATA Active Link Power Management, [[wikipedia:Aggressive Link Power Management|ALPM]], is enabled.<br />
ALPM is disabled by default and enabled by a power saving daemon (e.g. [[TLP]], [[Laptop Mode Tools]]).<br />
<br />
If you are starting to encounter SATA related errors when using such a daemon, you should try to disable ALPM by setting its state to {{ic|max_performance}} for both battery and AC powered profiles.<br />
<br />
== Firmware ==<br />
<br />
=== ADATA ===<br />
<br />
ADATA has a utility available for Linux (i686) on their [http://www.adata.com.tw/index.php?action=ss_main&page=ss_content_driver&lan=en support page]. The link to latest firmware will appear after selecting the model. The latest Linux update utility is packed with firmware and needs to be run as root. One may need to set correct permissions for binary file first.<br />
<br />
=== Crucial ===<br />
<br />
Crucial provides an option for updating the firmware with an ISO image. These images can be found after selecting the product on their [http://www.crucial.com/usa/en/support-ssd SSD support page] and downloading the "Manual Boot File." <br />
<br />
{{Note|ISO images provided by Crucial do not seem to be hybrid. If you will use just the {{ic|dd}} command to copy the image to some device, the [[MBR]] will not be present, making such device unbootable.}}<br />
<br />
Owners of an M4 Crucial model, may check if a firmware upgrade is needed with {{ic|smartctl}}.<br />
<br />
{{hc|$ smartctl --all /dev/sd'''X'''|<br />
==> WARNING: This drive may hang after 5184 hours of power-on time:<br />
http://www.tomshardware.com/news/Crucial-m4-Firmware-BSOD,14544.html<br />
See the following web pages for firmware updates:<br />
http://www.crucial.com/support/firmware.aspx<br />
http://www.micron.com/products/solid-state-storage/client-ssd#software<br />
}}<br />
<br />
Users seeing this warning are advised to backup all sensible data and '''consider upgrading immediately'''. Check [http://www.rojtberg.net/1008/updating-crucial-mx100-firmware-with-ubuntu/ this instructions] to update Crucial MX100 firmware by using the ISO image and Grub.<br />
<br />
=== Intel ===<br />
<br />
Intel has a Linux live system based [https://downloadcenter.intel.com/download/18363 Firmware Update Tool] for operating systems that are not compatible with its [https://downloadcenter.intel.com/download/18455 Intel® Solid-State Drive Toolbox] software.<br />
<br />
=== Kingston ===<br />
<br />
KFU tool is available on the AUR for the Sandforce based drives, {{AUR|kingston_fw_updater}}.<br />
<br />
=== Mushkin ===<br />
<br />
The lesser known Mushkin brand solid state drives also use Sandforce controllers, and have a Linux utility (nearly identical to Kingston's) to update the firmware.<br />
<br />
=== OCZ ===<br />
<br />
OCZ has a [https://www.ocz.com/us/download/clout Command Line Online Update Tool (CLOUT)] available for Linux. The AUR provides {{AUR|ocz-ssd-utility}}, {{AUR|ocztoolbox}} and {{AUR|oczclout}}.<br />
<br />
=== Samsung ===<br />
<br />
Samsung notes that update methods other than using their Magician Software are "not supported," but it is possible. The Magician Software can be used to make a USB drive bootable with the firmware update. Samsung provides pre-made [https://www.samsung.com/semiconductor/minisite/ssd/download/tools.html bootable ISO images] that can be used to update the firmware. Another option is to use Samsung's {{AUR|samsung_magician-consumer-ssd}}, which is available in the AUR. Magician only supports Samsung-branded SSDs; those manufactured by Samsung for OEMs (e.g., Lenovo) are not supported.<br />
<br />
{{Note|Samsung does not make it obvious at all that they actually provide these. They seem to have 4 different firmware update pages, and each references different ways of doing things.}}<br />
<br />
Users preferring to run the firmware update from a live USB created under Linux (without using Samsung's "Magician" software under Microsoft Windows) can refer to [http://fomori.org/blog/?p=933 this post] for reference.<br />
<br />
==== Native upgrade ====<br />
<br />
{{Style|Assumes use of [[udisks]]; loop mounts can be done directly via [[mount]]}}<br />
<br />
Alternatively, the firmware can be upgraded natively, without making a bootable USB stick, as shown below.<br />
<br />
First visit the [https://www.samsung.com/semiconductor/minisite/ssd/download/tools.html Samsung downloads page] and download the latest firmware for Windows, which is available as a disk image. In the following, {{ic|Samsung_SSD_840_EVO_EXT0DB6Q.iso}} is used as an example file name, adjust it accordingly.<br />
<br />
Setup the disk image:<br />
<br />
$ udisksctl loop-setup -r -f Samsung_SSD_840_EVO_EXT0DB6Q.iso<br />
<br />
This will make the ISO available as a loop device, and display the device path. Assuming it was {{ic|/dev/loop0}}:<br />
<br />
$ udisksctl mount -b /dev/loop0<br />
<br />
Get the contents of the disk:<br />
<br />
$ mkdir Samsung_SSD_840_EVO_EXT0DB6Q<br />
$ cp -r /run/media/$USER/CDROM/isolinux/ Samsung_SSD_840_EVO_EXT0DB6Q<br />
<br />
Unmount the iso:<br />
<br />
$ udisksctl unmount -b /dev/loop0<br />
$ cd Samsung_SSD_840_EVO_EXT0DB6Q/isolinux<br />
<br />
There is a FreeDOS image here that contains the firmware. Mount the image as before:<br />
<br />
$ udisksctl loop-setup -r -f btdsk.img<br />
$ udisksctl mount -b /dev/loop1<br />
$ cp -r /run/media/$USER/C04D-1342/ Samsung_SSD_840_EVO_EXT0DB6Q<br />
$ cd Samsung_SSD_840_EVO_EXT0DB6Q/C04D-1342/samsung<br />
<br />
Get the disk number from magician:<br />
<br />
# magician -L<br />
<br />
Assuming it was 0:<br />
<br />
# magician --disk 0 -F -p DSRD<br />
<br />
Verify that the latest firmware has been installed:<br />
<br />
# magician -L<br />
<br />
Finally reboot.<br />
<br />
=== SanDisk ===<br />
<br />
SanDisk makes ISO firmware images to allow SSD firmware update on operating systems that are unsupported by their SanDisk SSD Toolkit.<br />
<br />
One must choose the firmware for the correct ''SSD model'', '''and''' the correct ''capacity'' that it has (e.g. 60GB, '''or''' 256GB). After burning the ISO firmware image, simply restart the PC to boot with the newly created CD/DVD boot disk (may work from a USB stick).<br />
<br />
The iso images just contain a linux kernel and an initrd. Extract them to {{ic|/boot}} partition and boot them with [[GRUB]] or [[Syslinux]] to update the firmware.<br />
<br />
See also:<br />
<br />
SanDisk Extreme SSD [https://kb.sandisk.com/app/answers/detail/a_id/10127 Firmware Release notes] and [https://kb.sandisk.com/app/answers/detail/a_id/10476 Manual Firmware update version R211] <br />
<br />
SanDisk Ultra SSD [https://kb.sandisk.com/app/answers/detail/a_id/10192 Firmware release notes] and [https://kb.sandisk.com/app/answers/detail/a_id/10477 Manual Firmware update version 365A13F0]<br />
<br />
SanDisk Ultra+ SSD [https://kb.sandisk.com/app/answers/detail/a_id/12763 Firmware release notes] and [https://kb.sandisk.com/app/answers/detail/a_id/12762 Manual Firmware update version X2316RL] - use {{ic|smartctl -a /dev/sdX}} to determine if a "H2" or "HP" model is used.<br />
<br />
=== Western Digital ===<br />
<br />
Western Digital drives have issues that may cause the system to freeze when read from. See [https://askubuntu.com/questions/1051205/wd-black-nvme-ssd-2018-is-not-working-under-linux-ubuntu askubuntu]. This may have something to do with low power state latencies, and some people have been able to resolve it by adding nvme_core.default_ps_max_latency_us=52000 to grub. However, the other people have reported that the parameter has not worked. Also to note that Western Digital only supplies firmware updates via its Windows software that does not run in wine.<br />
<br />
== See also ==<br />
<br />
* [https://www.reddit.com/r/archlinux/comments/rkwjm/what_should_i_keep_in_mind_when_installing_on_ssd/ Discussion on Reddit about installing Arch on an SSD]<br />
* [http://permalink.gmane.org/gmane.comp.file-systems.btrfs/19446 Re: Varying Leafsize and Nodesize in Btrfs]<br />
* [http://thread.gmane.org/gmane.comp.file-systems.btrfs/19650/focus=19667 Re: SSD alignment and Btrfs sector size]<br />
* [https://forums.anandtech.com/threads/erase-block-alignment-misinformation.2266113/ Erase Block (Alignment) Misinformation?]<br />
* [https://superuser.com/questions/492084/is-alignment-to-erase-block-size-needed-for-modern-ssds Is alignment to erase block size needed for modern SSD's?]<br />
* [http://thread.gmane.org/gmane.comp.file-systems.btrfs/15646 Btrfs support for efficient SSD operation (data blocks alignment)]<br />
* [https://serverfault.com/questions/356534/ssd-erase-block-size-lvm-pv-on-raw-device-alignment SSD, Erase Block Size & LVM: PV on raw device, Alignment]</div>Crescenthttps://wiki.archlinux.org/index.php?title=Chrome_OS_devices/Crostini&diff=576246Chrome OS devices/Crostini2019-06-23T16:50:05Z<p>Crescent: remove period</p>
<hr />
<div>[[Category:Laptops]]<br />
[[ja:Crostini]]<br />
[https://chromium.googlesource.com/chromiumos/docs/+/master/containers_and_vms.md Crostini] is Google's umbrella term for making Linux application support easy to use and integrating well with Chrome OS.<br />
<br />
This article describes how to install Arch Linux on a Chromebook in a container (via Crostini), without needing to enable developer mode, allowing apps to run alongside other Chrome/Android apps.<br />
<br />
Highlights:<br />
* Officially supported, don't need to enable developer mode - leaves ChromeOS secure, no need to flash a BIOS etc.<br />
* Better battery life - Battery life of Chrome with the functionality of Linux.<br />
* Access to Android apps, play store etc.<br />
* Audio & OpenGL are supported, but microphone and USB devices are still in progress.<br />
<br />
== Introduction ==<br />
<br />
=== Enabling Linux support ===<br />
<br />
Look for Linux under Settings and enable it. This installs a Debian Linux container that we will then replace with an Arch Linux container.<br />
<br />
:''Settings > Linux > Enable''<br />
<br />
Crostini is still rolling out to Chromebooks. If you don't see an option to enable Linux, you may need to switch to the beta or developer channel, if it has not rolled out to the stable channel for your laptop yet. This can be done via ''Settings > About Chrome OS > Channel > Dev/Beta''.<br />
<br />
=== Replacing the default Debian Linux container with Arch Linux ===<br />
<br />
The below instructions were taken from https://www.reddit.com/r/Crostini/wiki/howto/run-arch-linux<br />
<br />
1. Install an Arch linux container <br />
<br />
Open a new terminal in Chrome (Ctrl + Alt + T). Then connect to terminal and create an arch linux container:<br />
<br />
vsh termina<br />
run_container.sh --container_name arch --user <gmail username> --lxd_image archlinux/current --lxd_remote https://us.images.linuxcontainers.org/<br />
<br />
The <gmail username> here is the same user you are logged in to your Chromebooks as, without the @gmail.com and dots. eg. foo.bar@gmail.com will set --user foobar. Apps launched from the ChromeOS launcher run under this user.<br />
<br />
2. Replace the default Debian container with Arch Linux.<br />
<br />
The default Debian container is named penguin. Renaming the "arch" container created above to it will cause chrome to launch Linux apps from the arch container.<br />
<br />
lxc stop arch<br />
lxc stop penguin<br />
lxc rename penguin debian<br />
lxc rename arch penguin<br />
<br />
3. Set password for gmail username<br />
<br />
By default the gmail user has no password set. Use lxc exec to set a password:<br />
<br />
lxc exec penguin -- bash<br />
<br />
You also might want to add [[sudo]] and add the user to sudoers.<br />
<br />
4. Install Crostini container tools, Wayland for GUI apps, XWayland for X11 apps.<br />
<br />
First open a console session the the Arch Linux container.<br />
<br />
lxc console penguin<br />
<br />
[[Install]] the {{AUR|cros-container-guest-tools-git}} package. Additionally install {{Pkg|wayland}} and {{Pkg|xorg-server-xwayland}} to be able to use GUI tools.<br />
<br />
At present (11-24-2018) xkeyboard-config 2.24 break the sommelier-x service. Workaround is to comment out two lines starting with "<i372>" and "<i374>" in /usr/share/X11/xkb/keycodes/evdev. Then enable and start the services.<br />
<br />
$ systemctl --user enable sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user enable sommelier-x@0 # For X11 GUI apps<br />
$ systemctl --user start sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user start sommelier-x@0 # For X11 GUI apps<br />
<br />
Make sure these services are running successfully by running:<br />
$ systemctl --user status sommelier@0<br />
$ systemctl --user status sommelier-x@0<br />
<br />
Now, when apps are installed in Arch Linux, they will automatically show up and can be launched from ChromeOS. Note that while GUI apps work, rendering is still software, with no OpenGL support yet.<br />
<br />
==Troubleshooting==<br />
<br />
===Network not working on Pixelbook===<br />
<br />
https://tedyin.com/posts/archlinux-on-pixelbook/ reports that the below setting needs to be set to get the network working on the pixelbook. Make sure to restart your container after you set it.<br />
<br />
lxc profile set default security.syscalls.blacklist "keyctl errno 38"<br />
<br />
===DNS resolution not working===<br />
<br />
DNS resolution stopped working in the container after my install. To get it working again I had to create [[:/etc/resolv.conf]].<br />
<br />
As of Jan 2019, my container wasn't able to resolve ".org" DNS, I had to modify {{man|5|nsswitch.conf}} (only the hosts line).<br />
<br />
hosts: files dns<br />
<br />
===App not opening in chrome OS (infinite spinner)===<br />
<br />
I found that launching a console (lxc console penguin) session prevents apps from launching in Chrome OS. Launching results in an infinite spinner. In that case I have to stop and start the container to get the Chrome OS launcher working<br />
<br />
lxc stop penguin<br />
lxc start penguin<br />
<br />
Instead of using an lxc console session, I use a regular Linux terminal GUI launched from ChomeOS that prevents this issue.<br />
<br />
===Steam / OpenGL / GLX not working===<br />
<br />
I found that Steam / OpenGL / GLX don't work out of the box because the Arch install is different. The issue has to do with sommelier-x. The original crostini [https://chromium.googlesource.com/chromiumos/containers/cros-container-guest-tools/+/master/cros-sommelier-config/postinst cros-container-guest-tools installer] copies the crostini supplied swrast_dri.so to /usr/lib64/dri/ because "mesa always looks at that path" instead of the version of swrast_dri.so supplied with crostini. This line installing swrast_dri.so is not part of the Arch linux installer, and thus OpenGL apps via X11 do not function. Further, on Arch copying this library over in needed for sommelier-x to work with GLX, allowing steam to work, but glxgears/glxinfo need the default mesa-distributed swrast_dri.so. I've been able to get steam & glxgears with the right combination of libraries by running the below commands each time Arch starts up.<br />
<br />
$ glxgears<br />
Error: couldn't get an RGB, Double-buffered visual<br />
<br />
$ sudo cp /usr/lib64/dri/swrast_dri.so /usr/lib64/dri/swrast_dri.so.backup<br />
$ sudo cp /opt/google/cros-containers/lib/swrast_dri.so /usr/lib64/dri/swrast_dri.so<br />
$ systemctl --user restart sommelier-x@0.service<br />
<br />
$ glxinfo<br />
Segmentation fault (core dumped)<br />
$ # But Steam works at this point<br />
<br />
$ sudo cp /usr/lib64/dri/swrast_dri.so.backup /usr/lib64/dri/swrast_dri.so<br />
<br />
$ glxgears<br />
SUCCESS<br />
<br />
$ # But after a few minutes sommelier-x reloads the mesa version and fails.<br />
<br />
To get steam working I had to replace /usr/lib64/dri/swrast_dri.so with the cros-containers version. This works permanently. I haven't been able to find a way to keep glxgears/glxinfo working permanently.<br />
<br />
===Fullscreen games and mouse capture don't work correctly===<br />
<br />
Currently Crostini doesn't allow linux apps to be completely fullscreen and mouse capture doesn't work correctly. So playing most Steam games is infeasable.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Chrome_OS_devices/Crostini&diff=576245Chrome OS devices/Crostini2019-06-23T16:49:38Z<p>Crescent: Latests updates : fullscreen & mouse capture dont work, OpenGL and audio supported</p>
<hr />
<div>[[Category:Laptops]]<br />
[[ja:Crostini]]<br />
[https://chromium.googlesource.com/chromiumos/docs/+/master/containers_and_vms.md Crostini] is Google's umbrella term for making Linux application support easy to use and integrating well with Chrome OS.<br />
<br />
This article describes how to install Arch Linux on a Chromebook in a container (via Crostini), without needing to enable developer mode, allowing apps to run alongside other Chrome/Android apps.<br />
<br />
Highlights:<br />
* Officially supported, don't need to enable developer mode - leaves ChromeOS secure, no need to flash a BIOS etc.<br />
* Better battery life - Battery life of Chrome with the functionality of Linux.<br />
* Access to Android apps, play store etc.<br />
* Audio & OpenGL are supported, but microphone and USB devices are still in progress.<br />
<br />
== Introduction ==<br />
<br />
=== Enabling Linux support ===<br />
<br />
Look for Linux under Settings and enable it. This installs a Debian Linux container that we will then replace with an Arch Linux container.<br />
<br />
:''Settings > Linux > Enable''<br />
<br />
Crostini is still rolling out to Chromebooks. If you don't see an option to enable Linux, you may need to switch to the beta or developer channel, if it has not rolled out to the stable channel for your laptop yet. This can be done via ''Settings > About Chrome OS > Channel > Dev/Beta''.<br />
<br />
=== Replacing the default Debian Linux container with Arch Linux ===<br />
<br />
The below instructions were taken from https://www.reddit.com/r/Crostini/wiki/howto/run-arch-linux<br />
<br />
1. Install an Arch linux container <br />
<br />
Open a new terminal in Chrome (Ctrl + Alt + T). Then connect to terminal and create an arch linux container:<br />
<br />
vsh termina<br />
run_container.sh --container_name arch --user <gmail username> --lxd_image archlinux/current --lxd_remote https://us.images.linuxcontainers.org/<br />
<br />
The <gmail username> here is the same user you are logged in to your Chromebooks as, without the @gmail.com and dots. eg. foo.bar@gmail.com will set --user foobar. Apps launched from the ChromeOS launcher run under this user.<br />
<br />
2. Replace the default Debian container with Arch Linux.<br />
<br />
The default Debian container is named penguin. Renaming the "arch" container created above to it will cause chrome to launch Linux apps from the arch container.<br />
<br />
lxc stop arch<br />
lxc stop penguin<br />
lxc rename penguin debian<br />
lxc rename arch penguin<br />
<br />
3. Set password for gmail username<br />
<br />
By default the gmail user has no password set. Use lxc exec to set a password:<br />
<br />
lxc exec penguin -- bash<br />
<br />
You also might want to add [[sudo]] and add the user to sudoers.<br />
<br />
4. Install Crostini container tools, Wayland for GUI apps, XWayland for X11 apps.<br />
<br />
First open a console session the the Arch Linux container.<br />
<br />
lxc console penguin<br />
<br />
[[Install]] the {{AUR|cros-container-guest-tools-git}} package. Additionally install {{Pkg|wayland}} and {{Pkg|xorg-server-xwayland}} to be able to use GUI tools.<br />
<br />
At present (11-24-2018) xkeyboard-config 2.24 break the sommelier-x service. Workaround is to comment out two lines starting with "<i372>" and "<i374>" in /usr/share/X11/xkb/keycodes/evdev. Then enable and start the services.<br />
<br />
$ systemctl --user enable sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user enable sommelier-x@0 # For X11 GUI apps<br />
$ systemctl --user start sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user start sommelier-x@0 # For X11 GUI apps<br />
<br />
Make sure these services are running successfully by running:<br />
$ systemctl --user status sommelier@0<br />
$ systemctl --user status sommelier-x@0<br />
<br />
Now, when apps are installed in Arch Linux, they will automatically show up and can be launched from ChromeOS. Note that while GUI apps work, rendering is still software, with no OpenGL support yet.<br />
<br />
==Troubleshooting==<br />
<br />
===Network not working on Pixelbook===<br />
<br />
https://tedyin.com/posts/archlinux-on-pixelbook/ reports that the below setting needs to be set to get the network working on the pixelbook. Make sure to restart your container after you set it.<br />
<br />
lxc profile set default security.syscalls.blacklist "keyctl errno 38"<br />
<br />
===DNS resolution not working===<br />
<br />
DNS resolution stopped working in the container after my install. To get it working again I had to create [[:/etc/resolv.conf]].<br />
<br />
As of Jan 2019, my container wasn't able to resolve ".org" DNS, I had to modify {{man|5|nsswitch.conf}} (only the hosts line).<br />
<br />
hosts: files dns<br />
<br />
===App not opening in chrome OS (infinite spinner)===<br />
<br />
I found that launching a console (lxc console penguin) session prevents apps from launching in Chrome OS. Launching results in an infinite spinner. In that case I have to stop and start the container to get the Chrome OS launcher working<br />
<br />
lxc stop penguin<br />
lxc start penguin<br />
<br />
Instead of using an lxc console session, I use a regular Linux terminal GUI launched from ChomeOS that prevents this issue.<br />
<br />
===Steam / OpenGL / GLX not working===<br />
<br />
I found that Steam / OpenGL / GLX don't work out of the box because the Arch install is different. The issue has to do with sommelier-x. The original crostini [https://chromium.googlesource.com/chromiumos/containers/cros-container-guest-tools/+/master/cros-sommelier-config/postinst cros-container-guest-tools installer] copies the crostini supplied swrast_dri.so to /usr/lib64/dri/ because "mesa always looks at that path" instead of the version of swrast_dri.so supplied with crostini. This line installing swrast_dri.so is not part of the Arch linux installer, and thus OpenGL apps via X11 do not function. Further, on Arch copying this library over in needed for sommelier-x to work with GLX, allowing steam to work, but glxgears/glxinfo need the default mesa-distributed swrast_dri.so. I've been able to get steam & glxgears with the right combination of libraries by running the below commands each time Arch starts up.<br />
<br />
$ glxgears<br />
Error: couldn't get an RGB, Double-buffered visual<br />
<br />
$ sudo cp /usr/lib64/dri/swrast_dri.so /usr/lib64/dri/swrast_dri.so.backup<br />
$ sudo cp /opt/google/cros-containers/lib/swrast_dri.so /usr/lib64/dri/swrast_dri.so<br />
$ systemctl --user restart sommelier-x@0.service<br />
<br />
$ glxinfo<br />
Segmentation fault (core dumped)<br />
$ # But Steam works at this point<br />
<br />
$ sudo cp /usr/lib64/dri/swrast_dri.so.backup /usr/lib64/dri/swrast_dri.so<br />
<br />
$ glxgears<br />
SUCCESS<br />
<br />
$ # But after a few minutes sommelier-x reloads the mesa version and fails.<br />
<br />
To get steam working I had to replace /usr/lib64/dri/swrast_dri.so with the cros-containers version. This works permanently. I haven't been able to find a way to keep glxgears/glxinfo working permanently.<br />
<br />
===Fullscreen games and mouse capture don't work correctly===.<br />
<br />
Currently Crostini doesn't allow linux apps to be completely fullscreen and mouse capture doesn't work correctly. So playing most Steam games is infeasable.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Chrome_OS_devices/Crostini&diff=567552Chrome OS devices/Crostini2019-02-28T19:32:19Z<p>Crescent: Update audio rollout version</p>
<hr />
<div>[[Category:Laptops]]<br />
[[ja:Crostini]]<br />
[https://chromium.googlesource.com/chromiumos/docs/+/master/containers_and_vms.md Crostini] is Google's umbrella term for making Linux application support easy to use and integrating well with Chrome OS.<br />
<br />
This article describes how to install Arch Linux on a Chromebook in a container (via Crostini), without needing to enable developer mode, allowing apps to run alongside other Chrome/Android apps.<br />
<br />
;Advantages<br />
* Don't need to enable developer mode - Officially supported, leaves ChromeOS secure, no need to flash a BIOS etc.<br />
* Better battery life - Battery life of Chrome with the functionality of Linux.<br />
* Access to Android apps, play store etc.<br />
<br />
;Disadvantages<br />
* Audio support rolling in [https://crbug.com/781398 Chroms Os 74] (Feb 28 2019)<br />
* OpenGL support is still [https://crbug.com/837073 in progress] (Feb 4 2019)<br />
<br />
== Introduction ==<br />
<br />
=== Enabling Linux support ===<br />
<br />
Look for Linux under Settings and enable it. This installs a Debian Linux container that we will then replace with an Arch Linux container.<br />
<br />
:''Settings > Linux > Enable''<br />
<br />
Crostini is still rolling out to Chromebooks. If you don't see an option to enable Linux, you may need to switch to the beta or developer channel, if it has not rolled out to the stable channel for your laptop yet. This can be done via ''Settings > About Chrome OS > Channel > Dev/Beta''.<br />
<br />
=== Replacing the default Debian Linux container with Arch Linux ===<br />
<br />
The below instructions were taken from https://www.reddit.com/r/Crostini/wiki/howto/run-arch-linux<br />
<br />
1. Install an Arch linux container <br />
<br />
Open a new terminal in Chrome (Ctrl + Alt + T). Then connect to terminal and create an arch linux container:<br />
<br />
vsh termina<br />
run_container.sh --container_name arch --user <gmail username> --lxd_image archlinux/current --lxd_remote https://us.images.linuxcontainers.org/<br />
<br />
The <gmail username> here is the same user you are logged in to your Chromebooks as, without the @gmail.com and dots. eg. foo.bar@gmail.com will set --user foobar. Apps launched from the ChromeOS launcher run under this user.<br />
<br />
2. Replace the default Debian container with Arch Linux.<br />
<br />
The default Debian container is named penguin. Renaming the "arch" container created above to it will cause chrome to launch Linux apps from the arch container.<br />
<br />
lxc stop arch<br />
lxc stop penguin<br />
lxc rename penguin debian<br />
lxc rename arch penguin<br />
<br />
3. Set password for gmail username<br />
<br />
By default the gmail user has no password set. Use lxc exec to set a password:<br />
<br />
lxc exec penguin -- bash<br />
<br />
You also might want to add [[sudo]] and add the user to sudoers.<br />
<br />
4. Install Crostini container tools, Wayland for GUI apps, XWayland for X11 apps.<br />
<br />
First open a console session the the Arch Linux container.<br />
<br />
lxc console penguin<br />
<br />
[[Install]] the {{AUR|cros-container-guest-tools-git}} package. Additionally install {{Pkg|wayland}} and {{Pkg|xorg-server-xwayland}} to be able to use GUI tools.<br />
<br />
At present (11-24-2018) xkeyboard-config 2.24 break the sommelier-x service. Workaround is to comment out two lines starting with "<i372>" and "<i374>" in /usr/share/X11/xkb/keycodes/evdev. Then enable and start the services.<br />
<br />
$ systemctl --user enable sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user enable sommelier-x@0 # For X11 GUI apps<br />
$ systemctl --user start sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user start sommelier-x@0 # For X11 GUI apps<br />
<br />
Make sure these services are running successfully by running:<br />
$ systemctl --user status sommelier@0<br />
$ systemctl --user status sommelier-x@0<br />
<br />
Now, when apps are installed in Arch Linux, they will automatically show up and can be launched from ChromeOS. Note that while GUI apps work, rendering is still software, with no OpenGL support yet.<br />
<br />
==Troubleshooting==<br />
<br />
===Network not working on Pixelbook===<br />
<br />
https://tedyin.com/posts/archlinux-on-pixelbook/ reports that the below setting needs to be set to get the network working on the pixelbook. Make sure to restart your container after you set it.<br />
<br />
lxc profile set default security.syscalls.blacklist "keyctl errno 38"<br />
<br />
===DNS resolution not working===<br />
<br />
DNS resolution stopped working in the container after my install. To get it working again I had to create [[:/etc/resolv.conf]].<br />
<br />
As of Jan 2019, my container wasn't able to resolve ".org" DNS, I had to modify {{man|5|nsswitch.conf}} (only the hosts line).<br />
<br />
hosts: files dns<br />
<br />
===App not opening in chrome OS (infinite spinner)===<br />
<br />
I found that launching a console (lxc console penguin) session prevents apps from launching in Chrome OS. Launching results in an infinite spinner. In that case I have to stop and start the container to get the Chrome OS launcher working<br />
<br />
lxc stop penguin<br />
lxc start penguin<br />
<br />
Instead of using an lxc console session, I use a regular Linux terminal GUI launched from ChomeOS that prevents this issue.<br />
<br />
===Steam / OpenGL / GLX not working===<br />
<br />
I found that Steam / OpenGL / GLX don't work out of the box because the Arch install is different. The issue has to do with sommelier-x. The original crostini [https://chromium.googlesource.com/chromiumos/containers/cros-container-guest-tools/+/master/cros-sommelier-config/postinst cros-container-guest-tools installer] copies the crostini supplied swrast_dri.so to /usr/lib64/dri/ because "mesa always looks at that path" instead of the version of swrast_dri.so supplied with crostini. This line installing swrast_dri.so is not part of the Arch linux installer, and thus OpenGL apps via X11 do not function. Further, on Arch copying this library over in needed for sommelier-x to work with GLX, allowing steam to work, but glxgears/glxinfo need the default mesa-distributed swrast_dri.so. I've been able to get steam & glxgears with the right combination of libraries by running the below commands each time Arch starts up.<br />
<br />
$ glxgears<br />
Error: couldn't get an RGB, Double-buffered visual<br />
<br />
$ sudo cp /usr/lib64/dri/swrast_dri.so /usr/lib64/dri/swrast_dri.so.backup<br />
$ sudo cp /opt/google/cros-containers/lib/swrast_dri.so /usr/lib64/dri/swrast_dri.so<br />
$ systemctl --user restart sommelier-x@0.service<br />
<br />
$ glxinfo<br />
Segmentation fault (core dumped)<br />
$ # But Steam works at this point<br />
<br />
$ sudo cp /usr/lib64/dri/swrast_dri.so.backup /usr/lib64/dri/swrast_dri.so<br />
<br />
$ glxgears<br />
SUCCESS<br />
<br />
$ # But after a few minutes sommelier-x reloads the mesa version and fails.<br />
<br />
To get steam working I had to replace /usr/lib64/dri/swrast_dri.so with the cros-containers version. This works permanently. I haven't been able to find a way to keep glxgears/glxinfo working permanently.<br />
<br />
===App that requires sound card not working===<br />
<br />
Crostini does not yet support sound. However, a dummy sound card can be created by installing and running pulseaudio that allows apps that require a sound card to run.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Chrome_OS_devices/Crostini&diff=566043Chrome OS devices/Crostini2019-02-08T06:56:14Z<p>Crescent: Update GLX not working wording</p>
<hr />
<div>[[Category:Laptops]]<br />
[[ja:Crostini]]<br />
[https://chromium.googlesource.com/chromiumos/docs/+/master/containers_and_vms.md Crostini] is Google's umbrella term for making Linux application support easy to use and integrating well with Chrome OS.<br />
<br />
This article describes how to install Arch Linux on a Chromebook in a container (via Crostini), without needing to enable developer mode, allowing apps to run alongside other Chrome/Android apps.<br />
<br />
;Advantages<br />
* Don't need to enable developer mode - Officially supported, leaves ChromeOS secure, no need to flash a BIOS etc.<br />
* Better battery life - Battery life of Chrome with the functionality of Linux.<br />
* Access to Android apps, play store etc.<br />
<br />
;Disadvantages<br />
* Audio support is still [https://crbug.com/781398 in progress] (Feb 4 2019)<br />
* OpenGL support is still [https://crbug.com/837073 in progress] (Feb 4 2019)<br />
<br />
== Introduction ==<br />
<br />
=== Enabling Linux support ===<br />
<br />
Look for Linux under Settings and enable it. This installs a Debian Linux container that we will then replace with an Arch Linux container.<br />
<br />
:''Settings > Linux > Enable''<br />
<br />
Crostini is still rolling out to Chromebooks. If you don't see an option to enable Linux, you may need to switch to the beta or developer channel, if it has not rolled out to the stable channel for your laptop yet. This can be done via ''Settings > About Chrome OS > Channel > Dev/Beta''.<br />
<br />
=== Replacing the default Debian Linux container with Arch Linux ===<br />
<br />
The below instructions were taken from https://www.reddit.com/r/Crostini/wiki/howto/run-arch-linux<br />
<br />
1. Install an Arch linux container <br />
<br />
Open a new terminal in Chrome (Ctrl + Alt + T). Then connect to terminal and create an arch linux container:<br />
<br />
vsh termina<br />
run_container.sh --container_name arch --user <gmail username> --lxd_image archlinux/current --lxd_remote https://us.images.linuxcontainers.org/<br />
<br />
The <gmail username> here is the same user you are logged in to your Chromebooks as, without the @gmail.com and dots. eg. foo.bar@gmail.com will set --user foobar. Apps launched from the ChromeOS launcher run under this user.<br />
<br />
2. Replace the default Debian container with Arch Linux.<br />
<br />
The default Debian container is named penguin. Renaming the "arch" container created above to it will cause chrome to launch Linux apps from the arch container.<br />
<br />
lxc stop arch<br />
lxc stop penguin<br />
lxc rename penguin debian<br />
lxc rename arch penguin<br />
<br />
3. Set password for gmail username<br />
<br />
By default the gmail user has no password set. Use lxc exec to set a password:<br />
<br />
lxc exec penguin -- bash<br />
<br />
You also might want to add [[sudo]] and add the user to sudoers.<br />
<br />
4. Install Crostini container tools, Wayland for GUI apps, XWayland for X11 apps.<br />
<br />
First open a console session the the Arch Linux container.<br />
<br />
lxc console penguin<br />
<br />
[[Install]] the {{AUR|cros-container-guest-tools-git}} package. Additionally install {{Pkg|wayland}} and {{Pkg|xorg-server-xwayland}} to be able to use GUI tools.<br />
<br />
At present (11-24-2018) xkeyboard-config 2.24 break the sommelier-x service. Workaround is to comment out two lines starting with "<i372>" and "<i374>" in /usr/share/X11/xkb/keycodes/evdev. Then enable and start the services.<br />
<br />
$ systemctl --user enable sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user enable sommelier-x@0 # For X11 GUI apps<br />
$ systemctl --user start sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user start sommelier-x@0 # For X11 GUI apps<br />
<br />
Make sure these services are running successfully by running:<br />
$ systemctl --user status sommelier@0<br />
$ systemctl --user status sommelier-x@0<br />
<br />
Now, when apps are installed in Arch Linux, they will automatically show up and can be launched from ChromeOS. Note that while GUI apps work, rendering is still software, with no OpenGL support yet.<br />
<br />
==Troubleshooting==<br />
<br />
===Network not working on Pixelbook===<br />
<br />
https://tedyin.com/posts/archlinux-on-pixelbook/ reports that the below setting needs to be set to get the network working on the pixelbook. Make sure to restart your container after you set it.<br />
<br />
lxc profile set default security.syscalls.blacklist "keyctl errno 38"<br />
<br />
===DNS resolution not working===<br />
<br />
DNS resolution stopped working in the container after my install. To get it working again I had to create [[:/etc/resolv.conf]].<br />
<br />
As of Jan 2019, my container wasn't able to resolve ".org" DNS, I had to modify {{man|5|nsswitch.conf}} (only the hosts line).<br />
<br />
hosts: files dns<br />
<br />
===App not opening in chrome OS (infinite spinner)===<br />
<br />
I found that launching a console (lxc console penguin) session prevents apps from launching in Chrome OS. Launching results in an infinite spinner. In that case I have to stop and start the container to get the Chrome OS launcher working<br />
<br />
lxc stop penguin<br />
lxc start penguin<br />
<br />
Instead of using an lxc console session, I use a regular Linux terminal GUI launched from ChomeOS that prevents this issue.<br />
<br />
===Steam / OpenGL / GLX not working===<br />
<br />
I found that Steam / OpenGL / GLX don't work out of the box because the Arch install is different. The issue has to do with sommelier-x. The original crostini [https://chromium.googlesource.com/chromiumos/containers/cros-container-guest-tools/+/master/cros-sommelier-config/postinst cros-container-guest-tools installer] copies the crostini supplied swrast_dri.so to /usr/lib64/dri/ because "mesa always looks at that path" instead of the version of swrast_dri.so supplied with crostini. This line installing swrast_dri.so is not part of the Arch linux installer, and thus OpenGL apps via X11 do not function. Further, on Arch copying this library over in needed for sommelier-x to work with GLX, allowing steam to work, but glxgears/glxinfo need the default mesa-distributed swrast_dri.so. I've been able to get steam & glxgears with the right combination of libraries by running the below commands each time Arch starts up.<br />
<br />
$ glxgears<br />
Error: couldn't get an RGB, Double-buffered visual<br />
<br />
$ sudo cp /usr/lib64/dri/swrast_dri.so /usr/lib64/dri/swrast_dri.so.backup<br />
$ sudo cp /opt/google/cros-containers/lib/swrast_dri.so /usr/lib64/dri/swrast_dri.so<br />
$ systemctl --user restart sommelier-x@0.service<br />
<br />
$ glxinfo<br />
Segmentation fault (core dumped)<br />
$ # But Steam works at this point<br />
<br />
$ sudo cp /usr/lib64/dri/swrast_dri.so.backup /usr/lib64/dri/swrast_dri.so<br />
<br />
$ glxgears<br />
SUCCESS<br />
<br />
$ # But after a few minutes sommelier-x reloads the mesa version and fails.<br />
<br />
To get steam working I had to replace /usr/lib64/dri/swrast_dri.so with the cros-containers version. This works permanently. I haven't been able to find a way to keep glxgears/glxinfo working permanently.<br />
<br />
===App that requires sound card not working===<br />
<br />
Crostini does not yet support sound. However, a dummy sound card can be created by installing and running pulseaudio that allows apps that require a sound card to run.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Chrome_OS_devices/Crostini&diff=566042Chrome OS devices/Crostini2019-02-08T06:55:53Z<p>Crescent: Update GLX not working wording</p>
<hr />
<div>[[Category:Laptops]]<br />
[[ja:Crostini]]<br />
[https://chromium.googlesource.com/chromiumos/docs/+/master/containers_and_vms.md Crostini] is Google's umbrella term for making Linux application support easy to use and integrating well with Chrome OS.<br />
<br />
This article describes how to install Arch Linux on a Chromebook in a container (via Crostini), without needing to enable developer mode, allowing apps to run alongside other Chrome/Android apps.<br />
<br />
;Advantages<br />
* Don't need to enable developer mode - Officially supported, leaves ChromeOS secure, no need to flash a BIOS etc.<br />
* Better battery life - Battery life of Chrome with the functionality of Linux.<br />
* Access to Android apps, play store etc.<br />
<br />
;Disadvantages<br />
* Audio support is still [https://crbug.com/781398 in progress] (Feb 4 2019)<br />
* OpenGL support is still [https://crbug.com/837073 in progress] (Feb 4 2019)<br />
<br />
== Introduction ==<br />
<br />
=== Enabling Linux support ===<br />
<br />
Look for Linux under Settings and enable it. This installs a Debian Linux container that we will then replace with an Arch Linux container.<br />
<br />
:''Settings > Linux > Enable''<br />
<br />
Crostini is still rolling out to Chromebooks. If you don't see an option to enable Linux, you may need to switch to the beta or developer channel, if it has not rolled out to the stable channel for your laptop yet. This can be done via ''Settings > About Chrome OS > Channel > Dev/Beta''.<br />
<br />
=== Replacing the default Debian Linux container with Arch Linux ===<br />
<br />
The below instructions were taken from https://www.reddit.com/r/Crostini/wiki/howto/run-arch-linux<br />
<br />
1. Install an Arch linux container <br />
<br />
Open a new terminal in Chrome (Ctrl + Alt + T). Then connect to terminal and create an arch linux container:<br />
<br />
vsh termina<br />
run_container.sh --container_name arch --user <gmail username> --lxd_image archlinux/current --lxd_remote https://us.images.linuxcontainers.org/<br />
<br />
The <gmail username> here is the same user you are logged in to your Chromebooks as, without the @gmail.com and dots. eg. foo.bar@gmail.com will set --user foobar. Apps launched from the ChromeOS launcher run under this user.<br />
<br />
2. Replace the default Debian container with Arch Linux.<br />
<br />
The default Debian container is named penguin. Renaming the "arch" container created above to it will cause chrome to launch Linux apps from the arch container.<br />
<br />
lxc stop arch<br />
lxc stop penguin<br />
lxc rename penguin debian<br />
lxc rename arch penguin<br />
<br />
3. Set password for gmail username<br />
<br />
By default the gmail user has no password set. Use lxc exec to set a password:<br />
<br />
lxc exec penguin -- bash<br />
<br />
You also might want to add [[sudo]] and add the user to sudoers.<br />
<br />
4. Install Crostini container tools, Wayland for GUI apps, XWayland for X11 apps.<br />
<br />
First open a console session the the Arch Linux container.<br />
<br />
lxc console penguin<br />
<br />
[[Install]] the {{AUR|cros-container-guest-tools-git}} package. Additionally install {{Pkg|wayland}} and {{Pkg|xorg-server-xwayland}} to be able to use GUI tools.<br />
<br />
At present (11-24-2018) xkeyboard-config 2.24 break the sommelier-x service. Workaround is to comment out two lines starting with "<i372>" and "<i374>" in /usr/share/X11/xkb/keycodes/evdev. Then enable and start the services.<br />
<br />
$ systemctl --user enable sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user enable sommelier-x@0 # For X11 GUI apps<br />
$ systemctl --user start sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user start sommelier-x@0 # For X11 GUI apps<br />
<br />
Make sure these services are running successfully by running:<br />
$ systemctl --user status sommelier@0<br />
$ systemctl --user status sommelier-x@0<br />
<br />
Now, when apps are installed in Arch Linux, they will automatically show up and can be launched from ChromeOS. Note that while GUI apps work, rendering is still software, with no OpenGL support yet.<br />
<br />
==Troubleshooting==<br />
<br />
===Network not working on Pixelbook===<br />
<br />
https://tedyin.com/posts/archlinux-on-pixelbook/ reports that the below setting needs to be set to get the network working on the pixelbook. Make sure to restart your container after you set it.<br />
<br />
lxc profile set default security.syscalls.blacklist "keyctl errno 38"<br />
<br />
===DNS resolution not working===<br />
<br />
DNS resolution stopped working in the container after my install. To get it working again I had to create [[:/etc/resolv.conf]].<br />
<br />
As of Jan 2019, my container wasn't able to resolve ".org" DNS, I had to modify {{man|5|nsswitch.conf}} (only the hosts line).<br />
<br />
hosts: files dns<br />
<br />
===App not opening in chrome OS (infinite spinner)===<br />
<br />
I found that launching a console (lxc console penguin) session prevents apps from launching in Chrome OS. Launching results in an infinite spinner. In that case I have to stop and start the container to get the Chrome OS launcher working<br />
<br />
lxc stop penguin<br />
lxc start penguin<br />
<br />
Instead of using an lxc console session, I use a regular Linux terminal GUI launched from ChomeOS that prevents this issue.<br />
<br />
===Steam / OpenGL / GLX not working===<br />
<br />
I found that Steam / OpenGL / GLX don't work out of the box because the Arch install is different. The issue has to do with sommelier-x. The original crostini [https://chromium.googlesource.com/chromiumos/containers/cros-container-guest-tools/+/master/cros-sommelier-config/postinst cros-container-guest-tools installer] copies the crostini supplied swrast_dri.so to /usr/lib64/dri/ because "mesa always looks at that path" instead of the version of swrast_dri.so supplied with crostini. This line installing swrast_dri.so is not part of the Arch linux installer, and thus OpenGL apps via X11 do not function. Further, on Arch copying this library over in needed for sommelier-x to work with GLX, allowing steam to work, but glxgears/glxinfo need the default mesa-distributed swrast_dri.so. I've been able to get steam & glxgears with the right combination of libraries by running the below commands each time Arch starts up.<br />
<br />
$ glxgears<br />
Error: couldn't get an RGB, Double-buffered visual<br />
<br />
$ sudo cp /usr/lib64/dri/swrast_dri.so /usr/lib64/dri/swrast_dri.so.backup<br />
$ sudo cp /opt/google/cros-containers/lib/swrast_dri.so /usr/lib64/dri/swrast_dri.so<br />
$ systemctl --user restart sommelier-x@0.service<br />
<br />
$ glxinfo<br />
Segmentation fault (core dumped)<br />
$ # But Steam works at this point<br />
<br />
$ sudo cp /usr/lib64/dri/swrast_dri.so.backup /usr/lib64/dri/swrast_dri.so<br />
<br />
$ glxgears<br />
SUCCESS<br />
<br />
$ # But after a few minutes sommelier-x reloads the mesa version and fails.<br />
<br />
To get steam working I had to replace /usr/lib64/dri/swrast_dri.so with the cros-containers version. This works permanently. I haven't been able to find a way to keep glxgears/glxinfo working permanently.<br />
<br />
===App that requires sound card not working===<br />
<br />
Crostini does not yet support sound. However, a dummy sound card can be created by installing and running pulseaudio that allows apps that require a sound card to run.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Chrome_OS_devices/Crostini&diff=566041Chrome OS devices/Crostini2019-02-08T06:38:49Z<p>Crescent: Update instructions on getting GLX working via X11 for Steam/glxgears</p>
<hr />
<div>[[Category:Laptops]]<br />
[[ja:Crostini]]<br />
[https://chromium.googlesource.com/chromiumos/docs/+/master/containers_and_vms.md Crostini] is Google's umbrella term for making Linux application support easy to use and integrating well with Chrome OS.<br />
<br />
This article describes how to install Arch Linux on a Chromebook in a container (via Crostini), without needing to enable developer mode, allowing apps to run alongside other Chrome/Android apps.<br />
<br />
;Advantages<br />
* Don't need to enable developer mode - Officially supported, leaves ChromeOS secure, no need to flash a BIOS etc.<br />
* Better battery life - Battery life of Chrome with the functionality of Linux.<br />
* Access to Android apps, play store etc.<br />
<br />
;Disadvantages<br />
* Audio support is still [https://crbug.com/781398 in progress] (Feb 4 2019)<br />
* OpenGL support is still [https://crbug.com/837073 in progress] (Feb 4 2019)<br />
<br />
== Introduction ==<br />
<br />
=== Enabling Linux support ===<br />
<br />
Look for Linux under Settings and enable it. This installs a Debian Linux container that we will then replace with an Arch Linux container.<br />
<br />
:''Settings > Linux > Enable''<br />
<br />
Crostini is still rolling out to Chromebooks. If you don't see an option to enable Linux, you may need to switch to the beta or developer channel, if it has not rolled out to the stable channel for your laptop yet. This can be done via ''Settings > About Chrome OS > Channel > Dev/Beta''.<br />
<br />
=== Replacing the default Debian Linux container with Arch Linux ===<br />
<br />
The below instructions were taken from https://www.reddit.com/r/Crostini/wiki/howto/run-arch-linux<br />
<br />
1. Install an Arch linux container <br />
<br />
Open a new terminal in Chrome (Ctrl + Alt + T). Then connect to terminal and create an arch linux container:<br />
<br />
vsh termina<br />
run_container.sh --container_name arch --user <gmail username> --lxd_image archlinux/current --lxd_remote https://us.images.linuxcontainers.org/<br />
<br />
The <gmail username> here is the same user you are logged in to your Chromebooks as, without the @gmail.com and dots. eg. foo.bar@gmail.com will set --user foobar. Apps launched from the ChromeOS launcher run under this user.<br />
<br />
2. Replace the default Debian container with Arch Linux.<br />
<br />
The default Debian container is named penguin. Renaming the "arch" container created above to it will cause chrome to launch Linux apps from the arch container.<br />
<br />
lxc stop arch<br />
lxc stop penguin<br />
lxc rename penguin debian<br />
lxc rename arch penguin<br />
<br />
3. Set password for gmail username<br />
<br />
By default the gmail user has no password set. Use lxc exec to set a password:<br />
<br />
lxc exec penguin -- bash<br />
<br />
You also might want to add [[sudo]] and add the user to sudoers.<br />
<br />
4. Install Crostini container tools, Wayland for GUI apps, XWayland for X11 apps.<br />
<br />
First open a console session the the Arch Linux container.<br />
<br />
lxc console penguin<br />
<br />
[[Install]] the {{AUR|cros-container-guest-tools-git}} package. Additionally install {{Pkg|wayland}} and {{Pkg|xorg-server-xwayland}} to be able to use GUI tools.<br />
<br />
At present (11-24-2018) xkeyboard-config 2.24 break the sommelier-x service. Workaround is to comment out two lines starting with "<i372>" and "<i374>" in /usr/share/X11/xkb/keycodes/evdev. Then enable and start the services.<br />
<br />
$ systemctl --user enable sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user enable sommelier-x@0 # For X11 GUI apps<br />
$ systemctl --user start sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user start sommelier-x@0 # For X11 GUI apps<br />
<br />
Make sure these services are running successfully by running:<br />
$ systemctl --user status sommelier@0<br />
$ systemctl --user status sommelier-x@0<br />
<br />
Now, when apps are installed in Arch Linux, they will automatically show up and can be launched from ChromeOS. Note that while GUI apps work, rendering is still software, with no OpenGL support yet.<br />
<br />
==Troubleshooting==<br />
<br />
===Network not working on Pixelbook===<br />
<br />
https://tedyin.com/posts/archlinux-on-pixelbook/ reports that the below setting needs to be set to get the network working on the pixelbook. Make sure to restart your container after you set it.<br />
<br />
lxc profile set default security.syscalls.blacklist "keyctl errno 38"<br />
<br />
===DNS resolution not working===<br />
<br />
DNS resolution stopped working in the container after my install. To get it working again I had to create [[:/etc/resolv.conf]].<br />
<br />
As of Jan 2019, my container wasn't able to resolve ".org" DNS, I had to modify {{man|5|nsswitch.conf}} (only the hosts line).<br />
<br />
hosts: files dns<br />
<br />
===App not opening in chrome OS (infinite spinner)===<br />
<br />
I found that launching a console (lxc console penguin) session prevents apps from launching in Chrome OS. Launching results in an infinite spinner. In that case I have to stop and start the container to get the Chrome OS launcher working<br />
<br />
lxc stop penguin<br />
lxc start penguin<br />
<br />
Instead of using an lxc console session, I use a regular Linux terminal GUI launched from ChomeOS that prevents this issue.<br />
<br />
===Steam / OpenGL / GLX not working===<br />
<br />
I found that Steam / OpenGL / GLX don't work out of the box because the Arch install is different. The issue has to do with sommelier-x. The original crostini [https://chromium.googlesource.com/chromiumos/containers/cros-container-guest-tools/+/master/cros-sommelier-config/postinst cros-container-guest-tools installer] copies the crostini supplied swrast_dri.so to /usr/lib64/dri/ because "mesa always looks at that path" instead of the version of swrast_dri.so supplied with crostini. This line installing swrast_dri.so is not part of the Arch linux installer, and thus OpenGL apps via X11 do not function. Further, on Arch copying this library over in needed for sommelier-x to work with GLX, allowing steam to work, but glxgears/glxinfo need the default mesa-distributed swrast_dri.so. I've been able to get steam & glxgears with the right combination of libraries by running the below commands each time Arch starts up.<br />
<br />
$ glxgears<br />
Error: couldn't get an RGB, Double-buffered visual<br />
<br />
$ sudo cp /usr/lib64/dri/swrast_dri.so /usr/lib64/dri/swrast_dri.so.backup<br />
$ sudo cp /opt/google/cros-containers/lib/swrast_dri.so /usr/lib64/dri/swrast_dri.so<br />
$ systemctl --user restart sommelier-x@0.service<br />
<br />
$ glxinfo<br />
Segmentation fault (core dumped)<br />
<br />
$ sudo cp /usr/lib64/dri/swrast_dri.so.backup /usr/lib64/dri/swrast_dri.so<br />
<br />
$ glxgears<br />
SUCCESS<br />
<br />
<br />
===App that requires sound card not working===<br />
<br />
Crostini does not yet support sound. However, a dummy sound card can be created by installing and running pulseaudio that allows apps that require a sound card to run.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Chrome_OS_devices/Crostini&diff=566031Chrome OS devices/Crostini2019-02-07T21:16:09Z<p>Crescent: Add pulseaudio dummy sound card notes.</p>
<hr />
<div>[[Category:Laptops]]<br />
[[ja:Crostini]]<br />
[https://chromium.googlesource.com/chromiumos/docs/+/master/containers_and_vms.md Crostini] is Google's umbrella term for making Linux application support easy to use and integrating well with Chrome OS.<br />
<br />
This article describes how to install Arch Linux on a Chromebook in a container (via Crostini), without needing to enable developer mode, allowing apps to run alongside other Chrome/Android apps.<br />
<br />
;Advantages<br />
* Don't need to enable developer mode - Officially supported, leaves ChromeOS secure, no need to flash a BIOS etc.<br />
* Better battery life - Battery life of Chrome with the functionality of Linux.<br />
* Access to Android apps, play store etc.<br />
<br />
;Disadvantages<br />
* Audio support is still [https://crbug.com/781398 in progress] (Feb 4 2019)<br />
* OpenGL support is still [https://crbug.com/837073 in progress] (Feb 4 2019)<br />
<br />
== Introduction ==<br />
<br />
=== Enabling Linux support ===<br />
<br />
Look for Linux under Settings and enable it. This installs a Debian Linux container that we will then replace with an Arch Linux container.<br />
<br />
:''Settings > Linux > Enable''<br />
<br />
Crostini is still rolling out to Chromebooks. If you don't see an option to enable Linux, you may need to switch to the beta or developer channel, if it has not rolled out to the stable channel for your laptop yet. This can be done via ''Settings > About Chrome OS > Channel > Dev/Beta''.<br />
<br />
=== Replacing the default Debian Linux container with Arch Linux ===<br />
<br />
The below instructions were taken from https://www.reddit.com/r/Crostini/wiki/howto/run-arch-linux<br />
<br />
1. Install an Arch linux container <br />
<br />
Open a new terminal in Chrome (Ctrl + Alt + T). Then connect to terminal and create an arch linux container:<br />
<br />
vsh termina<br />
run_container.sh --container_name arch --user <gmail username> --lxd_image archlinux/current --lxd_remote https://us.images.linuxcontainers.org/<br />
<br />
The <gmail username> here is the same user you are logged in to your Chromebooks as, without the @gmail.com and dots. eg. foo.bar@gmail.com will set --user foobar. Apps launched from the ChromeOS launcher run under this user.<br />
<br />
2. Replace the default Debian container with Arch Linux.<br />
<br />
The default Debian container is named penguin. Renaming the "arch" container created above to it will cause chrome to launch Linux apps from the arch container.<br />
<br />
lxc stop arch<br />
lxc stop penguin<br />
lxc rename penguin debian<br />
lxc rename arch penguin<br />
<br />
3. Set password for gmail username<br />
<br />
By default the gmail user has no password set. Use lxc exec to set a password:<br />
<br />
lxc exec penguin -- bash<br />
<br />
You also might want to add [[sudo]] and add the user to sudoers.<br />
<br />
4. Install Crostini container tools, Wayland for GUI apps, XWayland for X11 apps.<br />
<br />
First open a console session the the Arch Linux container.<br />
<br />
lxc console penguin<br />
<br />
[[Install]] the {{AUR|cros-container-guest-tools-git}} package. Additionally install {{Pkg|wayland}} and {{Pkg|xorg-server-xwayland}} to be able to use GUI tools.<br />
<br />
At present (11-24-2018) xkeyboard-config 2.24 break the sommelier-x service. Workaround is to comment out two lines starting with "<i372>" and "<i374>" in /usr/share/X11/xkb/keycodes/evdev. Then enable and start the services.<br />
<br />
$ systemctl --user enable sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user enable sommelier-x@0 # For X11 GUI apps<br />
$ systemctl --user start sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user start sommelier-x@0 # For X11 GUI apps<br />
<br />
Make sure these services are running successfully by running:<br />
$ systemctl --user status sommelier@0<br />
$ systemctl --user status sommelier-x@0<br />
<br />
Now, when apps are installed in Arch Linux, they will automatically show up and can be launched from ChromeOS. Note that while GUI apps work, rendering is still software, with no OpenGL support yet.<br />
<br />
==Troubleshooting==<br />
<br />
===Network not working on Pixelbook===<br />
<br />
https://tedyin.com/posts/archlinux-on-pixelbook/ reports that the below setting needs to be set to get the network working on the pixelbook. Make sure to restart your container after you set it.<br />
<br />
lxc profile set default security.syscalls.blacklist "keyctl errno 38"<br />
<br />
===DNS resolution not working===<br />
<br />
DNS resolution stopped working in the container after my install. To get it working again I had to create [[:/etc/resolv.conf]].<br />
<br />
As of Jan 2019, my container wasn't able to resolve ".org" DNS, I had to modify {{man|5|nsswitch.conf}} (only the hosts line).<br />
<br />
hosts: files dns<br />
<br />
===App not opening in chrome OS (infinite spinner)===<br />
<br />
I found that launching a console (lxc console penguin) session prevents apps from launching in Chrome OS. Launching results in an infinite spinner. In that case I have to stop and start the container to get the Chrome OS launcher working<br />
<br />
lxc stop penguin<br />
lxc start penguin<br />
<br />
Instead of using an lxc console session, I use a regular Linux terminal GUI launched from ChomeOS that prevents this issue.<br />
<br />
===Steam / OpenGL / GLX not working===<br />
<br />
I found that Steam / OpenGL / GLX work in a weston instance when the backend is wayland, but don't work when started on the command line. The issue has to do with sommelier-x. The original crostini [https://chromium.googlesource.com/chromiumos/containers/cros-container-guest-tools/+/master/cros-sommelier-config/postinst cros-container-guest-tools installer] copies the crostini supplied swrast_dri.so to /usr/lib64/dri/ because "mesa always looks at that path" instead of the version of swrast_dri.so supplied with crostini. This line installing swrast_dri.so is not part of the Arch linux installer, and thus OpenGL apps via X11 do not function. I've been able to get (steam, glxgears) running when the right combination of libraries from Arch and Crostini are loaded simultaneously (due to caching) via copying various libaries around but it hasn't been consistent. The closet I've achieved consistently is copying the crostini supplied swrast_dri.so to /usr/lib64/dri/. glxinfo and glxgears still don't work after this, but steam runs.<br />
<br />
===App that requires sound card not working===<br />
<br />
Crostini does not yet support sound. However, a dummy sound card can be created by installing and running pulseaudio that allows apps that require a sound card to run.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Chrome_OS_devices/Crostini&diff=566030Chrome OS devices/Crostini2019-02-07T21:14:23Z<p>Crescent: Remove Known issues / working programs - not useful</p>
<hr />
<div>[[Category:Laptops]]<br />
[[ja:Crostini]]<br />
[https://chromium.googlesource.com/chromiumos/docs/+/master/containers_and_vms.md Crostini] is Google's umbrella term for making Linux application support easy to use and integrating well with Chrome OS.<br />
<br />
This article describes how to install Arch Linux on a Chromebook in a container (via Crostini), without needing to enable developer mode, allowing apps to run alongside other Chrome/Android apps.<br />
<br />
;Advantages<br />
* Don't need to enable developer mode - Officially supported, leaves ChromeOS secure, no need to flash a BIOS etc.<br />
* Better battery life - Battery life of Chrome with the functionality of Linux.<br />
* Access to Android apps, play store etc.<br />
<br />
;Disadvantages<br />
* Audio support is still [https://crbug.com/781398 in progress] (Feb 4 2019)<br />
* OpenGL support is still [https://crbug.com/837073 in progress] (Feb 4 2019)<br />
<br />
== Introduction ==<br />
<br />
=== Enabling Linux support ===<br />
<br />
Look for Linux under Settings and enable it. This installs a Debian Linux container that we will then replace with an Arch Linux container.<br />
<br />
:''Settings > Linux > Enable''<br />
<br />
Crostini is still rolling out to Chromebooks. If you don't see an option to enable Linux, you may need to switch to the beta or developer channel, if it has not rolled out to the stable channel for your laptop yet. This can be done via ''Settings > About Chrome OS > Channel > Dev/Beta''.<br />
<br />
=== Replacing the default Debian Linux container with Arch Linux ===<br />
<br />
The below instructions were taken from https://www.reddit.com/r/Crostini/wiki/howto/run-arch-linux<br />
<br />
1. Install an Arch linux container <br />
<br />
Open a new terminal in Chrome (Ctrl + Alt + T). Then connect to terminal and create an arch linux container:<br />
<br />
vsh termina<br />
run_container.sh --container_name arch --user <gmail username> --lxd_image archlinux/current --lxd_remote https://us.images.linuxcontainers.org/<br />
<br />
The <gmail username> here is the same user you are logged in to your Chromebooks as, without the @gmail.com and dots. eg. foo.bar@gmail.com will set --user foobar. Apps launched from the ChromeOS launcher run under this user.<br />
<br />
2. Replace the default Debian container with Arch Linux.<br />
<br />
The default Debian container is named penguin. Renaming the "arch" container created above to it will cause chrome to launch Linux apps from the arch container.<br />
<br />
lxc stop arch<br />
lxc stop penguin<br />
lxc rename penguin debian<br />
lxc rename arch penguin<br />
<br />
3. Set password for gmail username<br />
<br />
By default the gmail user has no password set. Use lxc exec to set a password:<br />
<br />
lxc exec penguin -- bash<br />
<br />
You also might want to add [[sudo]] and add the user to sudoers.<br />
<br />
4. Install Crostini container tools, Wayland for GUI apps, XWayland for X11 apps.<br />
<br />
First open a console session the the Arch Linux container.<br />
<br />
lxc console penguin<br />
<br />
[[Install]] the {{AUR|cros-container-guest-tools-git}} package. Additionally install {{Pkg|wayland}} and {{Pkg|xorg-server-xwayland}} to be able to use GUI tools.<br />
<br />
At present (11-24-2018) xkeyboard-config 2.24 break the sommelier-x service. Workaround is to comment out two lines starting with "<i372>" and "<i374>" in /usr/share/X11/xkb/keycodes/evdev. Then enable and start the services.<br />
<br />
$ systemctl --user enable sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user enable sommelier-x@0 # For X11 GUI apps<br />
$ systemctl --user start sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user start sommelier-x@0 # For X11 GUI apps<br />
<br />
Make sure these services are running successfully by running:<br />
$ systemctl --user status sommelier@0<br />
$ systemctl --user status sommelier-x@0<br />
<br />
Now, when apps are installed in Arch Linux, they will automatically show up and can be launched from ChromeOS. Note that while GUI apps work, rendering is still software, with no OpenGL support yet.<br />
<br />
==Troubleshooting==<br />
<br />
===Network not working on Pixelbook===<br />
<br />
https://tedyin.com/posts/archlinux-on-pixelbook/ reports that the below setting needs to be set to get the network working on the pixelbook. Make sure to restart your container after you set it.<br />
<br />
lxc profile set default security.syscalls.blacklist "keyctl errno 38"<br />
<br />
===DNS resolution not working===<br />
<br />
DNS resolution stopped working in the container after my install. To get it working again I had to create [[:/etc/resolv.conf]].<br />
<br />
As of Jan 2019, my container wasn't able to resolve ".org" DNS, I had to modify {{man|5|nsswitch.conf}} (only the hosts line).<br />
<br />
hosts: files dns<br />
<br />
===App not opening in chrome OS (infinite spinner)===<br />
<br />
I found that launching a console (lxc console penguin) session prevents apps from launching in Chrome OS. Launching results in an infinite spinner. In that case I have to stop and start the container to get the Chrome OS launcher working<br />
<br />
lxc stop penguin<br />
lxc start penguin<br />
<br />
Instead of using an lxc console session, I use a regular Linux terminal GUI launched from ChomeOS that prevents this issue.<br />
<br />
===Steam / OpenGL / GLX not working===<br />
<br />
I found that Steam / OpenGL / GLX work in a weston instance when the backend is wayland, but don't work when started on the command line. The issue has to do with sommelier-x. The original crostini [https://chromium.googlesource.com/chromiumos/containers/cros-container-guest-tools/+/master/cros-sommelier-config/postinst cros-container-guest-tools installer] copies the crostini supplied swrast_dri.so to /usr/lib64/dri/ because "mesa always looks at that path" instead of the version of swrast_dri.so supplied with crostini. This line installing swrast_dri.so is not part of the Arch linux installer, and thus OpenGL apps via X11 do not function. I've been able to get (steam, glxgears) running when the right combination of libraries from Arch and Crostini are loaded simultaneously (due to caching) via copying various libaries around but it hasn't been consistent. The closet I've achieved consistently is copying the crostini supplied swrast_dri.so to /usr/lib64/dri/. glxinfo and glxgears still don't work after this, but steam runs.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Chrome_OS_devices/Crostini&diff=566026Chrome OS devices/Crostini2019-02-07T19:58:18Z<p>Crescent: Update GLX not working wording</p>
<hr />
<div>[[Category:Laptops]]<br />
[[ja:Crostini]]<br />
[https://chromium.googlesource.com/chromiumos/docs/+/master/containers_and_vms.md Crostini] is Google's umbrella term for making Linux application support easy to use and integrating well with Chrome OS.<br />
<br />
This article describes how to install Arch Linux on a Chromebook in a container (via Crostini), without needing to enable developer mode, allowing apps to run alongside other Chrome/Android apps.<br />
<br />
;Advantages<br />
* Don't need to enable developer mode - Officially supported, leaves ChromeOS secure, no need to flash a BIOS etc.<br />
* Better battery life - Battery life of Chrome with the functionality of Linux.<br />
* Access to Android apps, play store etc.<br />
<br />
;Disadvantages<br />
* Audio support is still [https://crbug.com/781398 in progress] (Feb 4 2019)<br />
* OpenGL support is still [https://crbug.com/837073 in progress] (Feb 4 2019)<br />
<br />
== Introduction ==<br />
<br />
=== Enabling Linux support ===<br />
<br />
Look for Linux under Settings and enable it. This installs a Debian Linux container that we will then replace with an Arch Linux container.<br />
<br />
:''Settings > Linux > Enable''<br />
<br />
Crostini is still rolling out to Chromebooks. If you don't see an option to enable Linux, you may need to switch to the beta or developer channel, if it has not rolled out to the stable channel for your laptop yet. This can be done via ''Settings > About Chrome OS > Channel > Dev/Beta''.<br />
<br />
=== Replacing the default Debian Linux container with Arch Linux ===<br />
<br />
The below instructions were taken from https://www.reddit.com/r/Crostini/wiki/howto/run-arch-linux<br />
<br />
1. Install an Arch linux container <br />
<br />
Open a new terminal in Chrome (Ctrl + Alt + T). Then connect to terminal and create an arch linux container:<br />
<br />
vsh termina<br />
run_container.sh --container_name arch --user <gmail username> --lxd_image archlinux/current --lxd_remote https://us.images.linuxcontainers.org/<br />
<br />
The <gmail username> here is the same user you are logged in to your Chromebooks as, without the @gmail.com and dots. eg. foo.bar@gmail.com will set --user foobar. Apps launched from the ChromeOS launcher run under this user.<br />
<br />
2. Replace the default Debian container with Arch Linux.<br />
<br />
The default Debian container is named penguin. Renaming the "arch" container created above to it will cause chrome to launch Linux apps from the arch container.<br />
<br />
lxc stop arch<br />
lxc stop penguin<br />
lxc rename penguin debian<br />
lxc rename arch penguin<br />
<br />
3. Set password for gmail username<br />
<br />
By default the gmail user has no password set. Use lxc exec to set a password:<br />
<br />
lxc exec penguin -- bash<br />
<br />
You also might want to add [[sudo]] and add the user to sudoers.<br />
<br />
4. Install Crostini container tools, Wayland for GUI apps, XWayland for X11 apps.<br />
<br />
First open a console session the the Arch Linux container.<br />
<br />
lxc console penguin<br />
<br />
[[Install]] the {{AUR|cros-container-guest-tools-git}} package. Additionally install {{Pkg|wayland}} and {{Pkg|xorg-server-xwayland}} to be able to use GUI tools.<br />
<br />
At present (11-24-2018) xkeyboard-config 2.24 break the sommelier-x service. Workaround is to comment out two lines starting with "<i372>" and "<i374>" in /usr/share/X11/xkb/keycodes/evdev. Then enable and start the services.<br />
<br />
$ systemctl --user enable sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user enable sommelier-x@0 # For X11 GUI apps<br />
$ systemctl --user start sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user start sommelier-x@0 # For X11 GUI apps<br />
<br />
Make sure these services are running successfully by running:<br />
$ systemctl --user status sommelier@0<br />
$ systemctl --user status sommelier-x@0<br />
<br />
Now, when apps are installed in Arch Linux, they will automatically show up and can be launched from ChromeOS. Note that while GUI apps work, rendering is still software, with no OpenGL support yet.<br />
<br />
==Known issues==<br />
Tested, working (2018-11-24)<br />
* Pycharm<br />
<br />
Tested, not working (2018-11-24 - no hardware acceleration, audio)<br />
* Gnome (No OpenGL)<br />
* glxgears (No OpenGL)<br />
* Audacity (No recording devices)<br />
<br />
==Troubleshooting==<br />
<br />
===Network not working on Pixelbook===<br />
<br />
https://tedyin.com/posts/archlinux-on-pixelbook/ reports that the below setting needs to be set to get the network working on the pixelbook. Make sure to restart your container after you set it.<br />
<br />
lxc profile set default security.syscalls.blacklist "keyctl errno 38"<br />
<br />
===DNS resolution not working===<br />
<br />
DNS resolution stopped working in the container after my install. To get it working again I had to create [[:/etc/resolv.conf]].<br />
<br />
As of Jan 2019, my container wasn't able to resolve ".org" DNS, I had to modify {{man|5|nsswitch.conf}} (only the hosts line).<br />
<br />
hosts: files dns<br />
<br />
===App not opening in chrome OS (infinite spinner)===<br />
<br />
I found that launching a console (lxc console penguin) session prevents apps from launching in Chrome OS. Launching results in an infinite spinner. In that case I have to stop and start the container to get the Chrome OS launcher working<br />
<br />
lxc stop penguin<br />
lxc start penguin<br />
<br />
Instead of using an lxc console session, I use a regular Linux terminal GUI launched from ChomeOS that prevents this issue.<br />
<br />
===Steam / OpenGL / GLX not working===<br />
<br />
I found that Steam / OpenGL / GLX work in a weston instance when the backend is wayland, but don't work when started on the command line. The issue has to do with sommelier-x. The original crostini [https://chromium.googlesource.com/chromiumos/containers/cros-container-guest-tools/+/master/cros-sommelier-config/postinst cros-container-guest-tools installer] copies the crostini supplied swrast_dri.so to /usr/lib64/dri/ because "mesa always looks at that path" instead of the version of swrast_dri.so supplied with crostini. This line installing swrast_dri.so is not part of the Arch linux installer, and thus OpenGL apps via X11 do not function. I've been able to get (steam, glxgears) running when the right combination of libraries from Arch and Crostini are loaded simultaneously (due to caching) via copying various libaries around but it hasn't been consistent. The closet I've achieved consistently is copying the crostini supplied swrast_dri.so to /usr/lib64/dri/. glxinfo and glxgears still don't work after this, but steam runs.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Chrome_OS_devices/Crostini&diff=566025Chrome OS devices/Crostini2019-02-07T19:56:01Z<p>Crescent: Fix link</p>
<hr />
<div>[[Category:Laptops]]<br />
[[ja:Crostini]]<br />
[https://chromium.googlesource.com/chromiumos/docs/+/master/containers_and_vms.md Crostini] is Google's umbrella term for making Linux application support easy to use and integrating well with Chrome OS.<br />
<br />
This article describes how to install Arch Linux on a Chromebook in a container (via Crostini), without needing to enable developer mode, allowing apps to run alongside other Chrome/Android apps.<br />
<br />
;Advantages<br />
* Don't need to enable developer mode - Officially supported, leaves ChromeOS secure, no need to flash a BIOS etc.<br />
* Better battery life - Battery life of Chrome with the functionality of Linux.<br />
* Access to Android apps, play store etc.<br />
<br />
;Disadvantages<br />
* Audio support is still [https://crbug.com/781398 in progress] (Feb 4 2019)<br />
* OpenGL support is still [https://crbug.com/837073 in progress] (Feb 4 2019)<br />
<br />
== Introduction ==<br />
<br />
=== Enabling Linux support ===<br />
<br />
Look for Linux under Settings and enable it. This installs a Debian Linux container that we will then replace with an Arch Linux container.<br />
<br />
:''Settings > Linux > Enable''<br />
<br />
Crostini is still rolling out to Chromebooks. If you don't see an option to enable Linux, you may need to switch to the beta or developer channel, if it has not rolled out to the stable channel for your laptop yet. This can be done via ''Settings > About Chrome OS > Channel > Dev/Beta''.<br />
<br />
=== Replacing the default Debian Linux container with Arch Linux ===<br />
<br />
The below instructions were taken from https://www.reddit.com/r/Crostini/wiki/howto/run-arch-linux<br />
<br />
1. Install an Arch linux container <br />
<br />
Open a new terminal in Chrome (Ctrl + Alt + T). Then connect to terminal and create an arch linux container:<br />
<br />
vsh termina<br />
run_container.sh --container_name arch --user <gmail username> --lxd_image archlinux/current --lxd_remote https://us.images.linuxcontainers.org/<br />
<br />
The <gmail username> here is the same user you are logged in to your Chromebooks as, without the @gmail.com and dots. eg. foo.bar@gmail.com will set --user foobar. Apps launched from the ChromeOS launcher run under this user.<br />
<br />
2. Replace the default Debian container with Arch Linux.<br />
<br />
The default Debian container is named penguin. Renaming the "arch" container created above to it will cause chrome to launch Linux apps from the arch container.<br />
<br />
lxc stop arch<br />
lxc stop penguin<br />
lxc rename penguin debian<br />
lxc rename arch penguin<br />
<br />
3. Set password for gmail username<br />
<br />
By default the gmail user has no password set. Use lxc exec to set a password:<br />
<br />
lxc exec penguin -- bash<br />
<br />
You also might want to add [[sudo]] and add the user to sudoers.<br />
<br />
4. Install Crostini container tools, Wayland for GUI apps, XWayland for X11 apps.<br />
<br />
First open a console session the the Arch Linux container.<br />
<br />
lxc console penguin<br />
<br />
[[Install]] the {{AUR|cros-container-guest-tools-git}} package. Additionally install {{Pkg|wayland}} and {{Pkg|xorg-server-xwayland}} to be able to use GUI tools.<br />
<br />
At present (11-24-2018) xkeyboard-config 2.24 break the sommelier-x service. Workaround is to comment out two lines starting with "<i372>" and "<i374>" in /usr/share/X11/xkb/keycodes/evdev. Then enable and start the services.<br />
<br />
$ systemctl --user enable sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user enable sommelier-x@0 # For X11 GUI apps<br />
$ systemctl --user start sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user start sommelier-x@0 # For X11 GUI apps<br />
<br />
Make sure these services are running successfully by running:<br />
$ systemctl --user status sommelier@0<br />
$ systemctl --user status sommelier-x@0<br />
<br />
Now, when apps are installed in Arch Linux, they will automatically show up and can be launched from ChromeOS. Note that while GUI apps work, rendering is still software, with no OpenGL support yet.<br />
<br />
==Known issues==<br />
Tested, working (2018-11-24)<br />
* Pycharm<br />
<br />
Tested, not working (2018-11-24 - no hardware acceleration, audio)<br />
* Gnome (No OpenGL)<br />
* glxgears (No OpenGL)<br />
* Audacity (No recording devices)<br />
<br />
==Troubleshooting==<br />
<br />
===Network not working on Pixelbook===<br />
<br />
https://tedyin.com/posts/archlinux-on-pixelbook/ reports that the below setting needs to be set to get the network working on the pixelbook. Make sure to restart your container after you set it.<br />
<br />
lxc profile set default security.syscalls.blacklist "keyctl errno 38"<br />
<br />
===DNS resolution not working===<br />
<br />
DNS resolution stopped working in the container after my install. To get it working again I had to create [[:/etc/resolv.conf]].<br />
<br />
As of Jan 2019, my container wasn't able to resolve ".org" DNS, I had to modify {{man|5|nsswitch.conf}} (only the hosts line).<br />
<br />
hosts: files dns<br />
<br />
===App not opening in chrome OS (infinite spinner)===<br />
<br />
I found that launching a console (lxc console penguin) session prevents apps from launching in Chrome OS. Launching results in an infinite spinner. In that case I have to stop and start the container to get the Chrome OS launcher working<br />
<br />
lxc stop penguin<br />
lxc start penguin<br />
<br />
Instead of using an lxc console session, I use a regular Linux terminal GUI launched from ChomeOS that prevents this issue.<br />
<br />
===Steam / OpenGL / GLX not working===<br />
<br />
I found that Steam / OpenGL / GLX work in a weston instance when the backend is wayland, but don't work when started on the command line. The issue has to do with sommelier-x. The original crostini [https://chromium.googlesource.com/chromiumos/containers/cros-container-guest-tools/+/master/cros-sommelier-config/postinst cros-container-guest-tools installer] copies the crostini supplied swrast_dri.so to /usr/lib64/dri/ because "mesa always looks at that path" instead of the version of swrast_dri.so supplied with crostini. This line installing swrast_dri.so is not part of the Arch linux installer, and thus OpenGL apps via X11 do not function. I've been able to get them running when the right combination of libraries from Arch and Crostini are loaded simultaneously (due to caching) but it hasn't been consistent. The closet I've achieved consistently after copying the crostini supplied swrast_dri.so to /usr/lib64/dri/ glxinfo and glxgears still don't work, but steam runs after this.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Chrome_OS_devices/Crostini&diff=566024Chrome OS devices/Crostini2019-02-07T19:55:02Z<p>Crescent: Update instructions on getting GLX working via X11 for Steam</p>
<hr />
<div>[[Category:Laptops]]<br />
[[ja:Crostini]]<br />
[https://chromium.googlesource.com/chromiumos/docs/+/master/containers_and_vms.md Crostini] is Google's umbrella term for making Linux application support easy to use and integrating well with Chrome OS.<br />
<br />
This article describes how to install Arch Linux on a Chromebook in a container (via Crostini), without needing to enable developer mode, allowing apps to run alongside other Chrome/Android apps.<br />
<br />
;Advantages<br />
* Don't need to enable developer mode - Officially supported, leaves ChromeOS secure, no need to flash a BIOS etc.<br />
* Better battery life - Battery life of Chrome with the functionality of Linux.<br />
* Access to Android apps, play store etc.<br />
<br />
;Disadvantages<br />
* Audio support is still [https://crbug.com/781398 in progress] (Feb 4 2019)<br />
* OpenGL support is still [https://crbug.com/837073 in progress] (Feb 4 2019)<br />
<br />
== Introduction ==<br />
<br />
=== Enabling Linux support ===<br />
<br />
Look for Linux under Settings and enable it. This installs a Debian Linux container that we will then replace with an Arch Linux container.<br />
<br />
:''Settings > Linux > Enable''<br />
<br />
Crostini is still rolling out to Chromebooks. If you don't see an option to enable Linux, you may need to switch to the beta or developer channel, if it has not rolled out to the stable channel for your laptop yet. This can be done via ''Settings > About Chrome OS > Channel > Dev/Beta''.<br />
<br />
=== Replacing the default Debian Linux container with Arch Linux ===<br />
<br />
The below instructions were taken from https://www.reddit.com/r/Crostini/wiki/howto/run-arch-linux<br />
<br />
1. Install an Arch linux container <br />
<br />
Open a new terminal in Chrome (Ctrl + Alt + T). Then connect to terminal and create an arch linux container:<br />
<br />
vsh termina<br />
run_container.sh --container_name arch --user <gmail username> --lxd_image archlinux/current --lxd_remote https://us.images.linuxcontainers.org/<br />
<br />
The <gmail username> here is the same user you are logged in to your Chromebooks as, without the @gmail.com and dots. eg. foo.bar@gmail.com will set --user foobar. Apps launched from the ChromeOS launcher run under this user.<br />
<br />
2. Replace the default Debian container with Arch Linux.<br />
<br />
The default Debian container is named penguin. Renaming the "arch" container created above to it will cause chrome to launch Linux apps from the arch container.<br />
<br />
lxc stop arch<br />
lxc stop penguin<br />
lxc rename penguin debian<br />
lxc rename arch penguin<br />
<br />
3. Set password for gmail username<br />
<br />
By default the gmail user has no password set. Use lxc exec to set a password:<br />
<br />
lxc exec penguin -- bash<br />
<br />
You also might want to add [[sudo]] and add the user to sudoers.<br />
<br />
4. Install Crostini container tools, Wayland for GUI apps, XWayland for X11 apps.<br />
<br />
First open a console session the the Arch Linux container.<br />
<br />
lxc console penguin<br />
<br />
[[Install]] the {{AUR|cros-container-guest-tools-git}} package. Additionally install {{Pkg|wayland}} and {{Pkg|xorg-server-xwayland}} to be able to use GUI tools.<br />
<br />
At present (11-24-2018) xkeyboard-config 2.24 break the sommelier-x service. Workaround is to comment out two lines starting with "<i372>" and "<i374>" in /usr/share/X11/xkb/keycodes/evdev. Then enable and start the services.<br />
<br />
$ systemctl --user enable sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user enable sommelier-x@0 # For X11 GUI apps<br />
$ systemctl --user start sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user start sommelier-x@0 # For X11 GUI apps<br />
<br />
Make sure these services are running successfully by running:<br />
$ systemctl --user status sommelier@0<br />
$ systemctl --user status sommelier-x@0<br />
<br />
Now, when apps are installed in Arch Linux, they will automatically show up and can be launched from ChromeOS. Note that while GUI apps work, rendering is still software, with no OpenGL support yet.<br />
<br />
==Known issues==<br />
Tested, working (2018-11-24)<br />
* Pycharm<br />
<br />
Tested, not working (2018-11-24 - no hardware acceleration, audio)<br />
* Gnome (No OpenGL)<br />
* glxgears (No OpenGL)<br />
* Audacity (No recording devices)<br />
<br />
==Troubleshooting==<br />
<br />
===Network not working on Pixelbook===<br />
<br />
https://tedyin.com/posts/archlinux-on-pixelbook/ reports that the below setting needs to be set to get the network working on the pixelbook. Make sure to restart your container after you set it.<br />
<br />
lxc profile set default security.syscalls.blacklist "keyctl errno 38"<br />
<br />
===DNS resolution not working===<br />
<br />
DNS resolution stopped working in the container after my install. To get it working again I had to create [[:/etc/resolv.conf]].<br />
<br />
As of Jan 2019, my container wasn't able to resolve ".org" DNS, I had to modify {{man|5|nsswitch.conf}} (only the hosts line).<br />
<br />
hosts: files dns<br />
<br />
===App not opening in chrome OS (infinite spinner)===<br />
<br />
I found that launching a console (lxc console penguin) session prevents apps from launching in Chrome OS. Launching results in an infinite spinner. In that case I have to stop and start the container to get the Chrome OS launcher working<br />
<br />
lxc stop penguin<br />
lxc start penguin<br />
<br />
Instead of using an lxc console session, I use a regular Linux terminal GUI launched from ChomeOS that prevents this issue.<br />
<br />
===Steam / OpenGL / GLX not working===<br />
<br />
I found that Steam / OpenGL / GLX work in a weston instance when the backend is wayland, but don't work when started on the command line. The issue has to do with sommelier-x. The original crostini [cros-container-guest-tools installer https://chromium.googlesource.com/chromiumos/containers/cros-container-guest-tools/+/master/cros-sommelier-config/postinst] copies the crostini supplied swrast_dri.so to /usr/lib64/dri/ because "mesa always looks at that path" instead of the version of swrast_dri.so supplied with crostini. This line installing swrast_dri.so is not part of the Arch linux installer, and thus OpenGL apps via X11 do not function. I've been able to get them running when the right combination of libraries from Arch and Crostini are loaded simultaneously (due to caching) but it hasn't been consistent. The closet I've achieved consistently after copying the crostini supplied swrast_dri.so to /usr/lib64/dri/ glxinfo and glxgears still don't work, but steam runs after this.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Chrome_OS_devices/Crostini&diff=565927Chrome OS devices/Crostini2019-02-06T04:32:46Z<p>Crescent: Add links to audio/opengl support WIP bugs</p>
<hr />
<div>[[Category:Laptops]]<br />
[[ja:Crostini]]<br />
[https://chromium.googlesource.com/chromiumos/docs/+/master/containers_and_vms.md Crostini] is Google's umbrella term for making Linux application support easy to use and integrating well with Chrome OS.<br />
<br />
This article describes how to install Arch Linux on a Chromebook in a container (via Crostini), without needing to enable developer mode, allowing apps to run alongside other Chrome/Android apps.<br />
<br />
;Advantages<br />
* Don't need to enable developer mode - Officially supported, leaves ChromeOS secure, no need to flash a BIOS etc.<br />
* Better battery life - Battery life of Chrome with the functionality of Linux.<br />
* Access to Android apps, play store etc.<br />
<br />
;Disadvantages<br />
* Audio support is still [https://crbug.com/781398 in progress] (Feb 4 2019)<br />
* OpenGL support is still [https://crbug.com/837073 in progress] (Feb 4 2019)<br />
<br />
== Introduction ==<br />
<br />
=== Enabling Linux support ===<br />
<br />
Look for Linux under Settings and enable it. This installs a Debian Linux container that we will then replace with an Arch Linux container.<br />
<br />
:''Settings > Linux > Enable''<br />
<br />
Crostini is still rolling out to Chromebooks. If you don't see an option to enable Linux, you may need to switch to the beta or developer channel, if it has not rolled out to the stable channel for your laptop yet. This can be done via ''Settings > About Chrome OS > Channel > Dev/Beta''.<br />
<br />
=== Replacing the default Debian Linux container with Arch Linux ===<br />
<br />
The below instructions were taken from https://www.reddit.com/r/Crostini/wiki/howto/run-arch-linux<br />
<br />
1. Install an Arch linux container <br />
<br />
Open a new terminal in Chrome (Ctrl + Alt + T). Then connect to terminal and create an arch linux container:<br />
<br />
vsh termina<br />
run_container.sh --container_name arch --user <gmail username> --lxd_image archlinux/current --lxd_remote https://us.images.linuxcontainers.org/<br />
<br />
The <gmail username> here is the same user you are logged in to your Chromebooks as, without the @gmail.com and dots. eg. foo.bar@gmail.com will set --user foobar. Apps launched from the ChromeOS launcher run under this user.<br />
<br />
2. Replace the default Debian container with Arch Linux.<br />
<br />
The default Debian container is named penguin. Renaming the "arch" container created above to it will cause chrome to launch Linux apps from the arch container.<br />
<br />
lxc stop arch<br />
lxc stop penguin<br />
lxc rename penguin debian<br />
lxc rename arch penguin<br />
<br />
3. Set password for gmail username<br />
<br />
By default the gmail user has no password set. Use lxc exec to set a password:<br />
<br />
lxc exec penguin -- bash<br />
<br />
You also might want to add [[sudo]] and add the user to sudoers.<br />
<br />
4. Install Crostini container tools, Wayland for GUI apps, XWayland for X11 apps.<br />
<br />
First open a console session the the Arch Linux container.<br />
<br />
lxc console penguin<br />
<br />
[[Install]] the {{AUR|cros-container-guest-tools-git}} package. Additionally install {{Pkg|wayland}} and {{Pkg|xorg-server-xwayland}} to be able to use GUI tools.<br />
<br />
At present (11-24-2018) xkeyboard-config 2.24 break the sommelier-x service. Workaround is to comment out two lines starting with "<i372>" and "<i374>" in /usr/share/X11/xkb/keycodes/evdev. Then enable and start the services.<br />
<br />
$ systemctl --user enable sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user enable sommelier-x@0 # For X11 GUI apps<br />
$ systemctl --user start sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user start sommelier-x@0 # For X11 GUI apps<br />
<br />
Make sure these services are running successfully by running:<br />
$ systemctl --user status sommelier@0<br />
$ systemctl --user status sommelier-x@0<br />
<br />
Now, when apps are installed in Arch Linux, they will automatically show up and can be launched from ChromeOS. Note that while GUI apps work, rendering is still software, with no OpenGL support yet.<br />
<br />
==Known issues==<br />
Tested, working (2018-11-24)<br />
* Pycharm<br />
<br />
Tested, not working (2018-11-24 - no hardware acceleration, audio)<br />
* Gnome (No OpenGL)<br />
* glxgears (No OpenGL)<br />
* Audacity (No recording devices)<br />
<br />
==Troubleshooting==<br />
<br />
===Network not working on Pixelbook===<br />
<br />
https://tedyin.com/posts/archlinux-on-pixelbook/ reports that the below setting needs to be set to get the network working on the pixelbook. Make sure to restart your container after you set it.<br />
<br />
lxc profile set default security.syscalls.blacklist "keyctl errno 38"<br />
<br />
===DNS resolution not working===<br />
<br />
DNS resolution stopped working in the container after my install. To get it working again I had to create [[:/etc/resolv.conf]].<br />
<br />
As of Jan 2019, my container wasn't able to resolve ".org" DNS, I had to modify {{man|5|nsswitch.conf}} (only the hosts line).<br />
<br />
hosts: files dns<br />
<br />
===App not opening in chrome OS (infinite spinner)===<br />
<br />
I found that launching a console (lxc console penguin) session prevents apps from launching in Chrome OS. Launching results in an infinite spinner. In that case I have to stop and start the container to get the Chrome OS launcher working<br />
<br />
lxc stop penguin<br />
lxc start penguin<br />
<br />
Instead of using an lxc console session, I use a regular Linux terminal GUI launched from ChomeOS that prevents this issue.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Chrome_OS_devices/Crostini&diff=557719Chrome OS devices/Crostini2018-11-28T21:24:27Z<p>Crescent: Add line about Crostini and link to Google page providing details.</p>
<hr />
<div>[[Category:Laptops]]<br />
[[ja:Chrome OS デバイス]]<br />
<br />
[https://chromium.googlesource.com/chromiumos/docs/+/master/containers_and_vms.md Crostini] is Google's umbrella term for making Linux application support easy to use and integrating well with Chrome OS.<br />
<br />
This article describes how to install Arch Linux on a Chromebook in a container (via Crostini), without needing to enable developer mode, allowing apps to run alongside other Chrome/Android apps.<br />
<br />
;Advantages<br />
* Don't need to enable developer mode - Officially supported, leaves ChromeOS secure, no need to flash a BIOS etc.<br />
* Better battery life - Battery life of Chrome with the functionality of Linux.<br />
* Access to Android apps, play store etc.<br />
<br />
;Disadvantages<br />
* No OpenGL support yet (24-11-2018)<br />
* No sound support yet (24-11-2018)<br />
<br />
== Introduction ==<br />
<br />
=== Enabling Linux support ===<br />
<br />
Look for Linux under Settings and enable it. This installs a Debian Linux container that we will then replace with an Arch Linux container.<br />
<br />
:''Settings > Linux > Enable''<br />
<br />
Crostini is still rolling out to Chromebooks. If you don't see an option to enable Linux, you may need to switch to the beta or developer channel, if it has not rolled out to the stable channel for your laptop yet. This can be done via ''Settings > About Chrome OS > Channel > Dev/Beta''.<br />
<br />
=== Replacing the default Debian Linux container with Arch Linux ===<br />
<br />
The below instructions were taken from https://www.reddit.com/r/Crostini/wiki/howto/run-arch-linux<br />
<br />
1. Install an Arch linux container <br />
<br />
Open a new terminal in Chrome (Alt + Shift + T). Then connect to terminal and create an arch linux container:<br />
<br />
vsh termina<br />
run_container.sh --container_name arch --user <gmail username> --lxd_image archlinux/current --lxd_remote https://us.images.linuxcontainers.org/<br />
<br />
The <gmail username> here is the same user you are logged in to your Chromebooks as, without the @gmail.com. eg. foobar@gmail.com will set --user foobar. Apps launched from the ChromeOS launcher run under this user.<br />
<br />
2. Replace the default Debian container with Arch Linux.<br />
<br />
The default Debian container is named penguin. Renaming the "arch" container created above to it will cause chrome to launch Linux apps from the arch container.<br />
<br />
lxc stop arch<br />
lxc stop penguin<br />
lxc rename penguin debian<br />
lxc rename arch penguin<br />
<br />
3. Install Crostini container tools, Wayland for GUI apps, XWayland for X11 apps.<br />
<br />
First open a console session the the Arch Linux container.<br />
<br />
lxc console penguin<br />
<br />
[[Install]] the {{AUR|cros-container-guest-tools-git}} package. Additionally install {{Pkg|wayland}} and {{Pkg|xorg-server-xwayland}} to be able to use GUI tools.<br />
<br />
At present (11-24-2018) xkeyboard-config 2.24 break the sommelier-x service. Workaround is to comment out two lines starting with "<i372>" and "<i374>" in /usr/share/X11/xkb/keycodes/evdev. Then enable and start the services.<br />
<br />
$ systemctl --user enable sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user enable sommelier-x@0 # For X11 GUI apps<br />
$ systemctl --user start sommelier@0 # For Wayland GUI apps<br />
$ systemctl --user start sommelier-x@0 # For X11 GUI apps<br />
<br />
Make sure these services are running successfully by running:<br />
$ systemctl --user status sommelier@0<br />
$ systemctl --user status sommelier-x@0<br />
<br />
Now, when apps are installed in Arch Linux, they will automatically show up and can be launched from ChromeOS. Note that while GUI apps work, rendering is still software, with no OpenGL support yet.<br />
<br />
==Known issues==<br />
Tested, working (2018-11-24)<br />
* Pycharm<br />
<br />
Tested, not working (2018-11-24 - no hardware acceleration, audio)<br />
* Gnome (No OpenGL)<br />
* glxgears (No OpenGL)<br />
* Audacity (No recording devices)<br />
<br />
==Troubleshooting==<br />
<br />
===Network not working on Pixelbook===<br />
<br />
https://tedyin.com/posts/archlinux-on-pixelbook/ reports that the below setting needs to be set to get the network working on the pixelbook. Make sure to restart your container after you set it.<br />
<br />
lxc profile set default security.syscalls.blacklist "keyctl errno 38"<br />
<br />
===DNS resolution not working===<br />
<br />
DNS resolution stopped working in the container after my install. To get it working again I had to create [[:/etc/resolv.conf]].<br />
<br />
===App not opening in chrome OS (infinite spinner)===<br />
<br />
I found that launching a console (lxc console penguin) session prevents apps from launching in Chrome OS. Launching results in an infinite spinner. In that case I have to stop and start the container to get the Chrome OS launcher working<br />
<br />
lxc stop penguin<br />
lxc start penguin<br />
<br />
Instead of using an lxc console session, I use a regular Linux terminal GUI launched from ChomeOS that prevents this issue.</div>Crescenthttps://wiki.archlinux.org/index.php?title=Chrome_OS_devices&diff=557200Chrome OS devices2018-11-25T05:39:45Z<p>Crescent: update wording to explain this psage is about installing ChromeOS "by activating developer mode"</p>
<hr />
<div>[[Category:Laptops]]<br />
[[ja:Chrome OS デバイス]]<br />
{{Related articles start}}<br />
{{Related|Chrome OS devices/Crostini}}<br />
{{Related|Chrome OS devices/Chromebook}}<br />
{{Related|Chrome OS devices/Custom firmware}}<br />
{{Related|Installation guide}}<br />
{{Related|Laptop}}<br />
{{Related articles end}}<br />
{{Warning|This article relies on third-party scripts and modifications, and may irreparably damage your hardware or data. Proceed at your own risk.}}<br />
This article was created to provide information on how to get Arch installed on the series of Chrome OS devices built by Acer, HP, Samsung, Toshiba, and Google. Currently this page is being overhauled, and more model specific pages are being built with some of the information listed below. <br />
<br />
{{Note|This article describes how to install Arch Linux by activating developer mode. For instructions on how to install Arch Linux in a ChromeOS container without having to enable developer mode see [[Chrome OS devices/Crostini|Crostini]]}}<br />
<br />
== Introduction ==<br />
<br />
=== Legacy Boot Mode ===<br />
<br />
All recent Intel-based Chrome OS devices (starting with the 2013 Chromebook Pixel) feature a Legacy Boot Mode, designed to allow the user to boot Linux. Legacy Boot Mode has a dedicated firmware region, {{ic|RW_LEGACY}}, which is designed to be user-writeable (hence the 'RW' notation) and is completely separate from the ChromeOS portion of the firmware (ie, it is safe to update and cannot brick the device). It is enabled by the [http://www.coreboot.org/SeaBIOS SeaBIOS] payload of [http://www.coreboot.org/ coreboot], the open-source firmware used for all Chrome OS devices (with the exception of the first generation of Chromebooks and a few early ARM models). SeaBIOS behaves like a traditional BIOS that boots into the MBR of the disk, and from there into standard bootloaders like Syslinux and GRUB.<br />
<br />
Models with a Core-i based SoC (Haswell, Broadwell, Skylake, KabyLake) mostly ship with a functional Legacy Boot Mode payload; updating to a 3rd party build can provide bug fixes and additional features. Models with an Atom-based SoC (Baytrail, Braswell, Apollolake) have Legacy Boot Mode capability, but do not ship with a RW_LEGACY/SeaBIOS payload (that part of the firmware is blank). These models require a 3rd party RW_LEGACY firmware to be loaded for Legacy Boot Mode to be functional.<br />
<br />
<br />
==== Models without Legacy Boot Mode/SeaBIOS ====<br />
<br />
One of the following approaches can be taken in order to install Arch Linux on Chrome OS devices which did not ship with SeaBIOS as part of the installed firmware:<br />
<br />
* If the device supports Legacy Boot Mode, but does not ship with a functional {{ic|RW_LEGACY}} payload (or doesn't ship with one at all), one can flash a SeaBIOS payload to the {{ic|RW_LEGACY}} part of the firmware. This is 100% safe, as it writes to a user-writeable area of the firmware image which is completely separate from/does not affect ChromeOS. The easiest way to install/update the RW_LEGACY firmware on your ChromeOS device is via MrChromebox's [[Chrome_OS_devices/Custom_firmware#Flashing_with_MrChromebox.27s_Firmware_Utility_Script|Firmware Utility Script]], which supports the widest range of devices and offers the most up-to-date SeaBIOS builds; one can also update the {{ic|RW_LEGACY}} firmware manually with Chrome OS' {{ic|flashrom}} (requires downloading/compiling your own build), or use John Lewis' {{ic|flash_chromebook_rom.sh}} script (no longer supported).<br />
<br />
* Flash a full [[Custom firmware for Chrome OS devices|custom firmware]] which includes either a SeaBIOS or UEFI payload, and removes all the ChromeOS-specific parts.<br />
<br />
* Flash the {{ic|BOOT_STUB}} part of the firmware. This method replaces the stock ChromeOS payload (depthcharge) with SeaBIOS. This is theoretically a safer approach than flashing the full firmware but there might be some limitations (e.g. no support in suspend or VMX). This is the {{ic|Modify ROM to run SeaBIOS exclusively}} option in John Lewis' {{ic|flash_chromebook_rom.sh}} script and {{ic|Flash BOOT_STUB firmware}} option in MrChromebox's.<br />
<br />
* Take the ChrUbuntu approach which uses the Chrome OS kernel and modules.<br />
<br />
* Build and sign your own kernel, see [https://plus.google.com/+OlofJohansson/posts/34PYU79eUqP] [http://pomozok.wordpress.com/2014/10/11/building-chromeos-kernel-without-chroot/] [https://github.com/drsn0w/chromebook_kernel_tools/blob/master/install_linux.md].<br />
<br />
The [[#Installation|Installation]] process described on this page tries to cover the method of installing Arch Linux on models without SeaBIOS by flashing a custom firmware.<br />
<br />
=== Firmware write protection intro ===<br />
<br />
All Chrome OS devices features firmware write protection, which restricts write access to certain regions of the flash chip. It is important to be aware of it as one might need to disable the hardware write protection as part of the installation process (to update GBB flags or flash a custom firmware).<br />
<br />
For more details see [[Custom firmware for Chrome OS devices#Firmware write protection|Firmware write protection]].<br />
<br />
=== Prerequisites ===<br />
<br />
* You should claim your free 100GB-1TB of Google Drive space before you install Arch. This needs to happen from ChromeOS(version > 23), not linux. This will sync/backup ChromeOS, as designed<br />
* Visit the ArchWiki page for your [[#Chrome OS devices|Chrome OS device]].<br />
* If there is no ArchWiki page for your device then before proceeding, gather information about the device and if you succeed in installing Arch Linux, then consider adding a new ArchWiki page for your model (you can use the [[Acer C720]] as an example for device shipped with SeaBios or the [[Acer_C710_Chromebook|Acer C710]] as device that did not ship with it).<br />
* Read this guide completely and make sure you understand all the steps before making any changes.<br />
<br />
== Chrome OS devices ==<br />
<br />
See [[Chrome_OS_devices/Chromebook|Chromebook models]] for hardware comparison with details about SeaBIOS availability and storage expansion.<br />
<br />
=== General hardware recommendations and remarks ===<br />
<br />
* MyDigitalSSD M.2 NGFF SSD drives are probably the most popular choice when upgrading the internal SSD of a Chrome OS device. There are multiple accounts of failing MyDigitalSSD SSD drives at the Acer C720 topic on the Arch forums [https://bbs.archlinux.org/viewtopic.php?pid=1461993#p1461993] [https://bbs.archlinux.org/viewtopic.php?pid=1474680#p1474680] [https://bbs.archlinux.org/viewtopic.php?pid=1460460#p1460460] and much more on the web. If the SSD was upgraded to a MyDigitalSSD model then it is highly recommended to backup the system and data frequently. It might be advisable to upgrade the SDD with a different brand. Notice that this might be due to a SSD firmware issue so updating the SSD firmware is highly recommended.<br />
* Transcend MTS400 M.2 NGFF SSD drives are failing (at least with stock Coreboot firmware) when ALPM is enabled, ATM there is no SSD firmware update that fixing this bug, so it is highly advisable to disabled ALPM if a power management daemon has been installed (which enabled it), see [[Solid_State_Drives#Resolving_SATA_power_management_related_errors|Resolving SATA power management related errors]] and [http://superuser.com/questions/887916/transcend-mts400-ssd-crashes-my-acer-c720-chromebook-how-to-disable-sata-power how to disable ALPM in Chrome OS].<br />
<br />
== Installation ==<br />
<br />
{{Warning|Installation on ChromeOS devices that do not ship with SeaBIOS requires flashing a custom firmware, certain types of which have the potential to brick your device. Proceed at your own risk.}}<br />
<br />
{{Note|While the following information should fit all the ChromeOS devices with coreboot firmware (shipped with SeaBIOS payload or without), it is possible that with some models you may need to make further adjustments.}}<br />
<br />
The general installation procedure:<br />
* Enable developer mode.<br />
* ChromeOS device with functional Legacy Boot Mode/SeaBIOS:<br />
** Enable Legacy Boot Mode.<br />
** Set SeaBIOS as default (optional but highly recommended, requires disabling the write protection).<br />
* ChromeOS device without functional Legacy Boot Mode:<br />
** Flash one of the following types of custom firmware<br />
*** Flash RW_LEGACY firmware (zero risk)<br />
*** Flash BOOT_STUB firmware (very low risk).<br />
*** Flash Full custom firmware (low risk).<br />
* Prepare the installation media.<br />
* Boot Arch Linux installation media and install Arch.<br />
<br />
=== Enabling developer mode ===<br />
<br />
[http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/acer-c720-chromebook#TOC-Developer-Mode Developer Mode] is necessary in order to access the superuser shell inside ChromeOS, which is required for making changes to the system like allow booting through SeaBIOS.<br />
<br />
{{Warning|Enabling Developer Mode will wipe all of your data.}}<br />
<br />
To enable developer mode: <br />
<br />
* Press and hold the {{ic|Esc + F3 (Refresh)}} keys, then press the {{ic|Power}} button. This enters Recovery Mode.<br />
** Chromeboxes have a dedicated Recovery button, which should be pressed/held while powering on<br />
* Press {{ic|Ctrl + D}} (no prompt). It will ask you to confirm, then the system will revert its state and enable Developer Mode.<br />
{{Note|Press {{ic|Ctrl + D}} (or wait 30 seconds for the beep and boot) at the white boot splash screen to enter ChromeOS.}}<br />
<br />
=== Accessing the superuser shell ===<br />
<br />
After you have enabled the Developer Mode you will need to access the superuser shell. How you do this depends on whether you have configured ChromeOS or not.<br />
<br />
==== Accessing the superuser shell without logging into ChromeOS ====<br />
<br />
If you have not configured ChromeOS, just press {{ic|Ctrl + Alt + F2}} (F2 is the "forward" arrow on the top row, →), you will see a login prompt.<br />
<br />
* Use {{ic|chronos}} as the username, it should not prompt you for a password.<br />
* Become superuser with [[sudo]], use the command {{ic|sudo su -}}.<br />
<br />
==== Accessing the superuser shell when logged into ChromeOS ====<br />
<br />
If you have configured ChromeOS already:<br />
<br />
* Open a crosh window with {{ic|Ctrl + Alt + T}}.<br />
* Open a bash shell with the {{ic|shell}} command.<br />
* Become superuser with [[sudo]], use the command {{ic|sudo su -}} to accomplish that.<br />
<br />
=== Enabling Legacy Boot Mode ===<br />
<br />
If your ChromeOS device did not ship with Legacy Boot Mode support via SeaBIOS, or you prefer to install a custom firmware, then continue to [[#Flashing a custom firmware|Flashing a custom firmware]].<br />
<br />
This will enable the pre-installed version of SeaBIOS through the Developer Mode screen in coreboot.<br />
<br />
* Inside your superuser shell enter:<br />
# crossystem dev_boot_legacy=1<br />
* Reboot the machine.<br />
<br />
You can now start SeaBIOS by pressing {{ic|Ctrl + L}} at the white boot splash screen.<br />
<br />
{{Note|If you intend to stay using pre-installed SeaBIOS route and think you will not appreciate having to press {{ic|Ctrl + L}} every time you boot to reach SeaBIOS, then you can set coreboot to boot to SeaBIOS by default. This requires disabling the hardware firmware write protection.}}<br />
<br />
You should now have SeaBIOS enabled on your ChromeOS device, if you choose to not set it as default then you can continue to [[#Installing Arch Linux|Installing Arch Linux]].<br />
<br />
==== Boot to SeaBIOS by default ====<br />
<br />
To boot SeaBIOS by default, you will need to run the [https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/master/scripts/image_signing/set_gbb_flags.sh {{ic|set_gbb_flags.sh}}] script, which is part of ChromeOS. The script uses flashrom and gbb_utility to read the RO_GBB firmware region, modify the flags, and write it back to flash. The GBB flags can also be set using MrChromebox's [https://mrchromebox.tech/#fwscript Firmware Utility Script] under either ChromeOS or Arch (the latter requiring booting with specific kernel parameters to relax memory access restrictions).<br />
<br />
{{Warning|If you do not set the GBB flags, then a fully discharged or disconnected battery will reset {{ic|dev_boot_legacy}} crossystem flag to its default value, removing the ability to boot in Legacy Boot Mode. While this used to require you to recover Chrome OS and wipe your Arch Linux installation on the internal storage, the GalliumOS developers have created a set of "fixflags" recovery images, which rather than wiping internal storage, will instead simply re-set the {{ic|dev_boot_legacy}} crossystem flag. See [https://galliumos.org/fixflags galliumos.org/fixflags]}}<br />
<br />
* Disable the hardware write protection.<br />
<br />
To find the location of the hardware write-protect screw/switch/jumper and how to disable it visit the ArchWiki page for your [[#Chrome OS devices|ChromeOS device]]. If there is no information about your device on the ArchWiki then turn to [http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices Developer Information for ChromeOS Devices] and [http://www.coreboot.org/Chromebooks coreboot's Chromebooks page].<br />
<br />
More information about the firmware protection available at the [[Custom firmware for ChromeOS devices#Firmware write protection|Custom firmware for ChromeOS devices]] page.<br />
<br />
* Switch to the [[#Accessing the superuser shell|superuser shell]].<br />
<br />
* Disable the software write protection.<br />
# flashrom --wp-disable<br />
<br />
* Check that write protection is disabled.<br />
# flashrom --wp-status<br />
<br />
* Run {{ic|set_gbb_flags.sh}} with no parameters.<br />
# /usr/share/vboot/bin/set_gbb_flags.sh<br />
<br />
* This will list all of the available flags. The ones of interest to us are:<br />
GBB_FLAG_DEV_SCREEN_SHORT_DELAY 0x00000001<br />
GBB_FLAG_FORCE_DEV_SWITCH_ON 0x00000008<br />
GBB_FLAG_FORCE_DEV_BOOT_LEGACY 0x00000080<br />
GBB_FLAG_DEFAULT_DEV_BOOT_LEGACY 0x00000400<br />
<br />
* So, to set SeaBIOS as default, with a 1s timeout, prevent accidentally exiting Developer Mode via spacebar, and ensure Legacy Boot Mode remains enabled in the event of battery drain/disconnect, we set the flags as such:<br />
# /usr/share/vboot/bin/set_gbb_flags.sh 0x489<br />
<br />
* Enable back the software write protection.<br />
# flashrom --wp-enable<br />
<br />
{{Note|All of these steps are automated by MrChromebox's Firmware Utility Script, so if using that to install/update your RW_LEGACY firmware, easiest to just set the flags via the script as well.}}<br />
<br />
Your ChromeOS device now will boot to SeaBIOS by default, you can continue to [[#Installing Arch Linux|Installing Arch Linux]], if your device is booting correctly then you can optionally re-enable the hardware write protection.<br />
<br />
=== Flashing a custom firmware ===<br />
<br />
{{Note|The following steps explain how to flash a custom firmware from ChromeOS, for information on how to flash a custom firmware from Arch Linux visit the [[Custom firmware for ChromeOS devices]] page}}<br />
<br />
* Disable the hardware write protection.<br />
<br />
To find the location of the hardware write-protect screw/switch/jumper and how to disable it visit the ArchWiki page for your [[#Chrome OS devices|ChromeOS device]]. If there is no information about your device on the ArchWiki then turn to [http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devicesDeveloper Information for ChromeOS Devices] and [http://www.coreboot.org/Chromebooks coreboot's Chromebooks page].<br />
<br />
More information about the firmware protection available at the [[Custom firmware for ChromeOS devices#Firmware write protection|Custom firmware for ChromeOS devices]] page.<br />
<br />
* Enter the command to run either MrChromebox's or John Lewis's firmware script.<br />
<br />
{{Note|The reason for not posting here is to force you to visit the site and read the instructions before proceeding.}}<br />
<br />
* After the exiting the script, be sure to copy the backed up firmware to an external storage before rebooting the system (if the script doesn't provide that option for you).<br />
<br />
You should now have a custom firmware installed on your device, cross your fingers and reboot.<br />
<br />
After flashing the firmware you can continue to [[#Installing Arch Linux|Installing Arch Linux]].<br />
<br />
=== Installing Arch Linux ===<br />
<br />
==== Preparing the installation media ====<br />
<br />
Create an [[USB flash installation media|Arch Linux Installer USB drive]].<br />
<br />
{{Note|If the USB loads but fails to boot into Arch, it may be due a bug in the syslinux the current (2017.03.01) installer uses. The 2016.11.01 version from the [[Arch Linux Archive]] will work until the issue is resolved.}}<br />
<br />
==== Booting the installation media ====<br />
<br />
* Plug the USB drive to the ChromeOS device and start SeaBIOS with {{ic|Ctrl + L}} at the white boot splash screen (if SeaBIOS is not set as default).<br />
* Press {{ic|Esc}} to get a boot menu and select the number corresponding to your USB drive.<br />
<br />
The Arch Linux installer boot menu should appear and the [[Installation guide|installation]] process can proceed as normal.<br />
<br />
{{Note|For now choose [[GRUB]] as your bootloader: you can choose MBR or GPT: [[Partitioning]]. If you choose GPT then do not forget to add a [[GRUB#GUID_Partition_Table_.28GPT.29_specific_instructions|BIOS Boot Partition]]. Also see [[#Syslinux|Known Issues]].}}<br />
<br />
After finishing installing Arch Linux continue by following the [[#Post installation configuration|Post Installation Configuration]].<br />
<br />
== Post installation configuration ==<br />
<br />
=== Patched kernels ===<br />
{{Note|You can most likely ignore this section unless your device requires patched kernel support.}}<br />
<br />
It is recommended to use the official {{Pkg|linux}} package for most Chrome OS devices with the exception being newer devices which might need patched kernel support such as the Chromebook Pixel 2015.<br />
<br />
{{AUR|linux-samus4}} provides patches for the Chromebook Pixel 2015 to fix touchpad, touchscreen, and sound functionality which has not been merged into upstream linux yet. More information is available at [https://github.com/raphael/linux-samus its GitHub page].<br />
<br />
If your devices requires a patched kernel, it is advised to review the list of patches and decide if the patch list is getting decidedly small enough that you no longer require a patched kernel and instead you can use the official {{Pkg|linux}} package instead. <br />
<br />
See [[kernels]] for more information.<br />
<br />
=== Video driver ===<br />
<br />
See [[Intel graphics]].<br />
<br />
=== Touchpad and touchscreen ===<br />
<br />
See [[Touchpad Synaptics]], [[libinput]], and [[Touchscreen]].<br />
<br />
==== Touchpad and touchscreen kernel modules ====<br />
<br />
Since kernel 3.17 all the related patches merged into the upstream sources, meaning the {{Pkg|linux}} package in core supports these devices.<br />
<br />
===== What to do if your touchpad or touchscreen is not supported? =====<br />
<br />
* Review the list of patches in {{Aur|linux-chromebook}}{{Broken package link|{{aur-mirror|linux-chromebook}}}}, if a related patch for your Chromebook model exist then [[#Patched kernels|install this package]].<br />
* If there is no such patch do not worry as the developers should be able to add it by request as the Chromium OS sources includes the related changes.<br />
* You can also try to find the related commits by yourself and create a proper patch, some hints:<br />
** Dig into your Chrome OS system, look at the obvious suspects like boot log, {{ic|/proc/bus/input/devices}} and {{ic|/sys/devices}}.<br />
** The Linux kernel sources for Chromium OS are at [https://chromium.googlesource.com/chromiumos/third_party/kernel].<br />
** Each kernel source for the latest Chromium OS release has its own branch, name convention: {{ic|release-R*-*-chromeos-KERNELVER}}, where {{ic|R*-*}} is the Chromium OS release and {{ic|KERNELVER}} is the kernel version.<br />
** Review the git log of {{ic|drivers/platform}}, {{ic|drivers/i2c/busses}} and {{ic|drivers/input/touchscreen}}.<br />
* {{AUR|linux-samus4}} includes touchpad and touchscreen support for the Chromebook Pixel 2015. More information is available at [https://github.com/raphael/linux-samus its GitHub page].<br />
<br />
==== Touchpad configuration ====<br />
<br />
There are few options how to set the touchpad:<br />
<br />
* Visit the ArchWiki page for your Chromebook model (see [[#Chromebook_Models|Chromebook models]]{{Broken section link}}) for touchpad xorg.conf.d file.<br />
* Use a [[Touchpad_Synaptics#Configuration_on_the_fly|touchpad configuration tool]].<br />
<br />
==== Chromium OS input drivers ====<br />
<br />
{{Out of date|{{ic|xf86-input-cmt}} development is not active and it is probably not needed anymore in any case since [[libinput]]'s compatibility with Chrome OS devices's touchpads is fairly good.}}<br />
<br />
{{AUR|xf86-input-cmt}} offers a port of the Chromium OS input driver: [https://github.com/hugegreenbug/xf86-input-cmt xf86-input-cmt] as an alternative for the [[Synaptics|Synaptics input driver]]. It provides tweaked configuration files for most devices, and provides functionality that the [[Synaptics|Synaptics input driver]] does not such as palm rejection. Additionally, it enables functionality not enabled by default in the Chromium OS input driver such as tap-to-drag.<br />
<br />
Please note, the input driver does not work under [https://github.com/hugegreenbug/xf86-input-cmt/issues/5 some circumstances] where you have insufficient permissions to access {{ic|/dev/input/event}}<br />
This will affect you if you use [[startx]] to load a DE/WM session.<br />
If this is the case or if the driver does not load for any other cases, you should run:<br />
# usermod -a -G input $USER<br />
Where $USER is the current user wanting to use the input driver.<br />
<br />
It should also be noted that some users have reported the driver does not work in [[GDM]] but works normally after log in.<br />
If you are affected by this, you should run:<br />
# usermod -a -G input gdm<br />
<br />
After reboot, you should be able to use the touchpad normally.<br />
<br />
=== Fixing suspend ===<br />
{{Note|Lid suspend might not work directly after boot, you might need to wait a little.}}<br />
<br />
The following are instructions to fix the suspend functionality.<br />
Users of a pre-installed SeaBIOS or John Lewis' pre-built SeaBIOS you will need this fix.<br />
This procedure is not needed with Matt DeVillier's custom firmware since problematic ACPI wake devices (such as {{ic|TPAD}}) are firmware-disabled.<br />
<br />
There have been a few alternatives discussed and those may work better for some. [https://bbs.archlinux.org/viewtopic.php?pid=1364376#p1364376] [https://bbs.archlinux.org/viewtopic.php?pid=1364521#p1364521]<br />
<br />
To fix suspend, the general idea is to disable the EHCI_PCI module, which interferes with the suspend cycle. There are multiple ways to achieve this.<br />
<br />
==== With kernel parameters ====<br />
{{Note|Blacklisting ehci_pci has no effect on dmesg ehci errors as of kernel 4.18.11}}<br />
Add the following to your GRUB configuration:-<br />
<br />
{{hc|head=/etc/default/grub|<br />
output=GRUB_CMDLINE_LINUX_DEFAULT="modprobe.blacklist=ehci_pci"}}<br />
<br />
Then [[GRUB#Generate_the_main_configuration_file|rebuild your grub config]]. After rebuilding your GRUB config, reboot your computer.<br />
<br />
==== With systemd ====<br />
<br />
Sometimes the synaptics touchpad, and various other parts of the laptop are used as wakeup devices causing certain movements of the laptop during suspend to end suspend. In order to disable all wakeup devices except for the laptop lid sensor, create the following {{ic|suspend-device-fix.sh}} file. <br />
<br />
{{hc|head=/usr/local/sbin/suspend-device-fix.sh|<br />
output=<nowiki>#!/bin/bash<br />
<br />
awk '{if ($1 != "LID0" && $3 == "*enabled") print $1}' < /proc/acpi/wakeup | while read NAME<br />
do echo "$NAME" > /proc/acpi/wakeup<br />
done<br />
<br />
exit 0<br />
</nowiki>}}<br />
<br />
Now give the file executable permissions:<br />
# chmod +x /usr/local/sbin/suspend-device-fix.sh<br />
<br />
Create a systemd service to execute the script on every boot. <br />
{{hc|head=/etc/systemd/system/suspend-fix.service|<br />
output=[Unit]<br />
Description=Suspend Fix<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=/usr/local/sbin/suspend-device-fix.sh<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
First [[start]] {{ic|suspend-fix.service}}. If it properly starts, then [[enable]] it to be started on bootup.<br />
<br />
Add the following line at the end of {{ic|/etc/rc.d/rc.local}} (if it does not exist, just create it) to prevent bad handling of EHCI USB:<br />
<br />
{{hc|head=/etc/rc.d/rc.local|<br />
output=<nowiki><br />
echo 1 > /sys/devices/pci0000\:00/0000\:00\:1d.0/remove<br />
</nowiki>}}<br />
<br />
Then, create the following {{ic|cros-sound-suspend.sh}} file. Only the Ath9k binding/unbinding lines are listed below; see the alternatives linked above for additional sound suspend handling if you experience issues.<br />
<br />
{{hc|head=/usr/lib/systemd/system-sleep/cros-sound-suspend.sh|<br />
output=<nowiki>#!/bin/bash<br />
<br />
case $1/$2 in<br />
pre/*)<br />
# Unbind ath9k for preventing error and full sleep mode (wakeup by LID after hibernating) <br />
echo -n "0000:01:00.0" | tee /sys/bus/pci/drivers/ath9k/unbind<br />
# Unbind snd_hda_intel for sound<br />
echo -n "0000:00:1b.0" | tee /sys/bus/pci/drivers/snd_hda_intel/unbind<br />
echo -n "0000:00:03.0" | tee /sys/bus/pci/drivers/snd_hda_intel/unbind<br />
;;<br />
post/*)<br />
# Bind ath9k for preventing error and and full sleep mode (wakeup by LID after hibernating) <br />
echo -n "0000:01:00.0" | tee /sys/bus/pci/drivers/ath9k/bind<br />
# bind snd_hda_intel for sound<br />
echo -n "0000:00:1b.0" | tee /sys/bus/pci/drivers/snd_hda_intel/bind<br />
echo -n "0000:00:03.0" | tee /sys/bus/pci/drivers/snd_hda_intel/bind<br />
;;<br />
esac</nowiki>}}<br />
<br />
Make sure to make the script executable:<br />
# chmod +x /usr/lib/systemd/system-sleep/cros-sound-suspend.sh<br />
<br />
Then [[GRUB#Generate_the_main_configuration_file|rebuild your grub config]].<br />
<br />
=== Fixing audio ===<br />
<br />
==== Baytrail based models ====<br />
<br />
Most baytrail models ''worked'' on {{Pkg|linux}} but a regression introduced in 4.18.15 broke it, see bug report [https://lkml.org/lkml/2018/10/30/676]. Either, rollback to 4.18.14, compile your own kernel using this patch [https://patchwork.kernel.org/patch/10667953], or, install linux-max98090 from unofficial user repo [https://github.com/duffydack/linux-max98090]. It is likely that you will also need to use {{ic|alsamixer}} from {{Pkg|alsa-utils}} to turn on "Left Speaker Mixer Left DAC" and "Right Speaker Mixer Right DAC". For more information, see [https://bugs.archlinux.org/task/48936].<br />
<br />
==== Haswell based models ====<br />
<br />
One or more of followings might help solving audio related issues, setting {{ic|snd_hda_intel}} module index reported the most useful. It is highly possible that you will not need to make any change.<br />
<br />
* Create {{ic|/etc/modprobe.d/alsa.conf}}, the option {{ic|index}} will make sure the analog output is the default (and not HDMI), the option {{ic|model}} will notify the driver our board model which will make the built-in microphone usable (you can try instead {{ic|<nowiki>model=alc283-sense-combo</nowiki>}} or {{ic|<nowiki>model=,alc283-dac-wcaps</nowiki>}}). <br />
<br />
{{hc|head=/etc/modprobe.d/alsa.conf|<br />
output=options snd_hda_intel index=1 model=,alc283-chrome}}<br />
<br />
* Use the {{ic|~/.asoundrc}} file from [https://gist.githubusercontent.com/dhead666/52d6d7d97eff76935713/raw/5b32ee11a2ebbe7a3ee0f928e49b980361a57548/.asoundrc].<br />
<br />
* If having problems with headphones (perhaps no audio playing), try {{ic|alsactl restore}} in terminal. Now, ALSA should automatically switch between channels when using headphones/speakers. <br />
<br />
* To fix [[Flash]] audio with PulseAudio, use the {{ic|~/.asoundrc}} file from [https://gist.githubusercontent.com/dhead666/0eebff16cd9578c5e035/raw/d4c974fcd50565bf116c57b1884170ecb47f8bf6/.asoundrc].<br />
<br />
==== Chromebook Pixel 2015 ====<br />
<br />
{{AUR|linux-samus4}} includes a patch for Broadwell SoC sound devices. [https://github.com/raphael/linux-samus Its GitHub page] includes additional instructions for initializing the sound device.<br />
<br />
=== Hotkeys ===<br />
<br />
[https://support.google.com/chromebook/answer/1047364?hl=en The Chromebook function keys] recognized as standard F1-F10 by the kernel, it is preferable to map them accordingly to their appearance. It would also be nice to get the keys {{ic|Delete, Home, End, PgUp, PgDown}} which in Chrome OS mapped to {{ic|Alt + : BackSpace, Right, Left, Up, Down}}.<br />
<br />
==== xkeyboard configuration ====<br />
<br />
{{Pkg|xkeyboard-config}} 2.16-1 added a {{ic|chromebook}} model that enables the Chrome OS style functions for the function keys. You can, for example, set this using {{ic|localectl set-x11-keymap us chromebook}}. See the {{ic|chromebook}} definition in {{ic|/usr/share/X11/xkb/symbols/inet}} for the full mappings.<br />
<br />
==== Sxhkd configuration ====<br />
<br />
One way to set the hotkeys would be by using the [[Sxhkd]] daemon. Besides {{Pkg|sxhkd}}, this also requires [[Advanced Linux Sound Architecture|amixer]], {{Pkg|xorg-xbacklight}}, and {{Pkg|xautomation}}.<br />
<br />
* See [https://gist.github.com/dhead666/191722ec04842d8d330b] for an example configuration in {{ic|~/.config/sxhkd/sxhkdrc}}.<br />
<br />
==== Xbindkeys configuration ====<br />
<br />
Another way to configure hotkeys would be by using [[Xbindkeys]]. Besides {{Pkg|xbindkeys}} this requires [[Advanced Linux Sound Architecture|amixer]] and {{Pkg|xorg-xbacklight}} and {{AUR|xvkbd}}.<br />
<br />
* See [https://gist.github.com/dhead666/08562a9a760b18b6e758] for an example configuration in {{ic|~/.xbindkeysrc}}.<br />
* See [https://bbs.archlinux.org/viewtopic.php?id=173418&p=3 vilefridge's xbindkeys configuration] for another example.<br />
<br />
===== Alternate xbindkeys configuration =====<br />
<br />
[http://pastie.org/9550960 Volchange] (originated in the [http://www.debianuserforums.org/viewtopic.php?f=55&t=1453#p14351 Debian User Forums])) can manipulate the volume with PulseAudio instead of using [[Advanced Linux Sound Architecture|amixer]]. Besides [http://pastie.org/9550960 Volchange] this requires {{Pkg|xorg-xbacklight}} and {{AUR|xvkbd}}.<br />
<br />
* Download the script from [http://pastie.org/9550960].<br />
* Make it executable <br />
$ chmod u+x ~/.local/bin/volchange<br />
<br />
See [https://gist.github.com/dhead666/4e23b506441ad424e26e] for a matching {{ic|~/.xbindkeysrc}}.<br />
<br />
==== Patch xkeyboard-config ====<br />
<br />
Another option is to install {{AUR|xkeyboard-config-chromebook}}, for more details visit [https://github.com/dhead666/archlinux-pkgbuilds/tree/master/xkeyboard-config-chromebook].<br />
<br />
==== Mapping in Gnome with gsettings set ====<br />
<br />
Some of the function keys can be mapped in Gnome with the advantage of HUD notifications on changes (like volume and brightness changes) which can supplement one of the mapping methods mentioned above. This [https://gist.github.com/dhead666/0b9c1cc9def939705594 linked example] maps the brightness and volume actions. Notice that {{Pkg|xdotool}} is required.<br />
<br />
=== Power key and lid switch handling ===<br />
<br />
==== Ignore using logind ====<br />
<br />
Out of the box, {{ic|systemd-logind}} will catch power key and lid switch events and handle them: it will shut down the Chromebook on a power key press, and a suspend on a lid close. However, this policy might be a bit harsh given that the power key is an ordinary key at the top right of the keyboard that might be pressed accidentally.<br />
<br />
To configure logind to ignore power key presses and lid switches, add the lines to {{ic|logind.conf}} below.<br />
<br />
{{hc|head=/etc/systemd/logind.conf|<br />
output=HandlePowerKey=ignore<br />
HandleLidSwitch=ignore}}<br />
<br />
Then [[restart]] logind for the changes to take effect.<br />
<br />
Power key and lid switch events will still be logged to journald by logind. See [[Power management#ACPI events]].<br />
<br />
==== Ignore by Gnome ====<br />
<br />
[[Install]] {{Pkg|gnome-tweaks}}, open the Tweak Tool and under Power change the Power Button Action.<br />
<br />
== Known issues ==<br />
<br />
=== Syslinux ===<br />
<br />
Follow Syslinux installation instructions carefully. Try manual installation to see where the problem comes from. If you see [[Syslinux#Missing_operating_system|Missing Operation System]] then it may be because you need to use correct bootloader binary. If syslinux does not work try another [[bootloader]] such as [[GRUB]].<br />
<br />
== See also ==<br />
<br />
* [http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices Developer Information for Chrome OS Devices at the Chromium Projects site]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=173418 BBS topic about the Acer C720] which include generic information on Haswell Based Chromebooks.<br />
* Re-partitioning in Chrome OS [http://chromeos-cr48.blogspot.co.uk/2012/04/chrubuntu-1204-now-with-double-bits.html], [http://goo.gl/i817v]<br />
* [http://bit.ly/NewChromebooks Brent Sullivan's the always updated list of Chrome OS devices]<br />
* [http://prodct.info/chromebooks/ Google Chromebook Comparison Chart]</div>Crescenthttps://wiki.archlinux.org/index.php?title=Chrome_OS_devices&diff=557195Chrome OS devices2018-11-25T02:56:08Z<p>Crescent: Add related to Crostini link</p>
<hr />
<div>[[Category:Laptops]]<br />
[[ja:Chrome OS デバイス]]<br />
{{Related articles start}}<br />
{{Related|Chrome OS devices/Crostini}}<br />
{{Related|Chrome OS devices/Chromebook}}<br />
{{Related|Chrome OS devices/Custom firmware}}<br />
{{Related|Installation guide}}<br />
{{Related|Laptop}}<br />
{{Related articles end}}<br />
{{Warning|This article relies on third-party scripts and modifications, and may irreparably damage your hardware or data. Proceed at your own risk.}}<br />
This article was created to provide information on how to get Arch installed on the series of Chrome OS devices built by Acer, HP, Samsung, Toshiba, and Google. Currently this page is being overhauled, and more model specific pages are being built with some of the information listed below. <br />
<br />
{{Note|This article describes how to install Linux in dual boot mode. For instructions on how to install Arch Linux in a ChromeOS container without having to enable developer mode see [[Chrome OS devices/Crostini|Crostini]]}}<br />
<br />
== Introduction ==<br />
<br />
=== Legacy Boot Mode ===<br />
<br />
All recent Intel-based Chrome OS devices (starting with the 2013 Chromebook Pixel) feature a Legacy Boot Mode, designed to allow the user to boot Linux. Legacy Boot Mode has a dedicated firmware region, {{ic|RW_LEGACY}}, which is designed to be user-writeable (hence the 'RW' notation) and is completely separate from the ChromeOS portion of the firmware (ie, it is safe to update and cannot brick the device). It is enabled by the [http://www.coreboot.org/SeaBIOS SeaBIOS] payload of [http://www.coreboot.org/ coreboot], the open-source firmware used for all Chrome OS devices (with the exception of the first generation of Chromebooks and a few early ARM models). SeaBIOS behaves like a traditional BIOS that boots into the MBR of the disk, and from there into standard bootloaders like Syslinux and GRUB.<br />
<br />
Models with a Core-i based SoC (Haswell, Broadwell, Skylake, KabyLake) mostly ship with a functional Legacy Boot Mode payload; updating to a 3rd party build can provide bug fixes and additional features. Models with an Atom-based SoC (Baytrail, Braswell, Apollolake) have Legacy Boot Mode capability, but do not ship with a RW_LEGACY/SeaBIOS payload (that part of the firmware is blank). These models require a 3rd party RW_LEGACY firmware to be loaded for Legacy Boot Mode to be functional.<br />
<br />
<br />
==== Models without Legacy Boot Mode/SeaBIOS ====<br />
<br />
One of the following approaches can be taken in order to install Arch Linux on Chrome OS devices which did not ship with SeaBIOS as part of the installed firmware:<br />
<br />
* If the device supports Legacy Boot Mode, but does not ship with a functional {{ic|RW_LEGACY}} payload (or doesn't ship with one at all), one can flash a SeaBIOS payload to the {{ic|RW_LEGACY}} part of the firmware. This is 100% safe, as it writes to a user-writeable area of the firmware image which is completely separate from/does not affect ChromeOS. The easiest way to install/update the RW_LEGACY firmware on your ChromeOS device is via MrChromebox's [[Chrome_OS_devices/Custom_firmware#Flashing_with_MrChromebox.27s_Firmware_Utility_Script|Firmware Utility Script]], which supports the widest range of devices and offers the most up-to-date SeaBIOS builds; one can also update the {{ic|RW_LEGACY}} firmware manually with Chrome OS' {{ic|flashrom}} (requires downloading/compiling your own build), or use John Lewis' {{ic|flash_chromebook_rom.sh}} script (no longer supported).<br />
<br />
* Flash a full [[Custom firmware for Chrome OS devices|custom firmware]] which includes either a SeaBIOS or UEFI payload, and removes all the ChromeOS-specific parts.<br />
<br />
* Flash the {{ic|BOOT_STUB}} part of the firmware. This method replaces the stock ChromeOS payload (depthcharge) with SeaBIOS. This is theoretically a safer approach than flashing the full firmware but there might be some limitations (e.g. no support in suspend or VMX). This is the {{ic|Modify ROM to run SeaBIOS exclusively}} option in John Lewis' {{ic|flash_chromebook_rom.sh}} script and {{ic|Flash BOOT_STUB firmware}} option in MrChromebox's.<br />
<br />
* Take the ChrUbuntu approach which uses the Chrome OS kernel and modules.<br />
<br />
* Build and sign your own kernel, see [https://plus.google.com/+OlofJohansson/posts/34PYU79eUqP] [http://pomozok.wordpress.com/2014/10/11/building-chromeos-kernel-without-chroot/] [https://github.com/drsn0w/chromebook_kernel_tools/blob/master/install_linux.md].<br />
<br />
The [[#Installation|Installation]] process described on this page tries to cover the method of installing Arch Linux on models without SeaBIOS by flashing a custom firmware.<br />
<br />
=== Firmware write protection intro ===<br />
<br />
All Chrome OS devices features firmware write protection, which restricts write access to certain regions of the flash chip. It is important to be aware of it as one might need to disable the hardware write protection as part of the installation process (to update GBB flags or flash a custom firmware).<br />
<br />
For more details see [[Custom firmware for Chrome OS devices#Firmware write protection|Firmware write protection]].<br />
<br />
=== Prerequisites ===<br />
<br />
* You should claim your free 100GB-1TB of Google Drive space before you install Arch. This needs to happen from ChromeOS(version > 23), not linux. This will sync/backup ChromeOS, as designed<br />
* Visit the ArchWiki page for your [[#Chrome OS devices|Chrome OS device]].<br />
* If there is no ArchWiki page for your device then before proceeding, gather information about the device and if you succeed in installing Arch Linux, then consider adding a new ArchWiki page for your model (you can use the [[Acer C720]] as an example for device shipped with SeaBios or the [[Acer_C710_Chromebook|Acer C710]] as device that did not ship with it).<br />
* Read this guide completely and make sure you understand all the steps before making any changes.<br />
<br />
== Chrome OS devices ==<br />
<br />
See [[Chrome_OS_devices/Chromebook|Chromebook models]] for hardware comparison with details about SeaBIOS availability and storage expansion.<br />
<br />
=== General hardware recommendations and remarks ===<br />
<br />
* MyDigitalSSD M.2 NGFF SSD drives are probably the most popular choice when upgrading the internal SSD of a Chrome OS device. There are multiple accounts of failing MyDigitalSSD SSD drives at the Acer C720 topic on the Arch forums [https://bbs.archlinux.org/viewtopic.php?pid=1461993#p1461993] [https://bbs.archlinux.org/viewtopic.php?pid=1474680#p1474680] [https://bbs.archlinux.org/viewtopic.php?pid=1460460#p1460460] and much more on the web. If the SSD was upgraded to a MyDigitalSSD model then it is highly recommended to backup the system and data frequently. It might be advisable to upgrade the SDD with a different brand. Notice that this might be due to a SSD firmware issue so updating the SSD firmware is highly recommended.<br />
* Transcend MTS400 M.2 NGFF SSD drives are failing (at least with stock Coreboot firmware) when ALPM is enabled, ATM there is no SSD firmware update that fixing this bug, so it is highly advisable to disabled ALPM if a power management daemon has been installed (which enabled it), see [[Solid_State_Drives#Resolving_SATA_power_management_related_errors|Resolving SATA power management related errors]] and [http://superuser.com/questions/887916/transcend-mts400-ssd-crashes-my-acer-c720-chromebook-how-to-disable-sata-power how to disable ALPM in Chrome OS].<br />
<br />
== Installation ==<br />
<br />
{{Warning|Installation on ChromeOS devices that do not ship with SeaBIOS requires flashing a custom firmware, certain types of which have the potential to brick your device. Proceed at your own risk.}}<br />
<br />
{{Note|While the following information should fit all the ChromeOS devices with coreboot firmware (shipped with SeaBIOS payload or without), it is possible that with some models you may need to make further adjustments.}}<br />
<br />
The general installation procedure:<br />
* Enable developer mode.<br />
* ChromeOS device with functional Legacy Boot Mode/SeaBIOS:<br />
** Enable Legacy Boot Mode.<br />
** Set SeaBIOS as default (optional but highly recommended, requires disabling the write protection).<br />
* ChromeOS device without functional Legacy Boot Mode:<br />
** Flash one of the following types of custom firmware<br />
*** Flash RW_LEGACY firmware (zero risk)<br />
*** Flash BOOT_STUB firmware (very low risk).<br />
*** Flash Full custom firmware (low risk).<br />
* Prepare the installation media.<br />
* Boot Arch Linux installation media and install Arch.<br />
<br />
=== Enabling developer mode ===<br />
<br />
[http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/acer-c720-chromebook#TOC-Developer-Mode Developer Mode] is necessary in order to access the superuser shell inside ChromeOS, which is required for making changes to the system like allow booting through SeaBIOS.<br />
<br />
{{Warning|Enabling Developer Mode will wipe all of your data.}}<br />
<br />
To enable developer mode: <br />
<br />
* Press and hold the {{ic|Esc + F3 (Refresh)}} keys, then press the {{ic|Power}} button. This enters Recovery Mode.<br />
** Chromeboxes have a dedicated Recovery button, which should be pressed/held while powering on<br />
* Press {{ic|Ctrl + D}} (no prompt). It will ask you to confirm, then the system will revert its state and enable Developer Mode.<br />
{{Note|Press {{ic|Ctrl + D}} (or wait 30 seconds for the beep and boot) at the white boot splash screen to enter ChromeOS.}}<br />
<br />
=== Accessing the superuser shell ===<br />
<br />
After you have enabled the Developer Mode you will need to access the superuser shell. How you do this depends on whether you have configured ChromeOS or not.<br />
<br />
==== Accessing the superuser shell without logging into ChromeOS ====<br />
<br />
If you have not configured ChromeOS, just press {{ic|Ctrl + Alt + F2}} (F2 is the "forward" arrow on the top row, →), you will see a login prompt.<br />
<br />
* Use {{ic|chronos}} as the username, it should not prompt you for a password.<br />
* Become superuser with [[sudo]], use the command {{ic|sudo su -}}.<br />
<br />
==== Accessing the superuser shell when logged into ChromeOS ====<br />
<br />
If you have configured ChromeOS already:<br />
<br />
* Open a crosh window with {{ic|Ctrl + Alt + T}}.<br />
* Open a bash shell with the {{ic|shell}} command.<br />
* Become superuser with [[sudo]], use the command {{ic|sudo su -}} to accomplish that.<br />
<br />
=== Enabling Legacy Boot Mode ===<br />
<br />
If your ChromeOS device did not ship with Legacy Boot Mode support via SeaBIOS, or you prefer to install a custom firmware, then continue to [[#Flashing a custom firmware|Flashing a custom firmware]].<br />
<br />
This will enable the pre-installed version of SeaBIOS through the Developer Mode screen in coreboot.<br />
<br />
* Inside your superuser shell enter:<br />
# crossystem dev_boot_legacy=1<br />
* Reboot the machine.<br />
<br />
You can now start SeaBIOS by pressing {{ic|Ctrl + L}} at the white boot splash screen.<br />
<br />
{{Note|If you intend to stay using pre-installed SeaBIOS route and think you will not appreciate having to press {{ic|Ctrl + L}} every time you boot to reach SeaBIOS, then you can set coreboot to boot to SeaBIOS by default. This requires disabling the hardware firmware write protection.}}<br />
<br />
You should now have SeaBIOS enabled on your ChromeOS device, if you choose to not set it as default then you can continue to [[#Installing Arch Linux|Installing Arch Linux]].<br />
<br />
==== Boot to SeaBIOS by default ====<br />
<br />
To boot SeaBIOS by default, you will need to run the [https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/master/scripts/image_signing/set_gbb_flags.sh {{ic|set_gbb_flags.sh}}] script, which is part of ChromeOS. The script uses flashrom and gbb_utility to read the RO_GBB firmware region, modify the flags, and write it back to flash. The GBB flags can also be set using MrChromebox's [https://mrchromebox.tech/#fwscript Firmware Utility Script] under either ChromeOS or Arch (the latter requiring booting with specific kernel parameters to relax memory access restrictions).<br />
<br />
{{Warning|If you do not set the GBB flags, then a fully discharged or disconnected battery will reset {{ic|dev_boot_legacy}} crossystem flag to its default value, removing the ability to boot in Legacy Boot Mode. While this used to require you to recover Chrome OS and wipe your Arch Linux installation on the internal storage, the GalliumOS developers have created a set of "fixflags" recovery images, which rather than wiping internal storage, will instead simply re-set the {{ic|dev_boot_legacy}} crossystem flag. See [https://galliumos.org/fixflags galliumos.org/fixflags]}}<br />
<br />
* Disable the hardware write protection.<br />
<br />
To find the location of the hardware write-protect screw/switch/jumper and how to disable it visit the ArchWiki page for your [[#Chrome OS devices|ChromeOS device]]. If there is no information about your device on the ArchWiki then turn to [http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices Developer Information for ChromeOS Devices] and [http://www.coreboot.org/Chromebooks coreboot's Chromebooks page].<br />
<br />
More information about the firmware protection available at the [[Custom firmware for ChromeOS devices#Firmware write protection|Custom firmware for ChromeOS devices]] page.<br />
<br />
* Switch to the [[#Accessing the superuser shell|superuser shell]].<br />
<br />
* Disable the software write protection.<br />
# flashrom --wp-disable<br />
<br />
* Check that write protection is disabled.<br />
# flashrom --wp-status<br />
<br />
* Run {{ic|set_gbb_flags.sh}} with no parameters.<br />
# /usr/share/vboot/bin/set_gbb_flags.sh<br />
<br />
* This will list all of the available flags. The ones of interest to us are:<br />
GBB_FLAG_DEV_SCREEN_SHORT_DELAY 0x00000001<br />
GBB_FLAG_FORCE_DEV_SWITCH_ON 0x00000008<br />
GBB_FLAG_FORCE_DEV_BOOT_LEGACY 0x00000080<br />
GBB_FLAG_DEFAULT_DEV_BOOT_LEGACY 0x00000400<br />
<br />
* So, to set SeaBIOS as default, with a 1s timeout, prevent accidentally exiting Developer Mode via spacebar, and ensure Legacy Boot Mode remains enabled in the event of battery drain/disconnect, we set the flags as such:<br />
# /usr/share/vboot/bin/set_gbb_flags.sh 0x489<br />
<br />
* Enable back the software write protection.<br />
# flashrom --wp-enable<br />
<br />
{{Note|All of these steps are automated by MrChromebox's Firmware Utility Script, so if using that to install/update your RW_LEGACY firmware, easiest to just set the flags via the script as well.}}<br />
<br />
Your ChromeOS device now will boot to SeaBIOS by default, you can continue to [[#Installing Arch Linux|Installing Arch Linux]], if your device is booting correctly then you can optionally re-enable the hardware write protection.<br />
<br />
=== Flashing a custom firmware ===<br />
<br />
{{Note|The following steps explain how to flash a custom firmware from ChromeOS, for information on how to flash a custom firmware from Arch Linux visit the [[Custom firmware for ChromeOS devices]] page}}<br />
<br />
* Disable the hardware write protection.<br />
<br />
To find the location of the hardware write-protect screw/switch/jumper and how to disable it visit the ArchWiki page for your [[#Chrome OS devices|ChromeOS device]]. If there is no information about your device on the ArchWiki then turn to [http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devicesDeveloper Information for ChromeOS Devices] and [http://www.coreboot.org/Chromebooks coreboot's Chromebooks page].<br />
<br />
More information about the firmware protection available at the [[Custom firmware for ChromeOS devices#Firmware write protection|Custom firmware for ChromeOS devices]] page.<br />
<br />
* Enter the command to run either MrChromebox's or John Lewis's firmware script.<br />
<br />
{{Note|The reason for not posting here is to force you to visit the site and read the instructions before proceeding.}}<br />
<br />
* After the exiting the script, be sure to copy the backed up firmware to an external storage before rebooting the system (if the script doesn't provide that option for you).<br />
<br />
You should now have a custom firmware installed on your device, cross your fingers and reboot.<br />
<br />
After flashing the firmware you can continue to [[#Installing Arch Linux|Installing Arch Linux]].<br />
<br />
=== Installing Arch Linux ===<br />
<br />
==== Preparing the installation media ====<br />
<br />
Create an [[USB flash installation media|Arch Linux Installer USB drive]].<br />
<br />
{{Note|If the USB loads but fails to boot into Arch, it may be due a bug in the syslinux the current (2017.03.01) installer uses. The 2016.11.01 version from the [[Arch Linux Archive]] will work until the issue is resolved.}}<br />
<br />
==== Booting the installation media ====<br />
<br />
* Plug the USB drive to the ChromeOS device and start SeaBIOS with {{ic|Ctrl + L}} at the white boot splash screen (if SeaBIOS is not set as default).<br />
* Press {{ic|Esc}} to get a boot menu and select the number corresponding to your USB drive.<br />
<br />
The Arch Linux installer boot menu should appear and the [[Installation guide|installation]] process can proceed as normal.<br />
<br />
{{Note|For now choose [[GRUB]] as your bootloader: you can choose MBR or GPT: [[Partitioning]]. If you choose GPT then do not forget to add a [[GRUB#GUID_Partition_Table_.28GPT.29_specific_instructions|BIOS Boot Partition]]. Also see [[#Syslinux|Known Issues]].}}<br />
<br />
After finishing installing Arch Linux continue by following the [[#Post installation configuration|Post Installation Configuration]].<br />
<br />
== Post installation configuration ==<br />
<br />
=== Patched kernels ===<br />
{{Note|You can most likely ignore this section unless your device requires patched kernel support.}}<br />
<br />
It is recommended to use the official {{Pkg|linux}} package for most Chrome OS devices with the exception being newer devices which might need patched kernel support such as the Chromebook Pixel 2015.<br />
<br />
{{AUR|linux-samus4}} provides patches for the Chromebook Pixel 2015 to fix touchpad, touchscreen, and sound functionality which has not been merged into upstream linux yet. More information is available at [https://github.com/raphael/linux-samus its GitHub page].<br />
<br />
If your devices requires a patched kernel, it is advised to review the list of patches and decide if the patch list is getting decidedly small enough that you no longer require a patched kernel and instead you can use the official {{Pkg|linux}} package instead. <br />
<br />
See [[kernels]] for more information.<br />
<br />
=== Video driver ===<br />
<br />
See [[Intel graphics]].<br />
<br />
=== Touchpad and touchscreen ===<br />
<br />
See [[Touchpad Synaptics]], [[libinput]], and [[Touchscreen]].<br />
<br />
==== Touchpad and touchscreen kernel modules ====<br />
<br />
Since kernel 3.17 all the related patches merged into the upstream sources, meaning the {{Pkg|linux}} package in core supports these devices.<br />
<br />
===== What to do if your touchpad or touchscreen is not supported? =====<br />
<br />
* Review the list of patches in {{Aur|linux-chromebook}}{{Broken package link|{{aur-mirror|linux-chromebook}}}}, if a related patch for your Chromebook model exist then [[#Patched kernels|install this package]].<br />
* If there is no such patch do not worry as the developers should be able to add it by request as the Chromium OS sources includes the related changes.<br />
* You can also try to find the related commits by yourself and create a proper patch, some hints:<br />
** Dig into your Chrome OS system, look at the obvious suspects like boot log, {{ic|/proc/bus/input/devices}} and {{ic|/sys/devices}}.<br />
** The Linux kernel sources for Chromium OS are at [https://chromium.googlesource.com/chromiumos/third_party/kernel].<br />
** Each kernel source for the latest Chromium OS release has its own branch, name convention: {{ic|release-R*-*-chromeos-KERNELVER}}, where {{ic|R*-*}} is the Chromium OS release and {{ic|KERNELVER}} is the kernel version.<br />
** Review the git log of {{ic|drivers/platform}}, {{ic|drivers/i2c/busses}} and {{ic|drivers/input/touchscreen}}.<br />
* {{AUR|linux-samus4}} includes touchpad and touchscreen support for the Chromebook Pixel 2015. More information is available at [https://github.com/raphael/linux-samus its GitHub page].<br />
<br />
==== Touchpad configuration ====<br />
<br />
There are few options how to set the touchpad:<br />
<br />
* Visit the ArchWiki page for your Chromebook model (see [[#Chromebook_Models|Chromebook models]]{{Broken section link}}) for touchpad xorg.conf.d file.<br />
* Use a [[Touchpad_Synaptics#Configuration_on_the_fly|touchpad configuration tool]].<br />
<br />
==== Chromium OS input drivers ====<br />
<br />
{{Out of date|{{ic|xf86-input-cmt}} development is not active and it is probably not needed anymore in any case since [[libinput]]'s compatibility with Chrome OS devices's touchpads is fairly good.}}<br />
<br />
{{AUR|xf86-input-cmt}} offers a port of the Chromium OS input driver: [https://github.com/hugegreenbug/xf86-input-cmt xf86-input-cmt] as an alternative for the [[Synaptics|Synaptics input driver]]. It provides tweaked configuration files for most devices, and provides functionality that the [[Synaptics|Synaptics input driver]] does not such as palm rejection. Additionally, it enables functionality not enabled by default in the Chromium OS input driver such as tap-to-drag.<br />
<br />
Please note, the input driver does not work under [https://github.com/hugegreenbug/xf86-input-cmt/issues/5 some circumstances] where you have insufficient permissions to access {{ic|/dev/input/event}}<br />
This will affect you if you use [[startx]] to load a DE/WM session.<br />
If this is the case or if the driver does not load for any other cases, you should run:<br />
# usermod -a -G input $USER<br />
Where $USER is the current user wanting to use the input driver.<br />
<br />
It should also be noted that some users have reported the driver does not work in [[GDM]] but works normally after log in.<br />
If you are affected by this, you should run:<br />
# usermod -a -G input gdm<br />
<br />
After reboot, you should be able to use the touchpad normally.<br />
<br />
=== Fixing suspend ===<br />
{{Note|Lid suspend might not work directly after boot, you might need to wait a little.}}<br />
<br />
The following are instructions to fix the suspend functionality.<br />
Users of a pre-installed SeaBIOS or John Lewis' pre-built SeaBIOS you will need this fix.<br />
This procedure is not needed with Matt DeVillier's custom firmware since problematic ACPI wake devices (such as {{ic|TPAD}}) are firmware-disabled.<br />
<br />
There have been a few alternatives discussed and those may work better for some. [https://bbs.archlinux.org/viewtopic.php?pid=1364376#p1364376] [https://bbs.archlinux.org/viewtopic.php?pid=1364521#p1364521]<br />
<br />
To fix suspend, the general idea is to disable the EHCI_PCI module, which interferes with the suspend cycle. There are multiple ways to achieve this.<br />
<br />
==== With kernel parameters ====<br />
{{Note|Blacklisting ehci_pci has no effect on dmesg ehci errors as of kernel 4.18.11}}<br />
Add the following to your GRUB configuration:-<br />
<br />
{{hc|head=/etc/default/grub|<br />
output=GRUB_CMDLINE_LINUX_DEFAULT="modprobe.blacklist=ehci_pci"}}<br />
<br />
Then [[GRUB#Generate_the_main_configuration_file|rebuild your grub config]]. After rebuilding your GRUB config, reboot your computer.<br />
<br />
==== With systemd ====<br />
<br />
Sometimes the synaptics touchpad, and various other parts of the laptop are used as wakeup devices causing certain movements of the laptop during suspend to end suspend. In order to disable all wakeup devices except for the laptop lid sensor, create the following {{ic|suspend-device-fix.sh}} file. <br />
<br />
{{hc|head=/usr/local/sbin/suspend-device-fix.sh|<br />
output=<nowiki>#!/bin/bash<br />
<br />
awk '{if ($1 != "LID0" && $3 == "*enabled") print $1}' < /proc/acpi/wakeup | while read NAME<br />
do echo "$NAME" > /proc/acpi/wakeup<br />
done<br />
<br />
exit 0<br />
</nowiki>}}<br />
<br />
Now give the file executable permissions:<br />
# chmod +x /usr/local/sbin/suspend-device-fix.sh<br />
<br />
Create a systemd service to execute the script on every boot. <br />
{{hc|head=/etc/systemd/system/suspend-fix.service|<br />
output=[Unit]<br />
Description=Suspend Fix<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=/usr/local/sbin/suspend-device-fix.sh<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
First [[start]] {{ic|suspend-fix.service}}. If it properly starts, then [[enable]] it to be started on bootup.<br />
<br />
Add the following line at the end of {{ic|/etc/rc.d/rc.local}} (if it does not exist, just create it) to prevent bad handling of EHCI USB:<br />
<br />
{{hc|head=/etc/rc.d/rc.local|<br />
output=<nowiki><br />
echo 1 > /sys/devices/pci0000\:00/0000\:00\:1d.0/remove<br />
</nowiki>}}<br />
<br />
Then, create the following {{ic|cros-sound-suspend.sh}} file. Only the Ath9k binding/unbinding lines are listed below; see the alternatives linked above for additional sound suspend handling if you experience issues.<br />
<br />
{{hc|head=/usr/lib/systemd/system-sleep/cros-sound-suspend.sh|<br />
output=<nowiki>#!/bin/bash<br />
<br />
case $1/$2 in<br />
pre/*)<br />
# Unbind ath9k for preventing error and full sleep mode (wakeup by LID after hibernating) <br />
echo -n "0000:01:00.0" | tee /sys/bus/pci/drivers/ath9k/unbind<br />
# Unbind snd_hda_intel for sound<br />
echo -n "0000:00:1b.0" | tee /sys/bus/pci/drivers/snd_hda_intel/unbind<br />
echo -n "0000:00:03.0" | tee /sys/bus/pci/drivers/snd_hda_intel/unbind<br />
;;<br />
post/*)<br />
# Bind ath9k for preventing error and and full sleep mode (wakeup by LID after hibernating) <br />
echo -n "0000:01:00.0" | tee /sys/bus/pci/drivers/ath9k/bind<br />
# bind snd_hda_intel for sound<br />
echo -n "0000:00:1b.0" | tee /sys/bus/pci/drivers/snd_hda_intel/bind<br />
echo -n "0000:00:03.0" | tee /sys/bus/pci/drivers/snd_hda_intel/bind<br />
;;<br />
esac</nowiki>}}<br />
<br />
Make sure to make the script executable:<br />
# chmod +x /usr/lib/systemd/system-sleep/cros-sound-suspend.sh<br />
<br />
Then [[GRUB#Generate_the_main_configuration_file|rebuild your grub config]].<br />
<br />
=== Fixing audio ===<br />
<br />
==== Baytrail based models ====<br />
<br />
Most baytrail models ''worked'' on {{Pkg|linux}} but a regression introduced in 4.18.15 broke it, see bug report [https://lkml.org/lkml/2018/10/30/676]. Either, rollback to 4.18.14, compile your own kernel using this patch [https://patchwork.kernel.org/patch/10667953], or, install linux-max98090 from unofficial user repo [https://github.com/duffydack/linux-max98090]. It is likely that you will also need to use {{ic|alsamixer}} from {{Pkg|alsa-utils}} to turn on "Left Speaker Mixer Left DAC" and "Right Speaker Mixer Right DAC". For more information, see [https://bugs.archlinux.org/task/48936].<br />
<br />
==== Haswell based models ====<br />
<br />
One or more of followings might help solving audio related issues, setting {{ic|snd_hda_intel}} module index reported the most useful. It is highly possible that you will not need to make any change.<br />
<br />
* Create {{ic|/etc/modprobe.d/alsa.conf}}, the option {{ic|index}} will make sure the analog output is the default (and not HDMI), the option {{ic|model}} will notify the driver our board model which will make the built-in microphone usable (you can try instead {{ic|<nowiki>model=alc283-sense-combo</nowiki>}} or {{ic|<nowiki>model=,alc283-dac-wcaps</nowiki>}}). <br />
<br />
{{hc|head=/etc/modprobe.d/alsa.conf|<br />
output=options snd_hda_intel index=1 model=,alc283-chrome}}<br />
<br />
* Use the {{ic|~/.asoundrc}} file from [https://gist.githubusercontent.com/dhead666/52d6d7d97eff76935713/raw/5b32ee11a2ebbe7a3ee0f928e49b980361a57548/.asoundrc].<br />
<br />
* If having problems with headphones (perhaps no audio playing), try {{ic|alsactl restore}} in terminal. Now, ALSA should automatically switch between channels when using headphones/speakers. <br />
<br />
* To fix [[Flash]] audio with PulseAudio, use the {{ic|~/.asoundrc}} file from [https://gist.githubusercontent.com/dhead666/0eebff16cd9578c5e035/raw/d4c974fcd50565bf116c57b1884170ecb47f8bf6/.asoundrc].<br />
<br />
==== Chromebook Pixel 2015 ====<br />
<br />
{{AUR|linux-samus4}} includes a patch for Broadwell SoC sound devices. [https://github.com/raphael/linux-samus Its GitHub page] includes additional instructions for initializing the sound device.<br />
<br />
=== Hotkeys ===<br />
<br />
[https://support.google.com/chromebook/answer/1047364?hl=en The Chromebook function keys] recognized as standard F1-F10 by the kernel, it is preferable to map them accordingly to their appearance. It would also be nice to get the keys {{ic|Delete, Home, End, PgUp, PgDown}} which in Chrome OS mapped to {{ic|Alt + : BackSpace, Right, Left, Up, Down}}.<br />
<br />
==== xkeyboard configuration ====<br />
<br />
{{Pkg|xkeyboard-config}} 2.16-1 added a {{ic|chromebook}} model that enables the Chrome OS style functions for the function keys. You can, for example, set this using {{ic|localectl set-x11-keymap us chromebook}}. See the {{ic|chromebook}} definition in {{ic|/usr/share/X11/xkb/symbols/inet}} for the full mappings.<br />
<br />
==== Sxhkd configuration ====<br />
<br />
One way to set the hotkeys would be by using the [[Sxhkd]] daemon. Besides {{Pkg|sxhkd}}, this also requires [[Advanced Linux Sound Architecture|amixer]], {{Pkg|xorg-xbacklight}}, and {{Pkg|xautomation}}.<br />
<br />
* See [https://gist.github.com/dhead666/191722ec04842d8d330b] for an example configuration in {{ic|~/.config/sxhkd/sxhkdrc}}.<br />
<br />
==== Xbindkeys configuration ====<br />
<br />
Another way to configure hotkeys would be by using [[Xbindkeys]]. Besides {{Pkg|xbindkeys}} this requires [[Advanced Linux Sound Architecture|amixer]] and {{Pkg|xorg-xbacklight}} and {{AUR|xvkbd}}.<br />
<br />
* See [https://gist.github.com/dhead666/08562a9a760b18b6e758] for an example configuration in {{ic|~/.xbindkeysrc}}.<br />
* See [https://bbs.archlinux.org/viewtopic.php?id=173418&p=3 vilefridge's xbindkeys configuration] for another example.<br />
<br />
===== Alternate xbindkeys configuration =====<br />
<br />
[http://pastie.org/9550960 Volchange] (originated in the [http://www.debianuserforums.org/viewtopic.php?f=55&t=1453#p14351 Debian User Forums])) can manipulate the volume with PulseAudio instead of using [[Advanced Linux Sound Architecture|amixer]]. Besides [http://pastie.org/9550960 Volchange] this requires {{Pkg|xorg-xbacklight}} and {{AUR|xvkbd}}.<br />
<br />
* Download the script from [http://pastie.org/9550960].<br />
* Make it executable <br />
$ chmod u+x ~/.local/bin/volchange<br />
<br />
See [https://gist.github.com/dhead666/4e23b506441ad424e26e] for a matching {{ic|~/.xbindkeysrc}}.<br />
<br />
==== Patch xkeyboard-config ====<br />
<br />
Another option is to install {{AUR|xkeyboard-config-chromebook}}, for more details visit [https://github.com/dhead666/archlinux-pkgbuilds/tree/master/xkeyboard-config-chromebook].<br />
<br />
==== Mapping in Gnome with gsettings set ====<br />
<br />
Some of the function keys can be mapped in Gnome with the advantage of HUD notifications on changes (like volume and brightness changes) which can supplement one of the mapping methods mentioned above. This [https://gist.github.com/dhead666/0b9c1cc9def939705594 linked example] maps the brightness and volume actions. Notice that {{Pkg|xdotool}} is required.<br />
<br />
=== Power key and lid switch handling ===<br />
<br />
==== Ignore using logind ====<br />
<br />
Out of the box, {{ic|systemd-logind}} will catch power key and lid switch events and handle them: it will shut down the Chromebook on a power key press, and a suspend on a lid close. However, this policy might be a bit harsh given that the power key is an ordinary key at the top right of the keyboard that might be pressed accidentally.<br />
<br />
To configure logind to ignore power key presses and lid switches, add the lines to {{ic|logind.conf}} below.<br />
<br />
{{hc|head=/etc/systemd/logind.conf|<br />
output=HandlePowerKey=ignore<br />
HandleLidSwitch=ignore}}<br />
<br />
Then [[restart]] logind for the changes to take effect.<br />
<br />
Power key and lid switch events will still be logged to journald by logind. See [[Power management#ACPI events]].<br />
<br />
==== Ignore by Gnome ====<br />
<br />
[[Install]] {{Pkg|gnome-tweaks}}, open the Tweak Tool and under Power change the Power Button Action.<br />
<br />
== Known issues ==<br />
<br />
=== Syslinux ===<br />
<br />
Follow Syslinux installation instructions carefully. Try manual installation to see where the problem comes from. If you see [[Syslinux#Missing_operating_system|Missing Operation System]] then it may be because you need to use correct bootloader binary. If syslinux does not work try another [[bootloader]] such as [[GRUB]].<br />
<br />
== See also ==<br />
<br />
* [http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices Developer Information for Chrome OS Devices at the Chromium Projects site]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=173418 BBS topic about the Acer C720] which include generic information on Haswell Based Chromebooks.<br />
* Re-partitioning in Chrome OS [http://chromeos-cr48.blogspot.co.uk/2012/04/chrubuntu-1204-now-with-double-bits.html], [http://goo.gl/i817v]<br />
* [http://bit.ly/NewChromebooks Brent Sullivan's the always updated list of Chrome OS devices]<br />
* [http://prodct.info/chromebooks/ Google Chromebook Comparison Chart]</div>Crescent