The third-generation Amazon Kindle is unlike any other e-book reader we’ve handled before: and that includes the new Amazon Kindle DX (Graphite).

Leaving aside the obvious giveaways – smaller size, less wasted real estate around the edges, new button design, new colour – you only have to hold the Amazon Kindle 3 to realise that you are in new e-reader territory. The third-generation Kindle comes in two versions: the Kindle Wi-Fi retails for £109, and it costs £149 for a 3G and Wi-Fi version. This is the same as the 3G-only Amazon Kindle 2 cost previously, and is the first device launched specifically into the UK.

(Incidentally, if Amazon asks, we didn’t call this device the Amazon Kindle 3. Amazon says its name remains simply ‘Kindle’, but for simplicity’s sake we’ll go with ‘Amazon Kindle 3’ for this review.)

The Amazon Kindle 3 comfortably hold a Kindle e-reader in one hand. At 246g, the Kindle is not the lightest such device on the market, but it is lighter than Barnes & Noble’s Nook. And the new Kindle is 15 percent lighter than its predecessor; between its lighter weight and its more compact design, we could immediately tell that using the third-generation Kindle would be a more pleasing experience than with earlier models. The unit felt very balanced in-hand, and the buttons felt like they were in convenient, ergonomic places (more on that in a moment).

What’s notable is that Amazon achieves its design improvements even while adding features (notably, Wi-Fi), and boosting the screen technology.

Clearly, the new Kindle looks vastly different. For starters, it now comes in graphite, like its big brother, as well as in white; in our experience, the darker border enhances readability, as would be expected given the visual perception a dark border provides. But the display is dramatically better in its own regard: Like the Kindle DX (Graphite), the Kindle now has a 6-inch E-Ink Pearl display, which boasts faster refresh rates and 50 percent better contrast. As on Kindle DX (Graphite), blacks look more solid, and text is smoother.

The physical design is smaller, too – by 21 percent, according to Amazon. If you look at the numbers alone, it doesn’t feel as if that much has been shaved off: The new model measures a stout 190x122x9mm, as compared to the 203x135x9mm of the Amazon Kindle 2. But the difference felt more dramatic when holding the device (an act also made easier by the rubberised backing).

To achieve this smaller design, Amazon has in essence trimmed the white space around the bezels, to give the Amazon Kindle 3 a tighter and more efficient presentation. The effect is that the device is now dominated by its 6-inch screen, although there’s still enough room around the edges for your fingers to comfortably rest. The keyboard has been tightened, with the keys slightly closer, the row of numbers removed (to get to numbers, you now have to press the symbol button, much like on a touchscreen mobile phone’s keyboard). The navigation buttons have been clustered together and rearranged; and more notably, the page forward and back buttons have shrunk dramatically, to just one-quarter of an inch wide.

Indeed, all of the buttons have been redesigned on the new Amazon Kindle 3, to great effect. The screen is now flanked by simple forward and back buttons, mirrored in size and shape, and connoted by arrows, as opposed to words (as on Kindle 2). By having these buttons on both sides, the Kindle is especially handy for both left- and right-handed users.

One of the things we disliked about the Kindle 2 was that the page-forward and -back buttons depressed inward, into the screen. The much slimmer buttons for this third-generation Amazon Kindle 3 now depress away from the screen, a rocker style button that melds into the edge of the device. We prefer this approach, as fingers don’t need to hover in a single place to turn the page; instead, we could mix up our hand’s location, and still turn the page with a palm heel, or even the length of our thumb – either a vastly superior experience.

The Amazon Kindle 3’s keyboard buttons are more rounded, and by being closer together, we found the keyboard easier to type on than that of the Kindle 2. The experience was more akin to what we’re used to on a physical mobile phone keyboard.

As already noted, the navigation buttons are completely overhauled. The Home button has moved to the bottom of the Amazon Kindle 3’s keyboard, and the joystick navigation cluster of Kindle 2 replaced by a D-pad like approach with a 5-way navigation square, with an oval Menu button above it, and a Back button beneath it. We found this organisation easy to adapt to, and certainly better than the comparatively stiff joystick. We look forward to trying a shipping unit for a longer period to see how well the navigation works in practice.

Speaking of navigation, one thing is very clear: the navigation is noticeably faster. We could breezily scroll through menu items with practically no lag; previously, we’d have become frustrated by the sluggish responsiveness of the Kindle 2 (never mind competitors like Kobo, which is interminably slow). Page turns are 20 percent faster, too; based on our limited hands-on, that stat translates into a more zippy experience, but again, the full impact will be more obvious when we get to use the device for hours, not minutes, of reading.

