Installing and using GNU / Linux instead of Chrome OS on Toshiba Chromebook 2
Hello to all! Some time ago, I bought myself a Toshiba Chromebook 2 CB35-B3330 Chromebook and replaced Chrome OS with traditional GNU / Linux. It was not a crouton installation, but a “clean” installation with complete removal of Chrome OS. The fight against bad Linux support for this Chromebook took an unexpectedly long time (several nights), but in the end all the problems were solved and the Chromebook became a full-fledged working machine.
In the end, I decided to write an article in which:
Here and hereafter, the common wrong setting decisions are marked in red , working in yellow but ugly (crutches) in yellow , correct in green .
Model CB35-B3330 is built on a budget chip (SoC) Intel Baytrail N2840. Main characteristics:
')
Pros: the laptop is very light and compact. Pretty cute - metallic color with a corrugated surface, carefully assembled. It has passive cooling, so that it does not make noise from the word “absolutely”. Due to the weak iron it has a very low power consumption (2.5 - 5 W) and a long time when working on battery power. The manufacturer claims 13 hours of work, the battery indicator in Chrome OS confirms this in general, and after installing Linux, for the sake of interest, having turned off all unnecessary and slightly dimming the brightness, I received a forecast of 24 hours of work without load and 16-18 hours with a load of text editor + audio player + web browser + pdf viewer:
A very big plus is low cost. This model costs in the United States in the region of $ 150-200 for a restored or used version, and $ 230-250 for a new one. I note that many Chromebooks and similar characteristics from other manufacturers, in particular from HP and Acer, are even cheaper than this model.
Cons: IMHO the main disadvantage is a low-quality display (TN, low resolution and whitish surface). This Chromebook has an older brother - Toshiba Chromebook 2 CB35-B3340 with a FullHD IPS display and a slightly more powerful hardware, and here it seems to be an almost perfect chromebook.
Weak iron and a limited amount of RAM and disk exclude many use cases.
It is also very unpleasant that Toshiba pretends that it has nothing to do with the chromebooks produced by it. On the Toshiba offsite Toshiba Chromebook models are dedicated to blank pages without specs with a shorter user manual .
Another disadvantage of this Chromebook is its complete lack of sales in Russia, so you can immediately add to the price the cost of shipping from abroad or look for workarounds. (But this is a common problem - for some unknown reason, for some reason, the Chromebooks have almost completely disappeared from sales in Russia in the last 2-3 years).
The installation is approximately the same as for any other Linux on any other laptop, except for a couple of subtleties:
Beach of all Chromebooks on the Baytrail chip. Discussions on the Internet about the native Linux installation on such chromebooks are full of messages that the “sound does not work” ( example ). Most often this happens for the following reasons.
First, byt-max98090 (a kernel module responsible for sound from speakers and headphones) is not included in the standard kernel build of most distributions. (An example of a distribution that includes byt-max98090, - Ubuntu.) If this module does not exist, there will naturally be no sound from the speakers and headphones under any conditions and you will need to rebuild the kernel with the inclusion of byt-max98090. You can check the availability of this module in the system in several ways:
- In the kernel config should be CONFIG_SND_SOC_MAX98090 = m.
- The lsmod command should output this module in the list of others (if it is loaded).
Secondly, even worse, byt-max98090 does not work in many new kernel releases. By typing and web searching I found out the following:
TL; DR: 4.4.23 - the sound works, in any next kernel release - no.
Thirdly, even if you put byt-max98090 and the kernel of the required version, the sound from the box does not work - you need to perform a couple of actions to unload the kernel modules (see below) and set some necessary ALSA settings. At this stage, they usually give incorrect advice to use another distribution kit or use asound.state from Chrome OS (and such tips are noticed even for such gurus as John Lewis - the author of the most well-known SeaBios firmware for Chromebooks). Such advice can, in principle, work, but it is pure shamanism, because if the sound works in one distro and not in the other, it means that the problem is either in different kernel assemblies or in different configs of alsa / pulseaudio, there can be no other situations. The same with asound.state. Asound.state is just a snapshot of alsa settings. Anything that someone else has put in his asound.state can be put through his alsamixer utility or in a lower-level alsactl, without copying asound.state from anywhere.
So, the following actions include the sound on the baytrail Chromebook and do not require changing the distribution kit or copying asound.state:
These actions are the most obvious crutch with pulling-in of sound modules, designed to solve the wrong order of initialization of sound devices when loading. The correct solution would be to fix the kernel code , so that the sound worked out of the box, but IMHO is unlikely to fix it in the near future.
UPDATE 2 comments aleksandr99: When using UEFI (firmware by reference), the problem with the order of module initialization disappears. In other words, the sound in the core <= 4.4.23 will work out of the box immediately after the start, without requiring actions with lsmod. In newer kernels, unfortunately, the sound will not work under any circumstances.
UPDATE 3 (November 12, 2018): Hurray! On the above-mentioned page of this bug in archlinux , a link to the patch solving the problem appeared in the discussion! Right now, after this patch, I made a sound in the newest kernel - at the moment it is 4.19.
A very common problem for this Chromebook, and for many others. The internal drive on it is a soldered eMMC, which means that it cannot be replaced at home and the life of the Chromebook is equal to the lifetime of this drive. And he, like any MMC, has a very limited supply of rewriting cycles. For Chrome OS, this problem does not exist, because every time it is unpacked from a fixed image into memory and almost does not write to the drive, the usual Linux constantly writes to the disk: logs, home directory, etc. There are several solutions to this problem:
The most actively used directories are / home, / tmp and / var / log, so I have the following / etc / fstab:
Since the files placed in the RAM only live until the power is turned off, it is necessary to regularly make backups of these files somewhere in a more reliable place, for example, to the same internal drive, to the home server or to the cloud storage. How to implement it - everyone decides for himself, there can not be a universal recipe here.
I will add that a complete power failure on a laptop is an extremely rare event, it is easier if you need to send a laptop to sleep or hibernation. To force a laptop to shut down can only be the need to update the kernel, kernel panic or battery discharge to zero. (I turned off my chromebook only in the first 2-3 weeks after the purchase, the environment has not yet settled, after that I have not turned it off once, only sent to sleep). One more important note - installing Linux, you should never allow the full discharge of the Chromebook to be completely discharged , as this leads to the transition of the Chromebook to the Recovery Mode.
True, there is another unpleasant reason for shutting down, about which the next item -
I still do not understand what the creators of this Chromebook were guided by (which, in theory, almost never need to be turned off) and all the other Chromebooks, making the Power button with the usual keyboard key next to Backspace.
In normal laptops, Power is a tiny button somewhere on the side that cannot be accidentally pressed. On the Chromebook, in order to accidentally click on Power, it’s enough to miss the Backspace or the next F-key.
Only one way out - software disable or reassign Power. This does not make it impossible to turn off the PC, because firstly, it can always be done from the console via / sbin / init 0, poweroff, etc., and secondly, the combination “Esc + Power + F3” (reboot in recovery mode) and “hold Power for 5 seconds” (disabling) are absolutely always - they are processed at the BIOS level of Chromebooks.
For systemd-based distributions, this is very easy to do in systemd settings: just set HandlePowerKey = ignore in /etc/systemd/logind.conf and restart systemd-logind or PC.
For other distributions (including Slackware), ACPI handling of the "power button pressed" event is specified in /etc/acpi/handler.sh:
Another birth injury Chromebooks. There are no Caps Lock keys on them, instead the Search button. You can live without caps caption somehow, but the problem is that many Linux users use Caps Lock to change the layout, and I would like to have a Search key working as Caps, which we are doing now.
This key is recognized not as a search media key (XF86XK_Search), as one would expect, but as a left Win key. Therefore, if anyone is too lazy to perform long settings, you can simply score LWin on switching layouts in the DE or xkb settings of your choice.
Configuration via xkb is done (in my case) as follows:
And add the option:
The method is not quite perfect, tk:
So the correct way is to reset LWin to Caps at a low xkb level in xmodmap. Mapping xmodmap each configures in its place (~ / .Xmodmap, start script ...), but the action is the same everywhere:
Note: All that has been said about the keyboard refers only to the setting of keys under the X server (xkb). Other utilities are used in the console (in Slackware, they are represented by the kbd package) and the key resetting tool is loadkeys. Setting kbd in the article will not be considered.
UPDATE 2 (via mrobespierre ) :
2GB of RAM is nothing by today's standards, and on a chromebook with such a small memory it is very easy to fly out of its limits, and a swap comes into play, which means that the drive will wear out even faster. To combat this effect, there is a zram module in the Linux kernel for a long time that deals with data compression in RAM on the fly. So the advice here is simple: it is highly recommended to enable zram on this chromebook and use it for swapping. Again, there are many scenarios for how to enable it - in fstab, in rc.local. For an example - completely manual inclusion:
There is nothing much to tell about work on this laptop with stock Chrome OS - everything is the same as in any other Chromebook and there are dozens of articles and commercials on this topic. The central part of the system for the user is the Chrome browser. There are no applications in the classic sense - they are plugins for Chrome and web services opened in the browser. Among the usual - GMail, Google Docs, Google Drive, Hangouts. If you dig into the plugins, you can find the SSH client , VNC client , RDP client , Samba client , various text editors, graphics, etc. The speed and functionality of such plug-ins, as a rule, in the area of ​​the plinth. In theory, you can install native applications by replacing Chrome OS with Chromium OS and repacking the image , but this entertainment is only for the strong in spirit, and is clearly beyond the scope of this article. Everything works without special brakes, Chrome regularly loads pages, movies and music are played, although the set of video and audio codecs is far from complete and some formats cannot be played (and, unlike desktop OSs, there is no possibility to install codecs).
In Developer Mode, everything is a bit more fun, you get access to bash, the file system and work under the root. In such an environment, the most straightforward way to extend the functionality of a Chromebook is to chroot into the root directory with normal Linux (on a flash drive or on an internal drive), which is exactly what the well-known crouton utility does. Today, more modern than chroot, containerization tools, such as LXC, are relevant, but I don’t know anything about the possibility / complexity of using them in ruled Chrome OS.
A more fundamental modification of the Chromebook is the complete removal of Chrome OS from the drive and the installation of its OS (hereinafter I will assume that this is Linux, although in fact, of course, there are other options).
What a user gets when installing native GNU / Linux:
On my laptop, this option is implemented - the “clean” Slackware 14.2 is installed.
The tools are quite austere, so the power requirements of the laptop are very low. The graphical environment is dwm, a small tile-based window manager in C. Virtually all applications that I use use a text interface. Central among them is Emacs - I write code and any text in it, read email and RSS (Gnus), communicate in jabber and irc, keep notes and work plans (Org-mode), visit text web pages (w3m). There are few other user applications, the main ones are dwm (web browser), mpd + ncmpc (music), zathura (pdf viewer, djvu, etc.) and TeX Live (mathematics text layout system). Sometimes I watch movies (mplayer) and play games like Warsow, ADOM, Aquaria and Wangers. I am developing mainly in C ++, Perl, C.
The power of Chromebook for the listed software is enough. It starts to slow down on web pages that actively use js and flash, and unfortunately in almost all games, except for very minimalistic ones (Aquaria, Wangers, and of course ADOM).
The system with all the tools (the applications mentioned above, TeX, Perl, GCC and all related development tools) occupies 2.7 GB of the available 16 GB, the rest of the place is not used at all. All large data (media files, backups, virtual machine images) and generally all permanent data are stored on the home server, to the disk of which I connect via sshfs or nfs. Locally, on the Chromebook, I usually store only what I work with for the current day — usually a pair of books, a copy of the contents of the mailbox, a copy of 2-3 repositories with code, and a copy of the Org-mode database. At the beginning and at the end of the working day I synchronize with the server. Thus, Chromebook gets a very high autonomy, impossible in Chrome OS.
In the end, I decided to write an article in which:
- Very briefly described Chromebook itself and my impressions of iron.
- The basic problems of installing GNU / Linux on this particular model and ways to solve them are described.
- It describes very briefly how I use it myself after installing Linux.
Here and hereafter, the common wrong setting decisions are marked in red , working in yellow but ugly (crutches) in yellow , correct in green .
Toshiba Chromebook 2
Model CB35-B3330 is built on a budget chip (SoC) Intel Baytrail N2840. Main characteristics:
')
- CPU: 64-bit Intel Celeron, 2 cores, 2.16 GHz, 1MB L2 cache
- RAM: 2 GB DDR3L SDRAM
- Video: integrated Intel HD graphics adapter
- Disk memory: 16 GB eMMC (most specifications blatantly lie for SSD)
- Display: 13.3 "matte 1366x768
- Wi-Fi: 802.11 A / C
- Weight: 3 pounds (1.3 kg)
- Linear dimensions: 12.60 x 8.40 x 0.76 inches
Pros: the laptop is very light and compact. Pretty cute - metallic color with a corrugated surface, carefully assembled. It has passive cooling, so that it does not make noise from the word “absolutely”. Due to the weak iron it has a very low power consumption (2.5 - 5 W) and a long time when working on battery power. The manufacturer claims 13 hours of work, the battery indicator in Chrome OS confirms this in general, and after installing Linux, for the sake of interest, having turned off all unnecessary and slightly dimming the brightness, I received a forecast of 24 hours of work without load and 16-18 hours with a load of text editor + audio player + web browser + pdf viewer:
A very big plus is low cost. This model costs in the United States in the region of $ 150-200 for a restored or used version, and $ 230-250 for a new one. I note that many Chromebooks and similar characteristics from other manufacturers, in particular from HP and Acer, are even cheaper than this model.
Cons: IMHO the main disadvantage is a low-quality display (TN, low resolution and whitish surface). This Chromebook has an older brother - Toshiba Chromebook 2 CB35-B3340 with a FullHD IPS display and a slightly more powerful hardware, and here it seems to be an almost perfect chromebook.
Weak iron and a limited amount of RAM and disk exclude many use cases.
It is also very unpleasant that Toshiba pretends that it has nothing to do with the chromebooks produced by it. On the Toshiba offsite Toshiba Chromebook models are dedicated to blank pages without specs with a shorter user manual .
Another disadvantage of this Chromebook is its complete lack of sales in Russia, so you can immediately add to the price the cost of shipping from abroad or look for workarounds. (But this is a common problem - for some unknown reason, for some reason, the Chromebooks have almost completely disappeared from sales in Russia in the last 2-3 years).
Installing and configuring Slackware Linux 14.2
Installation problems
The installation is approximately the same as for any other Linux on any other laptop, except for a couple of subtleties:
- As far as I know, a bootloader hosted on an eMMC drive, be it GRUB or LILO, will work only in the case of UEFI . In the case of a BIOS + MBR, it will install on the eMMC, but will not work. Unfortunately, a rooted chromebook with OS Verification off = John Lewis's SeaBIOS = no UEFI.
I’m not sure about that and I’ll be glad if someone dissuades me or prompts a way to sign a third-party OS bootloader, but so far I haven’t succeeded.
UPDATE comments aleksandr99: To date, a firmware with UEFI has already appeared, supporting this Chromebook and many more other models. In addition to other advantages of UEFI, its presence allows you to put on Windows Chromebooks.
One way out with SeaBIOS is to place the bootloader on the MBR of a third-party carrier , for example, flash drives, and boot from the flash drive.
The correct way is to use UEFI . - Boot disks of some distributions will swear for lack of memory and will not be able to start. This is true for many other Chromebooks. To resolve the problem, you must tell the loader the kernel parameter mem = 1G.
Problems with the byt-max98090 module and non-working sound
Beach of all Chromebooks on the Baytrail chip. Discussions on the Internet about the native Linux installation on such chromebooks are full of messages that the “sound does not work” ( example ). Most often this happens for the following reasons.
First, byt-max98090 (a kernel module responsible for sound from speakers and headphones) is not included in the standard kernel build of most distributions. (An example of a distribution that includes byt-max98090, - Ubuntu.) If this module does not exist, there will naturally be no sound from the speakers and headphones under any conditions and you will need to rebuild the kernel with the inclusion of byt-max98090. You can check the availability of this module in the system in several ways:
- In the kernel config should be CONFIG_SND_SOC_MAX98090 = m.
- The lsmod command should output this module in the list of others (if it is loaded).
Secondly, even worse, byt-max98090 does not work in many new kernel releases. By typing and web searching I found out the following:
- The Chrome OS installed on this Chromebook (Swanky) is based on the 10/3/19 kernel. In it, of course, the sound works.
- For kernels of version 4.x, on GNU / Linux, sound works in lts release 4.4.23 and earlier.
- Version 4.5 introduced fundamental changes to the sound subsystem and the byt-max98090 module stopped working ( proof ). Non-work byt-max98090 in new kernels looks like this (in dmesg):exhaust dmesg
[6.001164] byt-max98090 byt-max98090: ASoC: CPU DAI baytrail-pcm-audio not registered [6.001298] byt-max98090 byt-max98090: snd_soc_register_card failed -517 [6.041935] baytrail-pcm-audio baytrail-pcm-audio: FW version: 04.05.13.a0 [6.042029] baytrail-pcm-audio baytrail-pcm-audio: Build type: a0 [6.042129] baytrail-pcm-audio baytrail-pcm-audio: Build date: Apr 2 2014 14:14:39 [6.046272] usb 1-3: new high-speed USB device number 2 using xhci_hcd [6.066088] max98090 i2c-193C9890: 00: MAX98090 REVID = 0x43 [6.070340] max98090 i2c-193C9890: 00: use default 2.8v micbias [6.072733] sst-acpi 80860F28: 00: ASoC: Cannot get gpio at index 1: -2 [6.072888] byt-max98090 byt-max98090: ASoC: failed to init Baytrail Audio: -2 [6.073021] byt-max98090 byt-max98090: ASoC: failed to instantiate card -2 [6.073251] byt-max98090 byt-max98090: snd_soc_register_card failed -2 [6.073354] byt-max98090: probe of byt-max98090 failed with error -2
- This situation apparently continues to the present. I collected 4.12.0 and the sound did not work for me, and with the same symptoms as in 4.5 and later.
TL; DR: 4.4.23 - the sound works, in any next kernel release - no.
Thirdly, even if you put byt-max98090 and the kernel of the required version, the sound from the box does not work - you need to perform a couple of actions to unload the kernel modules (see below) and set some necessary ALSA settings. At this stage, they usually give incorrect advice to use another distribution kit or use asound.state from Chrome OS (and such tips are noticed even for such gurus as John Lewis - the author of the most well-known SeaBios firmware for Chromebooks). Such advice can, in principle, work, but it is pure shamanism, because if the sound works in one distro and not in the other, it means that the problem is either in different kernel assemblies or in different configs of alsa / pulseaudio, there can be no other situations. The same with asound.state. Asound.state is just a snapshot of alsa settings. Anything that someone else has put in his asound.state can be put through his alsamixer utility or in a lower-level alsactl, without copying asound.state from anywhere.
So, the following actions include the sound on the baytrail Chromebook and do not require changing the distribution kit or copying asound.state:
- Make sure that we are in the starting situation when the sound does not work:
aplay -D sysdefault: CARD = bytmax98090 /usr/share/sounds/alsa/Noise.wav > ALSA lib pcm_dmix.c: 1030: (snd_pcm_dmix_open) unable to open slave > aplay: main: 786: audio open error: No such file or directory
- Unload all sound device modules (there are two of them in this chromabook - bytmax98090 and HDMI, in each specific case there may be external devices):
modprobe -r snd_soc_sst_byt_max98090_mach snd_hda_codec_hdmi
- Make sure the sound device list is empty:
aplay -L
- Create ~ / .asoundrc with the following contents:.asoundrc
pcm.! default { type hw card 0 } ctl.! default { type hw card 0 } - Download module byt-max98090.
modprobe snd_soc_sst_byt_max98090_mach
- Run alsamixer.
- Make sure the speaker is not on the mute (no MM under the speaker slider. Turns on the M key).
- Remove “Left Speaker Left DAC” and “Left Speaker Mixer Right DAC” devices from the mute.
There are similar devices for headphone output. Please note that the sound in the speakers and the sound in the headphones are configured independently - this is most likely a bug. - Check that the sound has appeared.
These actions are the most obvious crutch with pulling-in of sound modules, designed to solve the wrong order of initialization of sound devices when loading. The correct solution would be to fix the kernel code , so that the sound worked out of the box, but IMHO is unlikely to fix it in the near future.
UPDATE 2 comments aleksandr99: When using UEFI (firmware by reference), the problem with the order of module initialization disappears. In other words, the sound in the core <= 4.4.23 will work out of the box immediately after the start, without requiring actions with lsmod. In newer kernels, unfortunately, the sound will not work under any circumstances.
UPDATE 3 (November 12, 2018): Hurray! On the above-mentioned page of this bug in archlinux , a link to the patch solving the problem appeared in the discussion! Right now, after this patch, I made a sound in the newest kernel - at the moment it is 4.19.
Workaround for frequent eMMC rewrite
A very common problem for this Chromebook, and for many others. The internal drive on it is a soldered eMMC, which means that it cannot be replaced at home and the life of the Chromebook is equal to the lifetime of this drive. And he, like any MMC, has a very limited supply of rewriting cycles. For Chrome OS, this problem does not exist, because every time it is unpacked from a fixed image into memory and almost does not write to the drive, the usual Linux constantly writes to the disk: logs, home directory, etc. There are several solutions to this problem:
- Using a fully initrd-based distribution (Finnix, Puppy Linux) is difficult because of the 2 GB limit.
- Forming your own initrd with all the necessary software is difficult because of the 2 GB limit and the need to understand which system components to put in the initrd - udev, package manager ...).
- Installing the distribution kit on the SD card or USB flash drive. The only drawback is the low read speed from the drive, but there is a huge advantage - simplicity, since the installation is no different from the usual installation on a hard disk, not to mention the low price of SD cards and flash drives.
- Hybrid mode (chosen by me): Normal installation on an internal 16GB drive, but with mounting the most frequently written sections into memory.
The most actively used directories are / home, / tmp and / var / log, so I have the following / etc / fstab:
/ etc / fstab
/ dev / mmcblk0p1 / ext3 defaults 1 1 devpts / dev / pts devpts gid = 5, mode = 620 0 0 proc / proc proc defaults 0 0 tmpfs / home / cheater tmpfs defaults, noatime, nosuid, size = 800m 0 0 tmpfs / tmp tmpfs defaults, noatime, nosuid, size = 100m 0 0 tmpfs / var / cache tmpfs defaults, noatime, nosuid, mode = 0755, size = 190m 0 0 tmpfs / var / tmp tmpfs defaults, noatime, nosuid, size = 30m 0 0 tmpfs / var / log tmpfs defaults, noatime, nosuid, mode = 0755, size = 80m 0 0 tmpfs / var / run tmpfs defaults, noatime, nosuid, mode = 0755, size = 2m 0 0 tmpfs / var / spool / mqueue tmpfs defaults, noatime, nosuid, mode = 0700, gid = 12, size = 30m 0 0
Since the files placed in the RAM only live until the power is turned off, it is necessary to regularly make backups of these files somewhere in a more reliable place, for example, to the same internal drive, to the home server or to the cloud storage. How to implement it - everyone decides for himself, there can not be a universal recipe here.
I will add that a complete power failure on a laptop is an extremely rare event, it is easier if you need to send a laptop to sleep or hibernation. To force a laptop to shut down can only be the need to update the kernel, kernel panic or battery discharge to zero. (I turned off my chromebook only in the first 2-3 weeks after the purchase, the environment has not yet settled, after that I have not turned it off once, only sent to sleep). One more important note - installing Linux, you should never allow the full discharge of the Chromebook to be completely discharged , as this leads to the transition of the Chromebook to the Recovery Mode.
True, there is another unpleasant reason for shutting down, about which the next item -
Power button, vulnerable to accidental clicks
I still do not understand what the creators of this Chromebook were guided by (which, in theory, almost never need to be turned off) and all the other Chromebooks, making the Power button with the usual keyboard key next to Backspace.
In normal laptops, Power is a tiny button somewhere on the side that cannot be accidentally pressed. On the Chromebook, in order to accidentally click on Power, it’s enough to miss the Backspace or the next F-key.
Only one way out - software disable or reassign Power. This does not make it impossible to turn off the PC, because firstly, it can always be done from the console via / sbin / init 0, poweroff, etc., and secondly, the combination “Esc + Power + F3” (reboot in recovery mode) and “hold Power for 5 seconds” (disabling) are absolutely always - they are processed at the BIOS level of Chromebooks.
For systemd-based distributions, this is very easy to do in systemd settings: just set HandlePowerKey = ignore in /etc/systemd/logind.conf and restart systemd-logind or PC.
For other distributions (including Slackware), ACPI handling of the "power button pressed" event is specified in /etc/acpi/handler.sh:
case "$1" in button) case "$2" in power) # /sbin/init 0 logger "Power button is hit" ;; *) logger "ACPI action $2 is not defined" ;; esac ;; *) logger "ACPI group $1 / action $2 is not defined" ;; esac Search instead of caps lock
Another birth injury Chromebooks. There are no Caps Lock keys on them, instead the Search button. You can live without caps caption somehow, but the problem is that many Linux users use Caps Lock to change the layout, and I would like to have a Search key working as Caps, which we are doing now.
This key is recognized not as a search media key (XF86XK_Search), as one would expect, but as a left Win key. Therefore, if anyone is too lazy to perform long settings, you can simply score LWin on switching layouts in the DE or xkb settings of your choice.
Configuration via xkb is done (in my case) as follows:
vi /usr/share/X11/xorg.conf.d/90-keyboard-layout.conf
And add the option:
Option "XkbOptions" "grp: lwin_toggle"
The method is not quite perfect, tk:
- firstly, ideally, it is still desirable that Search work as Caps at the level of scan codes (for example, we have a large self-made layout for xmodmap, in which there are many combinations with caps, and I would not like to rewrite them all).
- secondly, in XkbOptions it is not possible to set Shift + Lwin to switch to the Russian layout (quite a lot of Linux users do this — switch the layout not with caps, but score caps with the English layout and shift + caps with the Russian). Therefore, to tweak, you still have to go to xmodmap.
So the correct way is to reset LWin to Caps at a low xkb level in xmodmap. Mapping xmodmap each configures in its place (~ / .Xmodmap, start script ...), but the action is the same everywhere:
keysym Super_L = Caps_Lock
Note: All that has been said about the keyboard refers only to the setting of keys under the X server (xkb). Other utilities are used in the console (in Slackware, they are represented by the kbd package) and the key resetting tool is loadkeys. Setting kbd in the article will not be considered.
UPDATE 2 (via mrobespierre ) :
Using zram to bypass the problem of lack of RAM
2GB of RAM is nothing by today's standards, and on a chromebook with such a small memory it is very easy to fly out of its limits, and a swap comes into play, which means that the drive will wear out even faster. To combat this effect, there is a zram module in the Linux kernel for a long time that deals with data compression in RAM on the fly. So the advice here is simple: it is highly recommended to enable zram on this chromebook and use it for swapping. Again, there are many scenarios for how to enable it - in fstab, in rc.local. For an example - completely manual inclusion:
lsmod | grep zram || modprobe zram || echo "error inserting zram" echo 1,000,000,000> / sys / block / zram0 / disksize # 1GiB fdisk -l | grep / dev / zram0 || echo "missing zram0 device" mkswap / dev / zram0 swapon / dev / zram0
Usage scenario
There is nothing much to tell about work on this laptop with stock Chrome OS - everything is the same as in any other Chromebook and there are dozens of articles and commercials on this topic. The central part of the system for the user is the Chrome browser. There are no applications in the classic sense - they are plugins for Chrome and web services opened in the browser. Among the usual - GMail, Google Docs, Google Drive, Hangouts. If you dig into the plugins, you can find the SSH client , VNC client , RDP client , Samba client , various text editors, graphics, etc. The speed and functionality of such plug-ins, as a rule, in the area of ​​the plinth. In theory, you can install native applications by replacing Chrome OS with Chromium OS and repacking the image , but this entertainment is only for the strong in spirit, and is clearly beyond the scope of this article. Everything works without special brakes, Chrome regularly loads pages, movies and music are played, although the set of video and audio codecs is far from complete and some formats cannot be played (and, unlike desktop OSs, there is no possibility to install codecs).
In Developer Mode, everything is a bit more fun, you get access to bash, the file system and work under the root. In such an environment, the most straightforward way to extend the functionality of a Chromebook is to chroot into the root directory with normal Linux (on a flash drive or on an internal drive), which is exactly what the well-known crouton utility does. Today, more modern than chroot, containerization tools, such as LXC, are relevant, but I don’t know anything about the possibility / complexity of using them in ruled Chrome OS.
A more fundamental modification of the Chromebook is the complete removal of Chrome OS from the drive and the installation of its OS (hereinafter I will assume that this is Linux, although in fact, of course, there are other options).
What a user gets when installing native GNU / Linux:
- A free OS with full control over it;
- All the hardware resources of the Chromebook, as opposed to chroot / crouton, and more simply built environment;
- The usual root system with the ability to write (unlike Chrome / Chromium OS, unpacked from a readonly image every time). This approach has its drawbacks, but at least it is simpler and more familiar;
- A complete set of familiar desktop applications instead of chromic plugins that mimic them.
- Significantly less dependent on the Internet if you rely on local applications and data.
On my laptop, this option is implemented - the “clean” Slackware 14.2 is installed.
The tools are quite austere, so the power requirements of the laptop are very low. The graphical environment is dwm, a small tile-based window manager in C. Virtually all applications that I use use a text interface. Central among them is Emacs - I write code and any text in it, read email and RSS (Gnus), communicate in jabber and irc, keep notes and work plans (Org-mode), visit text web pages (w3m). There are few other user applications, the main ones are dwm (web browser), mpd + ncmpc (music), zathura (pdf viewer, djvu, etc.) and TeX Live (mathematics text layout system). Sometimes I watch movies (mplayer) and play games like Warsow, ADOM, Aquaria and Wangers. I am developing mainly in C ++, Perl, C.
The power of Chromebook for the listed software is enough. It starts to slow down on web pages that actively use js and flash, and unfortunately in almost all games, except for very minimalistic ones (Aquaria, Wangers, and of course ADOM).
The system with all the tools (the applications mentioned above, TeX, Perl, GCC and all related development tools) occupies 2.7 GB of the available 16 GB, the rest of the place is not used at all. All large data (media files, backups, virtual machine images) and generally all permanent data are stored on the home server, to the disk of which I connect via sshfs or nfs. Locally, on the Chromebook, I usually store only what I work with for the current day — usually a pair of books, a copy of the contents of the mailbox, a copy of 2-3 repositories with code, and a copy of the Org-mode database. At the beginning and at the end of the working day I synchronize with the server. Thus, Chromebook gets a very high autonomy, impossible in Chrome OS.
Source: https://habr.com/ru/post/336044/
All Articles