As Pa Bailey might have put it, it’s deep in the race to want to run GNOME on your tablet. At last year’s Libre Graphics Meeting in Toronto, pippin displayed GNOME on his Lenovo MIIX 3 Bay Trail device. A few months later I was able to pick up an ASUS T100TA with similar specs (if not as elegant) for a good discount. Adam Williamson’s latest Fedlet release was days old at the time, and I installed it.
I’ve been through the Fedlet installation three times, the second and third installs necessitated by some newfound inherent skill at rendering the device unusable. The installation is nerve-wracking on account of some missing or invisible buttons in Anaconda, so I’d rather upgrade than re-install. The processor supports 64-bit Linux with 32-bit UEFI, but at this point I’m happy with the 32-bit kernel. (The experience of local LUG members suggests the Debian multiarch installer will address the 32-bit UEFI while installing a 64-bit system, but a brand new Ubuntu installer will not.)
There’s a Google+ Community dedicated to running Ubuntu on the different varieties of T100. After some weeks of reading about further advances specific to the hardware, I wasn’t satisfied with the Fedlet 4.2 kernel and decided to build a newer one. For ease of installation and removal, Fedora kernel packages are worth the small effort required beyond simply compiling a kernel. The procedure on the wiki page is pretty comprehensive; below are the changes I needed to get mine working. First some notes:
- ‘dnf upgrade’ on the newly-installed Fedlet led directly to the first from-scratch re-install. Since then I’ve installed specific required packages with dnf using ‘–best –allowerasing’. I’m still running Fedora 23 to prevent the loss of any of the customized packages (other than the kernel) from the Fedlet repo, but hopefully it will become possible (if it’s not already) to do without them. I would experiment, but at this point it’s easier to just avoid the risk.
- the last re-install was required after I built a kernel that was capable of eating the contents of the eMMC hard drive.
- sometime between 4.2 and 4.6, a dracut upgrade was required to enable the kernel installation to complete.
- the 60 GB hard drive needs a hefty percentage of free space to perform the build: I usually delete the contents of BUILD and BUILDROOT from the previous build, and keep my music on the removable SD card.
Asus T100 Ubuntu: progress reports, patches and config file, sound configuration (sound works with kernels older than 4.6-rc* but so far 4.6 breaks it). The About this community panel has a Google Drive link called Asus Files with all the good stuff.
These are the sections I follow from Building a custom kernel. Please consult the original page for the details.
Dependencies for building kernels
Building a kernel from the source RPM: Get the Source
I grab the kernel source package from Koji that corresponds to the patches in the Google Drive folder.
Prepare the Kernel Source Tree
rpmbuild -bp --target=$(uname -m) kernel.spec
Use ‘target=i686’ if building on my x86_64 laptop (hypothetical at this point since I haven’t successfully done this).
Copy the Source Tree and Generate a Patch
Skip this section: at this point I apply the patches (from the Google+ page) directly to the linux-* folder. I’ve performed the operation of copying the tree to create a single patch, but haven’t been successful automating it with ApplyPatch in the .spec file.
Configure kernel options
Copy in the config file acquired from the Google+ page.
Step 5 is i686.
Prepare Build Files
Customize the buildid in the .spec file (.mdh in my case).
Build the New Kernel
Use ‘noprep’ to prevent refreshing the source tree and re-applying the Fedora patches.
rpmbuild -bb --noprep --with baseonly --without debuginfo --target=`uname -m` kernel.spec
Use ‘target=i686’ if (someday) building on my x86_64 laptop.
On occasion at this point I need to rename the ~/rpmbuild/BUILD/kernel-*/linux-* folder to include the buildid and fc23 instead of the version from the source rpm (currently fc25).
I usually do the last step with the power connected, but occasionally carry it to the car and back for the trip to work, so as not to interrupt the build. If it finishes, a full set of packages should appear in ~/rpmbuild/RPMS/i686.
Corrections and recommendations welcome.