While the overall design of the e-reading experience remains unchanged, Amazon has added some new and noteworthy features. For the first time, you can change line spacing (choose between small, medium, and large), and you can finally change typeface (choose from regular, condensed, and sans serif). While we would have like to see some other options, and see the names presented in sample text, much like how the font size options are represented, we’re glad to see Amazon add the ability to change fonts, given that’s a feature Nook and most all LCD-based e-readers have had for some time.

Like the Kindle DX (Graphite) and updated Kindle 2, the Amazon Kindle 3 supports sharing passages via Facebook and Twitter. And, it supports viewing popular highlights (aggregated from the data of what passages Kindle users are sharing). Uniquely new for this Kindle: a WebKit-based Web browser. The browser is still classified as experimental, but it provides a better experience than before.

The new Amazon Kindle 3 doubles the internal memory from 2GB to 4GB, which Amazon says translates into 3500 books (up from 1500). Amazon now claims Kindle has up to one month of battery life; the company says its battery technology hasn’t fundamentally changed, but rather it has achieved double the performance of Kindle 2 through software.

Group test: what’s the best e-book reader?


The Amazon Kindle 3 made an unusually quick, and positive, impression. The new Kindle’s solid build quality, improved design, integrated store, and cross-platform transportability (books are usable on any Kindle reader app, including iPhone, iPad, Android, BlackBerry, and PC) all add up to a winner poised to top the pack.



The slicker, faster Amazon Kindle is a real step forward. There are a few navigation kinks, but the addition of subscriptions, extract-sharing, fast searching and the ability to successfully access other parts of the web make this an enjoyable device to use.

As of 2016-09-06, the Firmware Utility Script now offers Full ROMs offering either Legacy Boot or UEFI Boot for all Haswell and Broadwell devices (as well as for both the SandyBridge and IvyBridge variants of the Acer c710). UEFI (Unified Extensible Firmware Interface) is the successor to Legacy BIOS and is the firmware type used by virtually all Windows PC’s (and Macs) shipped in the last 5+ years.

UEFI functionality is provided by the Tianocore coreboot payload. The boot screen shown above is accessed by pressing any key (other than Enter) during the ~3s boot timeout (there will be a brief progress bar across the bottom, as well as a blinking cursor); if no key is pressed, it will attempt to boot any externally-connected devices, followed by the internal storage (unless you opted to prioritize internal storage at the time of installation). If not UEFI boot devices are available, it will simply take you to the screen above. If you didn’t get your USB boot media inserted in time, simply power off and back on.

UEFI firmware on ChromeOS devices offers many benefits over the existing Legacy BIOS offerings:

  • Better Windows support and faster Windows boot time (50%+ faster)
  • Full working HDMI audio under Windows, without any special drivers or hackery
  • Support for compressed Windows installs (under 5GB for Windows 8.1)
  • Better support for dual/triple/quad boot scenarios
  • Ability to run OS X / MacOS on Core i3/i5/i7-based machines
  • Better support for USB devices at boot time (SeaBIOS was/is quite finnicky)

And a few more I’m forgetting as well.

This initial UEFI firmware release chain loads a special Tianocore package on top of SeaBIOS (which is stripped down to the minimum needed to load Tianocore) in a manner invisible to user. It also has a few limitations: among other things, it lacks the ability to boot in Legacy Mode (often referred to as UEFI-CSM; this will likely never be implemented), and — critically — it lacks the ability to change/save settings, including the default boot device (though this can be set at time of install). Another side effect of this limitation is that a UEFI bootloader (like rEFInd) is requried for multi-OS booting, or for booting any OS which doesn’t install its own bootloader into the default UEFI boot path (/EFI/BOOT/BOOTX64.efi). The UI is also not as polished as other UEFI implementations, but that’s open source for you 🙂

All of these issues are being worked on, and hopfully in the near future all Full ROM firmware offered by the Firmware Utility Script will be fully UEFI-compatible. For now, feel free to check the status on/report any issues on the Github tracker.



Building your own kernel and installing it in the Chromebook isn’t
that hard, but there are a couple of extra steps needed.

The kernel resides in the boot partition, and it has to be signed for
the verified boot firmware to load and boot it. In developer mode,
it can be signed with any key though, including the default developer
keys provided on the Chrome OS filesystem.

To make life easier on Ubuntu, I copied over some of the tools from
Chrome OS. One of them needs libssl 0.9.8, so you need to install that:

