posts

When an old tablet is no longer up to the task for which it was originally designed, binning the thing seems a shame, but there is no guarantee that selling it is worthwhile. A recent ebay search suggests that a Fire 7 tablet with 8GB storage could be worth as little as £2 or as much as £26 (if it’s in decent condition, and comes with a child-friendly case). £26 is not to be sniffed at - if nothing else, and assuming you have bought into the Amazon ecosystem, that gets you pretty close to an Echo, or a Fire Stick. On the other hand, £2 is a pretty miserly return to be after for the effort of listing the item, dealing with questions, and posting it - assuming it sells at all.

I had a go at flashing my Kindle Fire 7 (7th Generation) tablet and then installing LineageOS. The aim was:

a. Learn how to replace the Fire OS with a more generic flavour of Android; b. Put together a tablet that I might be able to use as a hobby device for random bits and pieces - or even as a first “true Android” tablet for the kids; c. Maybe even figure out how the tablet could be repurposed as a smart screen in the home; showing weather, news, or even a looped video of a cat dressed as a shark chasing a duck around on a roomba. Because, well, why not?

There are loads of guides online; the hardest part in all of this is working out which instructions are relevant to you. So if you aim to follow this guide, you’ll need:

1. An Amazon Fire 7 Tablet (7th Generation). You can look at the device specifications website to work out what you have. If your Fire tablet has not been reset (i.e. you can still sign in to it), then you can also determine your hardware version by going to Settings > Device Settings > Device Model;
2. A micro-USB cable
3. Some means of opening the case of the tablet. If you have teh muscles, then you can try and pry the case apart by force. Otherwise, a plastic opening tool works well. You can use a small-sized slotted screwdriver, but you are liable to damage the case of your tablet, because in any battle of metal versus plastic (especially the plastic on a cheap tablet), the metal is likely to win;
4. A length of wire, with bare ends; each end should have about 1cm of exposed wiring; a paperclip works well here.
5. A small Phillips Head screwdriver (you’ll need this to disconnect the Fire battery);
6. A computer running linux. I’m using Linux Mint;

Step 1: Download the binaries you’ll need onto your linux box

You need some components installed:

sudo apt update
sudo add-apt-repository universe
sudo apt install python3 python3-serial adb fastboot

You need to disable the Modem Manager:

sudo systemctl stop ModemManager
sudo systemctl disable ModemManager

You’ll need the amonet-austin binaries, which have been helpfully put on a zip file here. You also want to download GApp binaries from here. I chose the arm 5.1 nano installation. Arm 5.1 is non-negotiable, and is required given the version of tablet I was installing on. The nano installation is much smaller than the stock one, and I wanted to install everything from the Fire Tablet’s internal storage rather than relying on a microSD card (two cards have failed in my Fire Tablet in the past two years).

Finally, you need a lineageOS zip. I got mine here.

1. Unzip the amonet-austin zipfile - we’ll open a bash terminal in here to do the work. The other zips (for lineageOS and GApp) can be left as zips.

Step 2: Prepare the Kindle

1. Reset the device, and unregister it from Amazon;
2. Switch it off, and remove the back cover. This works best if you start at the bottom end (the end opposite the camera), and work your way up.
3. Disconnect the battery. This involves unscrewing the two small screws that secure the connector to the main board, and then popping the cable off. You don’t need to use a lot of force; once the screws are out, the cable should just “pop” free with some gentle encouragement.
4. Work out where the VDD connector is. This is the fiddliest part of the operation: you need to short one pin on the Fire PCB to allow the tablet to be flashed. This picture is a good guide. The picture shows two options, VDD1 and CMD. I’ve not had a lot of luck with the CMD connector, so I tend to stick to the VDD one.
5. Push the wire under the shielding in order to contact the VDD connector, and ground it out. You can do this by connecting the other end of the wire to the shield.

Step 3: Let the fun begin

From a terminal on your linux box, navigate into the folder into which you unzipped the amonet austin file.

(base) x@x:~/work/fire_brick/amonet_austin$ sudo ./bootrom-step.sh 
[sudo] password for x:           
[2022-02-28 11:12:52.079500] Waiting for bootrom

At this point, connect the tablet to the linux box using a microUSB cable. If all goes to plan, you should see some nice stuff being displayed. If, however, you see this:

(base) x@x:~/work/fire_brick/amonet_austin$ sudo ./bootrom-step.sh 
[2022-02-28 11:18:08.283713] Waiting for bootrom
[2022-02-28 11:18:23.919498] Found port = /dev/ttyACM0
[2022-02-28 11:18:23.958787] Handshake
[2022-02-28 11:18:23.979722] Disable watchdog
Traceback (most recent call last):
  File "main.py", line 156, in <module>
    main()
  File "main.py", line 75, in main
    handshake(dev)
  File "/home/x/work/fire_brick/amonet_austin/modules/handshake.py", line 11, in handshake
    dev.write32(0x10007000, 0x22000000)
  File "/home/x/work/fire_brick/amonet_austin/modules/common.py", line 160, in write32
    self.check(self.dev.read(2), b'\x00\x01') # arg check

  File "/home/x/work/fire_brick/amonet_austin/modules/common.py", line 87, in check
    raise RuntimeError("ERROR: Serial protocol mismatch")
RuntimeError: ERROR: Serial protocol mismatch

the most likely issue is that your wire short between VDD and the shielding was not quite on point. You may need to disconnect the USB cable, adjust the wire, and try again.

If it works, the terminal will ask you to remove the shorting wire. At this point, toss the wire - you won’t need it again - and hit Enter. The Fire tablet will reboot into an unlocked fastboot state. You can now run the fastboot step from your linux box.

sudo ./fastboot-step.sh

The tablet will reboot into TWRP.

Step 4: Transfer and install LineageOS and GApp

1. Mount the tablet’s storage device for data transfer.
2. From the linux box, use adb push to transfer the lineageOS and GApp zip files to the tablet;
3. Unmount the tablet as a storage device, and then use TWRP to install lineageOS and GApp.

The result should be a shiny lineageOS tablet.

WordPress is one of the most popular platforms for developing sites; by their own estimate, “over 43% of the web runs on WordPress”. It is massively configurable with a huge array of plugins to cover all sorts of features, from backups through to web commerce. It has a low barrier to entry, and tries hard to stay out of your way as much as possible so as to appeal to content creators who have very little technical expertise.

The flipside of this particular coin is that a free, massively popular, hugely configurable platform leads to an exponential amount of content about how best to support it, and a lot of the advice is irrelevant, inappropriate, or at worst utterly dangerous. Consider the following questions that I’m currently trying to answer, faced with a WordPress site that needs some updates, armed with nothing more than a login to the admin console (wp_admin) and one to the hosting provider:

• How do I take a copy of the site so I can roll it back if necessary?
• Does WordPress work well with source control? Can I store the relevant bits (see previous question) in a github repository?
• What about the data? What do I need from the MySQL installation? All databases? What about users?
• How do I run a WordPress site locally?
• If I make changes to my local site, how do I then get those changes into the production site? Is there a publish mechanism?
• What about changes to the data? How do I deal with a development MySQL database which is different from the production one?

This post charts my five day journey to answer some of these questions. I start as a WordPress noob and end a WordPress noob, albeit one who managed to make a bit more sense of how to develop with WordPress (in a way that worked for me).

So what makes this tick?

It seems like the bare minimum you need to run a WordPress site locally is a suitable LAMP stack (Linux, Apache, MySQL and PHP), so this seems like a good place to start. Installing these amounts to four incantations:

sudo apt-get install apache2
sudo apt-get install php5 libapache2-mod-php5
sudo apt-get install mysql-server
sudo apt-get install libapache2-mod-auth-mysql php5-mysql phpmyadmin

You can test these installations in various ways.

1. Open a browser and navigate to http://localhost/ to verify your apache installation;
2. Create a file called index.php in a location from which apache will serve it (usually something like /var/www) and edit the file so it contains <?php phpinfo(); ?>. If you navigate to that page via a browser, you should see details on the PHP installation;
3. From a terminal, log in to sql using the username and password configured during installation - so something like mysql -u root -p;
4. For phpMyAdmin you should be able to navigate to http://localhost/phpmyadmin. The login details will be for the root user that you set up when configuring MySQL above;

For subsequent SQL operations, you can use the MySQL console available via phpMyAdmin.

Set up users

