In a previous post I explained my decision to choose a Lenovo Thinkpad X131e Chromebook for use as my regular laptop running Bodhi Linux. In this post I will describe the steps I took to install Bodhi on the Thinkpad Chromebook. In previous posts I discussed using a Samsung Series 3 Chromebook, initially to run the installed Chrome OS, and then to run Bodhi Linux. Because of my experience installing, and in fact building install tools and images of Bodhi Linux for the Samsung Chromebook I assumed installing Bodhi Linux on the Thinkpad Chromebook would be fairly simple. Although my previous experience provided me the basic steps, I did run into some issues and surprises.
When I wanted to install Linux on the Samsung Chromebook, there were quite a few posts describing how to do so for Bodhi, Ubuntu, Kali, Debian, and other Linux distributions. I was initially surprised that I could find little or no similar documentation for the Thinkpad Chromebook. Upon reflection, I realized that this was probably largely due to the fact that Lenovo has targeted the Thinkpad Chromebook at the education market. They in fact offer non-Chromebook versions of the Thinkpad X131e for the mainstream market. Because the Lenovo Chromebook was not more generally available is a major reason I opted for the Samsung Chromebook in the spring of 2013.
So in looking for alternate OS installation documentation on the Thinkpad X131e Chromebook, not much was available. I did of course find the instructions for entering Developer Mode on the Chromebook, which of course is a prerequisite for attempting any alternative installation. Additionally, I saw references to the fact that the firmware was coreboot. Additionally, there were a few more details on the specific version for the various Chromebooks here.
On newer Chromebooks, like the Acer C720, which have seabios firmware, it is possible to use Ctrl-L (once in developer mode) to boot alternate OS (for example a Bodhi ISO image). This is called a legacy boot. Alas, the Thinkpad X131e Chromebook apparently does not have that level of firmware. In fact I was not able to find detailed information on the capabilities of alternate booting using the coreboot stout firmware on the Thinkpad Chromebook. I did not entertain the idea of changing the firmware. I don't know if it is even possible. I did notice on the Lenovo Chromebook that partition 12 on the main disk (SSD) appeared to be boot configuration. Partition 12 (hexadecimal 0xC) was similarly boot configuration on the Samsung Series 3 Chromebook, although the two configurations look markedly different. The partition has the label "EFI-SYSTEM" and has the type "EFI System Partition".
Examining the EFI Partition
The Thinkpad Chromebook partition 12 has two directories: efi and syslinux. Under the efi directory, there is a single directory, boot. It contains 3 files bootia32.efi, bootx64.efi, and grub.cfg. The two efi files appear to be UEFI applications. The grub.cfg file appears to be a GNU grub configuration file. I think it may be a particular type used with EFI. The grub.cfg file has 5 menu entries, two for local images ("local image A" and "local image B"), two for verified images ("verified image A" and "verified image B") and one labelled "Alternate USB Boot". This last menu entry contains:
linux (hd0,3)/boot/vmlinuz quiet console=tty2 init=/sbin/init boot=local rootwait ro noresume noswap loglevel=1 noinitrd root=/dev/sdb3 i915.modeset=1 cros_efi
According to documentation I have read, this implies that it is booting off of /dev/hda4 (note that the first is 0, not 1). I believe /dev/hda is mapped to /dev/sda which means we are talking here about booting from /dev/sda4. When I use the cgpt command to examine the partitions on /dev/sda, I see that /dev/sda4 is the Chrome OS kernel with the highest priority. So it appears what is happening here is that it boots the kernel at /dev/sda4 and uses the root filesystem at /dev/sdb3. /dev/sdb is the first USB disk recognized by the system. The implication is then that it partition 3 on a USB drive recognized as /dev/sdb was a root filesystem and that grub menu entry were chosen, that system would be booted. The grub.cfg file has the default set at 2. Since grub entries apparently start at 0, that means the third entry ("verified image A") is booting by default. Perhaps if I modified the grub.cfg file to have the default at 4, I could boot off the first USB disk if the root filesystem partition was partition 3. I have not tried making this change. I don't know if this would work, given that I do not see a grub boot menu even if I hold down the shift key, which I believe would normally show you the boot menu. Note that when I tried the shift key when booting I was already in developer mode.
The syslinux directory contains several configuration files and what appears to be two kernel files (vmlinuz.A and vmlinuz.B). There is a a README file that states:
Partition 12 contains the active bootloader configuration when booting from a non-Chrome OS BIOS. EFI BIOSes use /efi/* and legacy BIOSes use this syslinux configuration.
I am not sure how to use this syslinux configuration, given that I believe the Chromebook has by default an EFI BIOS. Perhaps if I tried rewriting the BIOS I could use this, but I am not considering doing that at this point, even if I could.
After all this investigation, I determine I would try the same approach I had used on the Samsung Chromebook. Perhaps more documentation on the Lenovo Thinkpad X131e BIOS will appear at some point and more options will become obvious.
Note added March 26, 2014: I discovered a discussion of kernel boot modes. There are 3 boot modes for chromebooks: cros_secure, cros_efi, and cros_legacy. Partition 12 efi directory would be used with cros_efi mode, while the syslinux directory would be used with cros_legacy mode. You can view /proc/cmdline to see which mode is used (it should be at the front). I have seen cros_secure being used on my Thinkpad Chromebook. I don't know how to change the mode. It has been suggested that I would have to install updated firmware to have it change.
Using the Approach I Used on Samsung Chromebook
Given that I couldn't use the legacy boot approach used on newer Chromebooks like the Acer C720 and given that I couldn't figure out how to boot alternatives looking at partition 12 of my Thinkpad Chromebook, I decided to try the same approach I had used with the Samsung Chromebook. Initially I attempted to boot from a USB drive, as this is easier than modifying the main SDD in the Chromebook. The steps I need can be summarized as follows:
- Use parted to create a GPT partition table
- Use cgpt create to create/reset the partition table
- Use cgpt to create the partition for the kernel (which will be Chrome OS)
- Use cgpt to create the partition for the root filesystem
- Copy the root filesystem to the second partition
- Remove /lib/modules and /lib/firmware in the copied partition and copy them from the Chrome OS filesystem being used. This is necessary because these modules and firmware match the Linux (Chrome OS) kernel to be used.
- Repack the running Chrome OS kernel into the first partition, using the needed boot parameters. Note that this step must be executed on the Chromebook being used.
Dealing with Thinkpad-Specific Issues
Once I had an image to use and an approach, I created a new installation script based on the initial Samsung Chromebook version. Right away, I had to investigate differences between the Samsung and Chromebook machines, other than the difference in architecture.
First I had to put the machine in Developer Mode. Each Chromebook is different. On the earliest models there was an actual physical switch. On later models like the Samsung Series 3 Chromebook, there was a key sequence you needed to use when powering on the machine. For the Thinkpad, it was actually more complicated. There was a similar key sequence, but that sequence could only be used after first removing power (both AC and battery), and then use the proper key sequence within 20 seconds after reapplying power (e.g. reinstalling the battery). The steps are described here. Note that I did not verify whether the 20 second limit is accurate. Secondly, although removing the battery sounds difficult, it is actually quite easy to do on Thinkpads.
Second, I needed to understand how the devices were mapped. On the Samsung the main drive (SDD) is called /dev/mmcblk0. When I used the blkid command (with sudo) I found that the main drive (SDD) was instead /dev/sda. This meant that instead of making sure not to overwrite the wrong device when creating my boot USB, I had to understand that /dev/sda was the main drive. I also need to know this to locate and repack the running kernel.
The third part I could only learn by experimentation. For some reason, there are limitations as to which USB ports can be used for booting. On the Samsung Series 3 Chromebook there is a USB 2.0 port and a USB 3.0 port. Only the USB 2.0 port can be used for booting. The Lenovo Thinkpad X131e Chromebook has two USB 3.0 ports and one USB 2.0 port. My only successful attempt to boot from USB occurred when I used the USB 2.0 port. Note that it seems USB 3.0 ports are marked in blue inside, while USB 2.0 ports are not. On the Thinkpad Chromebook, the USB 2.0 port is on the right side and marked in yellow.
Using the USB drive (one that I had successfully used on the Samsung--some USB drives do not work for some reason), I was able to boot the machine. However, I immediately encountered issues. First the login screen appeared, but clicking on the default userid (I had a default userid and password in the image) did not seem to do anything. However, when I used Ctrl-Alt-F1 to change to virtual terminal 1, and then Ctrl-Alt-F7 to go back to the X display the screen was refreshed. Now I saw the password prompt. I entered the password. It did not appear that I was typing (I should have seen asterisks), but when I hit enter the screen changed. I had actually tried an older Bodhi x86 install image earlier and had seen the same problem. On the older Bodhi image at this point I saw the enlightenment desktop. On this newer image, created with newer graphics packages for the Acer C720, I saw a blank screen.
I saw the version of intel graphics package installed and went searching for a report of issues for this package and adapter. I didn't find a solution right away, but I did find this page about the driver and possible configuration. I decided to try using UXA instead of SNA acceleration. I did this by adding a 20-intel.conf file in /usr/share/X11/xorg.conf.d containing:
Option "accelMethod" "uxa"
I did this by using Ctrl-Alt-F1 to change to virtual terminal 1 and using sudo and vi to add the file. I rebooted. I again had the problem with the login screen, but once I used the Ctrl-Alt-F1/Ctrl-Alt-F7 sequence to get past that, I now had my enlightenment desktop. Note that with recent open-source video drivers, xorg configuration is typically not needed. Instead, they use kernel modesetting (KMS). Apparently, I needed to add the aforementioned xorg configuration entry to bypass a bug.
Solving the problem with the login screen took much longer. I tried other login managers (the default with the Bodhi install was LXDM), like LightDM, GDM, etc. All had similar problems. Since the i915 Intel driver was being used, I started searching for issues with that. I found this Debian bug report, which talked not about a blank screen but about screen corruption. I decided to try adding i915.i915_enable_fbc=0 to the boot parameters. Once I did this (by modifying my installation script to include this boot parameter when repacking the kernel), my login screen issues went away. Note that the setting I added turns off frame buffer compression.
At this point I had what appeared to be a properly working Bodhi Linux system.
One other issue I ran into was that occasionally I would lose my wireless connection. It would ask for the password for my wireless access point that I was previously connected to but re-entering did not help. I could only get it back by rebooting. In looking around I found that some people using the ath9k driver solved issues by adding /etc/modprobe.d/ath9k.conf (using sudo) with contents:
options ath9k nohwcrypt=1
So far it seems to be working, but it will probably take a few days to know for sure.
Note added March 26, 2014: I continued to have occasional wireless issues even with the above settings. I recently booted into Chrome OS and updated to the canary channel, which installed a new kernel (still 3.8.11, but dated 3/24/2014). Since then I haven't seen wireless issues, but only time will tell.
Note added March 26, 2014: I recently began experimenting with bodhi 3.0.0 alpha, which is based on Ubuntu 14.04. I ran into a boot issue where there was a long delay at boot time, seeming related to plymouth. I saw the following error message:
plymouthd: ply-terminal.c: 611 ply_terminal_open: Assertion `terminal != ((void *)0)' failed.
After a long period of time (sometimes 2 minutes), the login screen would appear. To work around this issue, I added (as sudo) the file /etc/initramfs.conf/conf.d/splash and added the line:
and then executed the command (as root):
update-initramfs -k 3.8.11 -u
and rebooted. I am still seeing the error message, but I no longer have the long delay. I found the above setting related to some plymouth bug reports. Only time will tell if it resolves the issue, as it did not happen every time.
Comparing Bodhi on Thinkpad Chromebook vs. Samsung
In my previous post, I explained reasons for moving to the Thinkpad Chromebook for Bodhi and away from the Samsung. The main reason was of course the ARM architecture. I will list here a few of the advantages:
- Audio worked immediately, without having to investigate special settings. The main speaker was muted when I used the headphone jack, something I never got working on the Samsung (using Linux).
- The backlight control worked immediately, without having to investigate special settings.
- The backlight turned off when the screen blanked (unlike the Samsung which didn't)
- I was able to use Ctrl-Alt-F1 to switch to virtual terminal 1 and Ctrl-Alt-F7 to switch back to the graphical screen. On the Samsung I could never switch back.
- Booting is faster. While the boot time (from the main SDD) on the Samsung was about 10 seconds, on the Thinkpad it is even faster.
- On the Samsung sometimes when I would boot the cursor would be frozen. I would have to power off and start again. I haven't encountered this on the Thinkpad.
- The filesystem for Bodhi on the Samsung (ARM) Chromebook is based on debian, while for x86 machines the filesystem is based on Ubuntu. Yes, Ubuntu is based on Debian, but the x86 filesystem uses Ubuntu packages and the Ubuntu repository. This means things like the Bodhi Linux AppCenter work properly, since such things assume Ubuntu repositories and packages, not Debian.
In this post I have described my experience in determining how to get Bodhi Linux installed on a Lenovo Thinkpad X131e Chromebook. I can say at this point I much happier with the state of Bodhi on my Thinkpad Chromebook than the Samsung, despite the months of effort I spent on improving the experience on the Samsung. In a future post, I will describe how to access and use my installation script to install Bodhi Linux on the Thinkpad Chromebook.