# apt-get install libssl0.9.8

Then, the vbutil_kernel tool is used to pack and sign the kernel image
that is written to disk. You’ll also want to install the keys, etc:

# mount -o ro /dev/mmcblk0p3 /mnt
# cp /mnt/usr/bin/vbutil_kernel /usr/bin
# rsync -a /mnt/usr/share/vboot /usr/share

There’s also another tool that is convenient to have, dump_kernel_config.
It actually dumps the command line, not the kernel config, from a packed
kernel image. You can also use vbutil_kernel to do it, but this tool is
more practical for scripting. So, also:

# cp /mnt/usr/bin/dump_kernel_config /usr/bin

Also, if you haven’t already copied over cgpt, do so now.

# cp /mnt/usr/bin/cgpt /usr/bin

And then, of course:

# umount /mnt

Now you have the tools you need on the filesystem. Just to make sure they
work, try verifying the current kernel on the disk. So:

# vbutil_kernel –verify /dev/mmcblk1p1

Now, configuring and building a kernel is something that I will mostly
skip over here. People like Marcin Juszkiewicz and others who clean up
my rough instructions and package things up for the distro will sort
most of that out. Just a couple of quick pointers:

The sources for the Chrome OS kernel are at The
current active branch there is chromeos-3.4. To find the branch that
corresponds to the release that your Chromebook runs, see the release-R*

To generate the kernel config that we build with, besides getting it
from /boot on the Chrome OS filesystem, you can (in the source tree) run:

$ chromeos/scripts/prepareconfig chromeos-exynos5

It will create the .config file for you.

Then just use the regular distro build tools (make-kpkg), or just make
+ make_install. If you want/need to rebuild the kernel, you probably
know how to do these things already. If not, just use the kernel
copied over from Chrome OS.