Using the root user everywhere is asking for all kinds of trouble, so you should configure a dedicated user for your WordPress site. To do this, let us first create a database in which the WordPress tables will live. Via phpMyAdmin this is as simple as selecting New from the left-hand database tree, and in the resulting panel, giving the database a name and choosing a collation strategy. (Gotcha Number One: the user that you entered to log in to phpMyAdmin needs to have the right permissions to create databases. If it doesn’t you’ll quickly find that there is no option to create a new database, and this caused me a fair bit of headscratching.)

Collation may be important, so don’t just select some random one. When choosing mine, I decided to look at the collation settings for the production database I was hoping to clone, so as to ensure they matched.

Having a database, I next created a user and granted that user full perms over the database. This might be overkill, but given the whole thing was local, I wasn’t hugely paranoid about it. From the phpMyAdmin home, the Users tab includes the option to create a new user; during creation you can choose what set of permissions to give it - including the option to limit access to the database you create in the previous step.

Fill the database

I needed to ensure the content of the database matched that of the production site. MySQL provides a dump feature that can be used to emit the contents of a database to a file which can then be imported into another.

I used the production server’s phpMyAdmin to generate the dump of the relevant database, electing to save out a zipped result. This is then downloaded to your local machine. From the local machine’s phpMyAdmin, select the correct database and choose the Import option - this option allows you to import directly from a zipped dump.

Gotcha Number Two: The php server that powers the admin console is configured with a relatively low limit on the size of file it will allow to be uploaded. If your dump is large, then importing it is likely to fail unless this limit is addressed. For reference, in my case the default upload limit was 2MB, and the dumpfile I was trying to upload was 3.3MB. You can change this limit by updating the upload_max_filesize and post_max_size properties of the php.ini file that was created during the installation phase. If you are not sure where this file is located, you can look through the phpinfo output to find it. Don’t forget you’ll need to restart apache to pick this change up.

The upload took a few minutes to complete, but a clean status page at the end suggested it had all gone okay. Sure enough, in the database I had created, I could now see all sorts of WordPress tables, names starting with the tell-tale wp_as happens by default.

Get a copy of the website files

This was a royal PITA. Depending on your hosting provider, you may have SFTP or SSH access to your host, allowing you to navigate and fetch the relevant files. In my case, I had to use some crappy web-based file navigation and download mechanism.

Aside: What files? Depending on where you look, the set of files you need to take a copy of varies from a handful (some references suggest the wp-content folder is enough, but I think you need the contents of the root folder down. As a rule of thumb, look for the wp-config.php file and assume that its containing folder is the one that is required (and all subfolders).

Once you have downloaded a copy of the content, you need to make some changes to make sure things work.

Final Tweaks

1. Edit the wp-config.php file - this is in the root of the local copy of your website - to update the connection details for the SQL server. You are now connecting to the new database you created, on your local host, and using the username and password you set up for the purpose.
2. A few changes are required to the database content that you imported. These changes update values that tell WordPress where the site is located. The SQL should be relatively self-explanatory:

UPDATE wp_options SET option_value = replace(option_value, 'https://www.example.com', 'http://localhost/mylocalsite') WHERE option_name = 'home' OR option_name = 'siteurl';
UPDATE wp_posts SET post_content = replace(post_content, 'https://www.example.com', 'http://localhost/mylocalsite');
UPDATE wp_postmeta SET meta_value = replace(meta_value,'https://www.example.com','http://localhost/mylocalsite');

A note about mod_rewrite

You might need to add a rewrite rule so that your local installation handles permalinks properly. WordPress provides nice links to pages that are suited for SEO (So pages have RESTful URLs like http://foo.bar/category/fish rather than http://foo.bar/post.php?id=7). In order for them to work, your Apache installation needs to have mod_rewrite installed and enabled, and you need to provide a rewrite rule that can be used to translate these links into the correct content.

On my Apache installation mod_rewrite was disabled by default. Enabling it is as simple as:

sudo a2enmod rewrite

The rewrite rule required for WordPress permalinks looks like this (this can be put in a file called .htaccess that sits alongside the rest of the site):

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /foo/
  RewriteRule ^index\.php$ - [L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /foo/index.php [L]
</IfModule>

You should also ensure that the apache directory configuration for your website allows overrides - otherwise the .htaccess file you painstakingly created above will be ignored. For example:

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
</Directory>

Don’t forget to restart apache to pick these changes up.

Success?

At this point, you should find that navigating to the relevant address in your browser brings up a fully functioning copy of your website, but one which is now hosted locally.