The one thing I’ve done differently than the default build tools
is that I tend to also do a “make dtbs” and copy the contents from
arch/arm/boot/dts/*.dtb into /boot. The script below uses those paths
so revise accordingly if you don’t do the same.

So, the kernel format used on ARM Chrom{e,ium} OS is a combined format
called FIT Image. It’s produced by the mkimage u-boot tool, which is
provided by the u-boot-tools package on Ubuntu:

# apt-get install u-boot-tools

Then you need a source file (kernel.its). Mine contains:


/ {
description = “Chrome OS kernel image with one or more FDT blobs”;
#address-cells = <1>;
images {
description = “kernel”;
data = /incbin/(“/boot/zImage”);
type = “kernel_noload”;
arch = “arm”;
os = “linux”;
compression = “none”;
load = <0>;
entry = <0>;
description = “exynos5250-snow.dtb”;
data = /incbin/(“/boot/exynos5250-snow.dtb”);
type = “flat_dt”;
arch = “arm”;
compression = “none”;
algo = “sha1”;
configurations {
default = “conf@1”;
kernel = “kernel@1”;
fdt = “fdt@1”;

Then, to create the binary kernel image, you do:

mkimage -f kernel.its kernel.itb

That creates kernel.itb as the binary image. Finally, you need to sign
this with the verified boot tools. You also need to specify the kernel
command line as part of this. The command to do so is:

$ echo “console=tty1 debug root=/dev/mmcblk1p3 rw rootwait” > config.txt

$ vbutil_kernel –pack /tmp/newkernel \
–keyblock /usr/share/vboot/devkeys/kernel.keyblock \
–version 1 \
–signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \
–config config.txt –vmlinuz kernel.itb –arch arm

Then you write out the newly generated kernel to disk. I use the second
kernel partition for my test kernels:

# dd if=/tmp/newkernel of=/dev/mmcblk1p2

Then you need to mark the second kernel partition bootable, and you need
to mark it as higher priority than the first kernel partition. Here is
where verified boot has a feature that is very convenient when you are
testing new kernels:

If you mark the kernel partition as higher priority, but don’t set the
“successful” bit in the partition table, it will try to boot it as
many times as the “tries” field specifies, decrementing it each time.

This means that if I want to try booting a kernel just once, and if
that doesn’t work, boot back to the known good kernel, I will set it to
something like:

# cgpt add -i 2 -P 15 -S 0 -T 1 /dev/mmcblk1

In other words: For partition index 2 (mmcblk1p2), set priority to 15,
successful to 0 and tries to 1. Since the first partition has priority
10, it means this will be tried first, as long as the tries counter is >0.

To see what your settings are, use:

# cgpt show -i 2 /dev/mmcblk1

(and compare with -i 1).

That mostly wraps up most of what I was planning on writing up so far.

Based on my descriptions here, it seems like some of the distro guys
have gotten enough going that they are mostly self sufficient. I’m of
course happy to help answer questions, and I want to make sure that the
platform is convenient to work on once we have upstreamed most of our
kernel changes over the upcoming months, but beyond that I’ll leave most
of the polish and packaging up to others.

GPT stands for “GUID Partition Table” and it refers to a relatively new format for disk partition tables. It was designed to get around the limitations of the MBR format, namely that you can have more than 4 primary partitions and partitions can be more than 2.2 terabytes in size. GPT is part of the EFI standard but it can also be used on standard BIOS only machines i.e. most non-MAC PCs. Converting to GPT will allow you to future proof your partitions. 2 TB disks are becoming common and it won’t be long before the 2.2TB limit of MBR will stop people using all their disk space in one partition, so in the name of usability and flexibility GPT is the way forward.

The procedure is as follows:-

  1. Backup, backup and thrice I say backup!
  2. Make sure you have enough space at the start of your disk for a “BIOS boot partition”.
  3. Make sure you have enough space at the end of you disk for the backup/redundant partition table.
  4. Install and run gdisk otherwise known as “GPT disk”.
  5. Reinstall grub to the boot sector.
  6. Reboot and cross your fingers.

Backup, backup and thrice I say backup!

I’m not going to go into too much detail here. Suffice to say, make sure you have recourse if everything goes mammarys up. Suggestions include using Rsnapshot to backup the whole of the machine to another and using dd to backup the existing boot sector and partition table i.e. for dd:

dd if=/dev/sda of=bootsect.img bs=512 count=1

Or instead of using rsnapshot you could use dd, gzip and SSH to copy each partition to another machine on your network i.e. :

dd if=/dev/sda1 | gzip | ssh root@192.168.x.x dd of=/backup/laptopsda1.img

Once you are sure everything is backed up and available if needed, continue on.

Make sure you have enough space at the start of your disk for a “BIOS boot partition”.

Happily if you have done a “fresh” install of Lucid Lynx a.k.a. Ubuntu 10.04 LTS, your partitions will be aligned to a 1MB boundary for new disk and SSD performance reasons, which will leave just enough space of nearly 1MB to install the GPT version of Grub 2.

Happily for me, although my Ubuntu install has been in existence for a few years, I already manually aligned the partitions.

If you are in neither of the above camps I can only recommend running GParted Live, to move the start of the first existing partition, and make the required space.

Make sure you have enough space at the end of you disk for the backup/redundant partition table.

Because I have home on it’s own separate partition, I was able log out, shut down GDM, and unmount the last partition on the drive while the system is running, like so:

service gdm stop
umount /dev/sda3
e2fsck -f /dev/sda3
resize2fs /dev/sda3 xxGB
fdisk /dev/sda
partprobe /dev/sda3

Making sure when deleting and recreating the partition that it isn’t smaller than the file system size.

Alternatively you could again use the GParted Live CD to free up the space (probably safer anywho).

Install and run gdisk otherwise known as “GPT disk”.

apt-get install gdisk
gdisk /dev/sda

When you start gdisk for the first time it will automatically convert the partition tables to GPT, but it will not save them unless you exit by hitting “w”. If you haven’t managed to create a megabyte or 2 of space at the end of the disk gdisk will complain about the redundant partition table “overlapping the last partition by xx blocks”. Assuming you have got this far your partition layout should look something like this when you press “p” to print:

Number  Start (sector)    End (sector)  Size       Code  Name
 1            2048          309248   150.0 MiB   0700  Linux/Windows data
 2          311296        17577984   8.2 GiB     0700  Linux/Windows data
 3        17580032       125206494   51.3 GiB    0700  Linux/Windows data

We then need to create the “BIOS boot partition” where part of Grub 2 will reside. Type “n” and return. Hit return again to accept the next available partition number. Type “34” and return for the first sector and hit return again to accept the default last sector (which should be 2047). Type “ef02” and return to set the partition type. Partition layout should now look something like this:

Number  Start (sector)    End (sector)  Size       Code  Name
 1            2048          309248   150.0 MiB   0700  Linux/Windows data
 2          311296        17577984   8.2 GiB     0700  Linux/Windows data
 3        17580032       125206494   51.3 GiB    0700  Linux/Windows data
 4              34            2047   1007.0 KiB  EF02  BIOS boot partition

At this stage you should be able to type “v” and return and get similar output to this:

No problems found. 4094 free sectors (2.0 MiB) available in 2
segments, the largest of which is 2047 sectors (1023.5 KiB) in size

At this point if you are happy everything thus far has gone to plan you can type “w” and return to save the partition layout to disk.

Reinstall grub to the boot sector.

At this point you should be able to run

grub-install /dev/sda

and get no errors.

This will install the GPT version of the bootloader into the little BIOS boot partition we created earlier.

All that remains then is to reboot and fingers crossed your machine will come up. Happy days!


Wikipedia GPT definition –

GPT Disk tutorial from the author –

The overall problem.

Work have given me a MacBook Pro to use, although they’re not too enamoured at the thought of me putting Linux on the internal SSD. I must haz Linux.

The overall answer.

I had a 128GB M2 SSD in my Acer Chromebook 15 at home, so I purchased a USB M2 SSD enclosure/adapter, with a view to using Linux via it and my SSD on the MacBook Pro, and it being fast.

The problem MKII.

Once I had Linux on said SSD in said enclosure/adapter, and booting on said MacBook Pro, I was unable to boot it on my Acer Chromebook 15 running SeaBIOS. I guess a secondary reason for me wanting the SSD in the enclosure, would be that I could take my OS, boot it “anywhere”, and it would be fast (i.e close to the theoretical maximum of USB 3.0 with very low latency, at least on a device with USB 3.0). The basic problem is that the Mac uses UEFI and the Chromebook uses “legacy” BIOS. Both have differing mechanisms for boot.

The answer MKII.

So, the answer turned out to be putting a “bios_boot” partition on the SSD in the first one meg (obviously not over the mbr and partition table), installing Grub again, and fiddling with the grub config a little. In this way the external SSD boots on both UEFI and Legacy BIOS systems.

How did you do that?

I referenced an article I wrote 5 years ago and did a little sideways thinking:

The commands would be as follows, assuming the internal SSD is /dev/sda and the external SSD/enclosure is /dev/sdb:

  1. Backup the existing first 1 MB of the drive – sudo dd count=2048 if=/dev/sdb of=mbr.gpt.bak
  2. sudo gdisk /dev/sdb
  3. Type n
  4. Type 3 (assuming that partition number is available)
  5. Type 34 (this is the starting sector of the partition we’re creating)
  6. Type 2047 (this takes the partition up to the one meg boundary)
  7. Type ef02 (this makes the partition the “bios_boot” type)
  8. Type w to save and quit.

I then reinstalled Grub to the SSD:

sudo grub2-install --target i386-pc /dev/sdb

For some reason it wouldn’t work without the target specified. Then I had to get around the Grub config.

The primary difference between Linux booted on UEFI, and Linux booted on Legacy BIOS, is the command to load the kernel/initrd. In UEFI this is “linuxefi” and “initrdefi”, in Legacy BIOS it’s “linux” and “initrd”, or “linux16” and “initrd16”. So, the easiest thing to do was create a custom Grub config to deal with booting none UEFI. In /etc/grub.d/40_custom I put:

menuentry 'Fedora (4.2.7-300.fc23.x86_64) 23 (SeaBIOS Mode)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.2.7-300.fc23.x86_64-advanced-a2c26bf5-3f1b-436f-8291-8ee94f8dc7b4' {
 set gfxpayload=keep
 insmod gzio
 insmod part_gpt
 insmod ext2
 set root='hd1,gpt2'
 if [ x$feature_platform_search_hint = xy ]; then
 search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2 --hint-efi=hd1,gpt2 --hint-baremetal=ahci1,gpt2 a2c26bf5-3f1b-436f-8291-8ee94f8dc7b4
 search --no-floppy --fs-uuid --set=root a2c26bf5-3f1b-436f-8291-8ee94f8dc7b4
 linux /boot/vmlinuz-4.2.7-300.fc23.x86_64 root=UUID=a2c26bf5-3f1b-436f-8291-8ee94f8dc7b4 ro rhgb quiet
 initrd /boot/initramfs-4.2.7-300.fc23.x86_64.img

Then run su -c “grub2-mkconfig > /boot/grub2/grub.cfg” and you will be able to boot Linux both under UEFI *and* Legacy BIOS.

Bear in mind, that if you upgrade the kernel while booted under Legacy BIOS, the prober/autoconfig will automatically change the primary menu options from linuxefi to linux16, so watch out for that.

Also, the usual disclaimers apply – you broke it you bought it, YMMV, etc, etc.