Why did the chicken crossystem the road?

Last weekend I established a mature procedure for deploying Chrome to my ASUS X200LA and my ThinkPad Yoga 11 20D9.  That procedure is stored on paper, at the moment.

I also learned last weekend the reason why I was unable mount any Chrome OS partitions. This is because of the RO setting on the ext4 filesystem.  I found a message thread about someone trying to modify the contents of an existing image, which greatly helped me.  I zeroed out the location with the disable_rw_mount flag, and this proved that the RO was the stumbling block. Using mount /dev/recoveryblockdevp3 /media/chromerecovery is not likely going to succeed in Fedora or Ubuntu.  Your first idiot test begins now (I already failed mine)...and all my frustration up to this point was easily solved by mounting read-only.  So let's say for a moment, the freshly downloaded recovery image is on /dev/sdb, then after making my mountpoint /tmp/sdb3, I can successfully mount /dev/sdb3 /tmp/sdb3 -o ro.

Being able to mount the recovery image and inventory the contents is particularly useful for helping me find out what /lib/firmware images and /lib/modules/`uname -r`/kernel/drivers/net ko's are shipped per a given recovery image.  I also found that it might be a good idea to traverse the image and see if tpm_managerd is required.  My Thinkpad 20D9 does not have a TPM 2.0, but a TPM 1.2.  I have to wonder if this is why snappy doesn't allow me to add my first Google account, but gets stuck in an endless loop.

Today I dived in to re-writing the VbGet and VbSet functions of lib/crossystem.c to consult /etc/os-release.d/* files of my design.  In this little side adventure, if /etc/os-release.d/hwid exists, then this derivation of crossystem (I created) will report the contents of that file.  If that file exists and the crossystem "sys_param_list" Param allows writing, then the file can be written to, thus storing the desired value.

The point of this exercise was to become more familiar with the keys and values that Chromebooks use; in particular finding out how to assign a FWID and HWID.  After successfully getting it compiled and working on Fedora 28, I copied it over to my ThinkPad running Chrome and it tested with flying colors (provided I mounted /etc/os-release.d as tmpfs).  However, I still couldn't get updates. Updates would have to be performed by dumping an image from a recovery image, until later.

Tonight, I made progress.  I was able to add a FWID and HWID and loaded the beta channel for GANDOF on my Thinkpad.  I then wiped it all out, installed 10462, primed the FWID and HWID, and the stable-channel update applied.  Here's the result with /dev/sda5 mounted to /tmp/sda5 (ro):

localhost / # grep -n DESCRIPTION /etc/lsb-release /tmp/sda5/etc/lsb-release/etc/lsb-release:14:CHROMEOS_RELEASE_DESCRIPTION=10452.99.0 (Official Build) stable-channel gandof/tmp/sda5/etc/lsb-release:14:CHROMEOS_RELEASE_DESCRIPTION=10718.88.2 (Official Build) stable-channel gandof

Although I haven't rebooted yet, seeing this is good news.  I will then run through my manual process for updating grub.cfg (/dev/sda12).

GANDOF works nicely on my ThinkPad Yoga 11e (20D9/20DA) with the exception the kernel apparently doesn't initialize the touchscreen.  The 4.4 kernel for the BayTrail hardware have a working touchscreen but are absent Play Store support.  EDIT/20180918 Testing with a fresh deploy of BANJO, the update from 10452 to 10718 also came with a new kernel but it only deployed to the ChromeOS kernel partition despite indicating it updated /dev/sda12.  After reading the Disk Format - The Chromium Project page, I gathered that an update or recovery image might not deliver a consistent vmlinuz and kernel partition.  This might kill my interest in going further.

TERRA is my current choice for my ASUS X200LA - keep in mind I swapped out the wireless card for an Intel AC7265 so I wouldn't have violate dm_verity or layer with tmpfs and override module_locking.

(Cr)atching up on Cr blog progess

Chrome Update
Chrome is still on my radar.  Installing Chrome isn't as easy as installing Chromium.

My current selfish dependency for my Cr-install project is establishing bootable media with the sole purpose of installing Chrome.  Other's scripts and procedures for installing Chrome are already easily found on the Internet, and my own augmentation of that procedure will not require much work.  Creating a purpose built environment for deploying Chrome is taking much longer than expected.

My current choice is minimal linux.  It has been a long time since I've compiled a kernel from source.  The minimal linux environment is nicely organized and allows for modular invocation of failed steps.  I thank the author.  It takes months of work to organize and test a project like minimal linux.

My "goto" operating system for a personal laptop is Fedora.  I began with the kernel from Fedora 28 (kernel-devel).  I renamed the directory and bundled it up to be minimal linux compatible.  I ran in to issues with inline assembly and the includes for SElinux.  Too much floundering steered me to download the source for the same kernel release from kernel.org and to preserve the .config from Fedora 28.  minimal linux was engineered with support for this scenario!  

Last weekend I made it to the point where the kernel now compiles without errors, but the generated ISO lacks the correct glibc (I believe) as busybox cannot launch.  

This Post's Tip for the Day
The way I made sure inline assembly was supported was to launch the build script with
CC_HAVE_ASM_GOTO /build_minimal_linux_live.sh

That is all for now.

You failed me for the last time! I hope.

Background
I ordered two Android HTC One M9's from dailysteals about a year ago (8/15/2017). Classified as pre-owned, I realized it was a crapshoot if they would arrive in the category of "slight blemishes."  I ordered one gold and one gunmetal.  Their purpose: sync my Skype (s4b), HipChat, Slack, JIRA, Confluence, Outlook both at work, and at home, without the need to carry a "work" phone.

They arrived nearly blemish free.  But the first thing I observed was the scuffing around the micro USB charge for the gold M9.  Who ever owned it before me must have tried to mate the connector at night, in total darkness, in order to miss that often.  Edit: I figured out why -> HTC M9 batteries deplete quickly when left on constant charge.  That scuffing was someone removing the adhesive an anti-theft anchor.  These were most likely in-store display models.

Both HTC's had dismal battery life from the time I received them; in fact much worse than I expected.  I think I squeezed around 2 hours of 2048 from one of them while in airplane mode.  I anticipated this being an issue, and for work, I left a magnetic Net2Dot charger cable at my desk.  That HTC, when paired with a Samsung R730T Gear S2, worked pretty well.  Notifications about chat and correspondence would pop up on my watch while I focused on tasks, without having nasty "floating" chat windows or Outlook pop-ups getting in the way.

The Repair Job
In June I ordered two replacement batteries, one for each.

In June I began a tear down of the HTC I kept at home.  That first weekend I floundered for half a day trying to determine why that case was such a challenge to open.  I've dissected HTC's before and even had to resolder the mini USB on my PPC-6700 on a vacation trip.  I've replaced the battery in an iPhone 4S and an iPhone 5. I wasn't prepared for what iFixit listed as a low Serviceability score of 2/10.  I gave up after mangling the LCD bezel.  I sought less frustrating activities to occupy my time.

In early July I regained interest, and searched for others' experiences disassembling the M9.  One fellow used a box knife to score around the perimeter and I found out why after successfully opening the rear aluminum case.  There were at least eight tabs -- see map -- that protrude in to the tab-sized cavities of the aluminum case.  The knife cuts loose the part of the tab that's "clinging for dear life" to the rear case.  This permanently damages the case's ability to provide a firm seal against the elements, but gives a chance to repair the insides.  I cleaned up the tabs a bit further so I could service the battery in the future.

Following iFixit's guide, I was given enough insight to release the vast quantity ZIF connectors, super tiny RF connectors, and the few small screws.  This guide was helpful. The new battery went in to place, taking care to "slide it under" the upper circuit card's annoying ribbon cable presence, but despite the battery's appearance of being a genuine article manufactured by HTC earlier in the year, the battery's metal header connector -- with screw holes to fasten securely in place -- didn't both line up.  A small bit of widening one screw hole in to an oblong shape made it wide enough for me to secure the second screw.  

Later in July, the HTC M9 which I kept at work, while being connected to the slow Net2Dot charger, completely lost power during a two hour Skype conference.  The drain from Skype was too much for the combination of a slow charger and a nearly "depleted" battery.  I attempted to revive it, but received a message that the battery was draining too much current when charging, and not long after that, the screen blipped off. 

The HTC I kept at home, barely had a week of burn-in time with the new battery, but I was committed to keeping my productivity strategy at the office. Keeping this objective meant slogging through a restore of my apps.  The restore, in short, was c omplicated by HTC's backup being unable to migrate anything more than contacts and media, Google's Android backup being unable recognize a backup made a few hours earlier, and a first-timer's acclamation to launching CWM's Helium -- helium being based on adb -- and the rigors of running that version of adb on Fedora 28*.  

I achieved my goal. This HTC was ready to replace the HTC at work. 

The next weekend I tested my seasoned approach on the HTC that was formerly at work.  It took about 3 hours from start to finish.  The map of tabs was useful and allowed me to use square tipped hobbyist knife blades to slowly keep an open perimeter around the tabs. I worked from top (IR port) to bottom.  On reassembly, I observed the top of one ZIF was damaged.  To my surprise it powered up.

Tips for Repair For anyone keen to replace an M9 battery, when one of the wider ZIF connectors resists full insertion, try taking a guitar pick shaped spudger - perhaps even a genuine guitar pick will work - and put it uniformly under the ZIF ribbon -- about 2mm from touching the motherboard ZIF connector.  Then press down on the ribbon so it lays (or mashes) flat against the guitar pick and gradually wiggle left and right to complete full insertion.

Remove as few of the RF connectors as possible.  The connectors were difficult for me to re-align.

When taking a break from the repair, when laying down the exposed LCD and circuit assembly, always lay it down LCD face down. The rear camera's rubberized grommet has a highly sticky adhesive that will stick to flat surfaces and materials like paper.  When it sticks, it can easily get mangled or distorted, thus reducing the ability for the rubber grommet to protect the camera from the elements.

Before starting this project I owned a generic rubberized M9 case.  I also ordered an OtterBox branded case.  I highly recommend the OtterBox case to help protect the phone from the effects of cracking it open for service.

The Result
It's been two weeks since the second was put back together, and I'm pleased with the results.  
  

ASUS X200LA runs terra (Chrome OS for the ASUS C202SA)

A few weeks ago I loaded an image of both terra and kip on to my ASUS X200LA.  Aside from a "behind the scenes" action requiring a keypress to boot, terra and kip boot nicely. I picked terra specifically under the hope that ASUS uses the media key mappings in their spins of Chrome OS.

terra has Google Play; which is one of my requirements to make a Chromebook useful. 

The X200LA has a 100Mb Realtek, which is okay for testing out builds for different Chromebook hardware. All of the editions I've staged (peppy, kip, terra, glimmer, squawks and ultima) have the r8169 driver, but for the Chromebook to be useful for anyone else, it must have working wireless.

terra has a tolerable function key map and since it has Google Play support working out of the box, I sought to figure out how I could roll in wireless without rebuilding the kernel.  I left kip on /dev/sda5 as I have no need to mess with it right now.

I postulated searching the big mass of recovery images for a build having the exact same kernel and the right wireless module, but it was easier to spend $22 on a mini PCIe Intel AC 7260.  This model corrects for the AR9485 lacking 5Ghz A and AC.  My residential district is oppressed with a "TroposNetworks" SSID and eats up three B/G channels, so 5Ghz is the only cost effective way.  The X200LA has a i3-4010u, and plenty of zip for a Chromebook.

About two years ago I replaced the 500GB laptop drive in the X200LA with a Crucial 128GB SSD, and I already had working knowledge of loosing the external screws and spudging the bottom case open.   Getting accessto the wireless card, once inside, was easy.  Replacing the wireless adapter only involved removing a single retention screw and carefully popping off the wifi/bluetooth antenna connectors.  Assembly is that same process, in reverse. 

I captured screenshots of the old adapter, new adapter installed, terra's lack of wireless with the AR9485 and also screenshots of a working wireless menu with the Intel 7260 and I plan on integrating them with this post, later.

Everything works except:

1. youtube video in Chrome
2. casting to my Miracast endpoints.  I'll use the Android YouTube app for now.
3. HDMI output (hasn't been tested)
4. XBOX One controller causes it to reboot (PS3 SixAxis works fine as /dev/js0)
5. G-sensor / accelerometer

This is the function key map:
F1 -> back
F2 -> forward
F3 -> refresh
F4 -> mlaptopzaximize
F5 -> app switcher
F6 -> dim LCD
F7 -> brighten LCD
F8 -> mute
F9 -> lower volume
F10 -> raise volume
F11 -> maximize
F12 -> F12

What to do with a Latitude 5175 2-in-1

This is a short post meant only to summarize my first adventure in deploying Chrome OS on a Latitude 5175 2-in-1.  The instructions are brief, and meant as a reminder of what I did to make it work, but why not share?


Hardware configuration of the Latitude 5175:

• 4GB RAM
• Intel m5-6Y57
• 128GB SATA SSD
• Venue 11 Travel keyboard (extended battery version)
• Intel Wireless AC-8260
• EFI enabled
• Secure boot disabled

The first build of Chrome OS I found that had similar enough hardware was the HP Chromebook x360 G1 EE.  The model or hwid prefix is SNAPPY. There may be a release with native support of the Intel AC 8260.  Let me know if you find one!

In the absence of native Intel AC 8260 support with an official Chrome OS recovery image, proceed with caution.

Searching Intel's support for Linux indicates that as of kernel 4.1.x, the AC 8260 is supported.  It appears that as of May 2018, several Chrome recovery images use a 3.8 or a 4.4 kernel.  A 4.4 kernel meets the requirement.  Although the SNAPPY image is pretty close, it fails to come with the 8260 firmware.  dmesg reveals that it is looking specifically for iwlwifi-8000C-31.ucode.  dmesg also has a standard message directing to download the correct firmware from git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git.  You can only imagine how thankful I was to have the next breadcrumb tossed in front of me!

I did my Chromium to Chrome OS preparation with an Ubuntu live distribution, with the prerequisite that I installed Chromium OS before Ubuntu.

I'm going to get the cart ahead of the horse for a moment and explain how I loaded the Ubuntu live distribution so that way when I reference it below, you'll know what I'm talking about. If you don't care about this "side trip," jump down to "To prepare your SSD".

I duplicated the Ubuntu 1.4GB data of the ISO as partition #14 of my internal drive and the EFI volume of the ISO as partition #15.  To repeat what I did with live media, install Chromium OS, create a 13th partition but don't take up the remaining disk space.  Plan for the 15th partition (Ubuntu EFI volume) to be at the very end of the disk.  Plan for the 14th partition (Ubuntu ISO data) to be just in front of the partition 15 Ubuntu EFI volume. Change partition 14 (Ubuntu ISO data) to type 11 (Microsoft data) and partition 15 (Ubuntu EFI volume) to type 1 (EFI).  Save your changes to the gpt. Then, say if /dev/sdb is the Ubuntu live media,

1. dd if=/dev/sdb1 of=/dev/sda14
2. dd if=/dev/sdb2 of=/dev/sda15.

With that established, you should now be able to use F12 during the Dell "POST" to select partition 15 for EFI boot.

As an overview, the gpt will then resemble this (using fdisk -l /dev/sda):
Disk /dev/sda: 119.2 GiB, 128035676160 bytes, 250069680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 478103D4-2A22-384F-88F8-1816B09D50F8

Device         Start       End  Sectors  Size Type
/dev/sda1    8704000  17092607  8388608    4G Microsoft basic data
/dev/sda2      20480     53247    32768   16M ChromeOS kernel
/dev/sda3    4509696   8703999  4194304    2G ChromeOS root fs
/dev/sda4      53248     86015    32768   16M ChromeOS kernel
/dev/sda5     315392   4509695  4194304    2G ChromeOS root fs
/dev/sda6      16448     16448        1  512B ChromeOS kernel
/dev/sda7      16449     16449        1  512B ChromeOS root fs
/dev/sda8      86016    118783    32768   16M Microsoft basic data
/dev/sda9      16450     16450        1  512B ChromeOS reserved
/dev/sda10     16451     16451        1  512B ChromeOS reserved
/dev/sda11        64     16447    16384    8M unknown
/dev/sda12    249856    315391    65536   32M EFI System
/dev/sda13  17092608  62533261 45440654 21.7G Linux filesystem
/dev/sda14 247133196 250065036  2931841  1.4G Microsoft basic data
/dev/sda15 250065038 250069646     4609  2.3M EFI System
Partition table entries are not in disk order.

To prepare your SSD:
# Get the firmware with a computer that has git
Step 1: git clone git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
Step 2: from the linux-firmware directory, isolate iwlwifi-8000C-31.ucode and copy it to a temporary directory.
# Focus on your 5175
Step 3: install Arnold The Bat's Chromium OS to your 5175.  This means any operating system on the 5175 gets completely wiped out and I assume you will be dumping the Chromium OS image over the top of your 5175 internal disk.
Step 4: Now installed, boot in to Chromium on your 5175 (or use Ubuntu live media if you're applying the update manually).
Step 5: Locate the directions on reddit's Update Chromium OS to official Chrome OS
Step 5a OPTION 1) and note that the reddit article specifically has the current recovery.conf URL shortened to http://goo.gl/8v1ZkV in it.  Follow this article unless you're doing it manually.
Step 5b OPTION 1) Select the image for the HP Chromebook x360 G1 EE and follow through with the documented procedure on that page. Skip over the rest of the 5a/b/c/d/e steps and continue at step 6.
Step 5a OPTION 2)  or you can search and grab recovery.conf and grep/vi/less whatever yourself.
Step 5b OPTION 2) wget or curl the SNAPPY image, unzip it, or zcat to a flash drive.
Step 5c OPTION 2) and dump the image's/flash drive's 3rd gpt partition over the top of your internal disk's 3rd gpt  partition
Step 5d OPTION 2) and then copy the [image-part12]/syslinux/vmlinuz.A from the image's 12th partition to your internal disk's 12th gpt (EFI ) partition [sda12]/syslinux/vmlinuz.A.
Step 5e OPTION 2) if it doesn't boot Chrome OS in a matter of seconds, use blkid to identify the UUID of /dev/sda3 and edit /efi/boot/grub.cfg on the EFI partition /dev/sda12 to use that UUID of /dev/sda3.  I elected to mimic the same UUID format I found in grub.cfg by stripping the quotes and capitalizing the UUID in grub.cfg.
Step 6: Add a 13th partition and format, say using ext3 which then becomes /dev/sda13.  If you want to park Ubuntu at the end, keep about 2GB at the end of the disk free for partitions 14 and 15.
Step 7: mkdir /tmp/sda13 and mount /dev/sda13 to /tmp/sda13.
Step 8. copy the firmware images from step 2 to /tmp/sda13.
Step 9. add this script named activate8260.sh to /tmp/sda13

!/bin/sh

WORKDIR=`pwd`
cd /lib/firmware
find | cpio -ov -H crc > /tmp/lib-firmware.cpio
cd /lib
mount tmpfs -t tmpfs /lib/firmware
cd /lib/firmware
cat /tmp/lib-firmware.cpio | cpio -idv 2> /dev/null
cp ${WORKDIR}/iwlwifi*.ucode /lib/firmware
echo 0 > /proc/sys/kernel/chromiumos/module_locking
rmmod iwlmvm
rmmod iwlwifi
modprobe iwlwifi
echo 1 > /proc/sys/kernel/chromiumos/module_locking
touch /tmp/lib-firmware.cpio.unpacked
clear
sleep 2
ifconfig -a
ifconfig -a | grep -q ^wlan0 && echo "ifconfig says wlan0 is loaded."
ifconfig -a | grep -q ^wlan0 || echo "ifconfig does not show wlan0. Check firmware load with dmesg."

Step 10. chmod +x /tmp/sda13/activate8260.sh

Please note that every time you reboot you will have to activate it.  As of writing this I barely spent an evening on this plight.

With the script, you should now be able to manually activate on next boot.  Since deploying over Chromium OS likely means developer mode is on, the CTRL-ALT-F2 console is probably available after Chrome OS boots. If it isn't, you can try adding cros_debug to your grub command line at the next boot.

To activate:
1. CTRL-ALT-F1 and logon as chronos
2. sudo su
3. mkdir /tmp/sda13; mount /dev/sda13 /tmp/sda13
4. cd /tmp/sda13
5. ./activate8260.sh
5a) The script should report if the wlan0 ethernet adapter is successfully found.
6. cd /tmp
7. umount /dev/sda13
8. CTRL-D (to exit su)
9. CTRL-D (to exit chronos shell)
10. CTRL-ALT-F1 to return to Chrome OS.

Wireless should now be live!  Take this foundation and run with it.

In the future I plan on sharing a script that'll deploy Ubuntu Live to the end of the disk.  But that'll depend on if there's already a good write up or existing tool.

I used my actual first successful deployment to add this blog entry.  Immediately, it appears
there is no functional volume up shortcut key along the traditional function key bar.
when closing the lid and effectively putting it to sleep, it can be quite difficult to resume as the power button didn't wake it up and neither did opening the lid.
The battery state never changes from 100% and calculating.

I can confirm that these are working:

• touchscreen input
• stylus intput
• keyboard and touchpad
• Google Play store

I can confirm that this/these are not working:

• bluetooth
• sound

My first Apple excursion

KansasFest Experience (2017)

Four kinds of people:

• Facilitators
• Software engineers
• Hardware engineers
• Collectors

Conference Elements:

• Sessions: "endless wow."  The presenters were all prepared and skilled.
• Giveaway: I picked with wrong mode of travel.  I need //e's, but had no space to take them with me.  Donate to the team that brings in the Garage Giveaway haul; they deserve it!
• Social Experience: Steve W, Peter N, Carl, and Martin are amazing.  Collectors have neat stories and are excited to share. Olivier, Olivier, Antoine, and Alain took time to socialize and share. John and Peter were two among the Americans who opened up.  I appreciated his hospitality. All of the other, regular engineers circulate in tight groups in effort to crank out research and results in the brief week they all have together.  
• Lunches: decent grub, and is just about the only time to get to know more about regular attendees.
• Facility: in need of modernization, and the main area is too small for a confluence of 100 attendees.  Wireless internet access is troublesome.  
• Location: hot, humid climate, and volatile weather.
• Competition: proficient software engineers have an edge.  
• Vendors: a mix of everything; hardware, software, relics, and modern, themed trinkets.

I thought I might become friends with hobbyists interested in talking about copy protection schemes on the Apple II.  I thought I would encounter more appreciation for emulators. I expected an opportunity to share memories.  Not even close.

The ticket to making friends is bringing your own classic Apple.  Failure to bring your own classic Apple almost certainly means failed first impressions.  Perhaps a photo wallet of loved II's would overcome the offense. Stories and experience lacking current context have no place at this conference.  KansasFest folks march forward and few look back.  New attendees, including myself, seemed to be floundering to make connections, sitting in the general communal half-occupied by a team of extremely focused software preservationists.  When the preservationists were off somewhere, there was ample seating to make new friends.

Twitter is their anchor for communication.

I left confused and sad. 

For context, in 1993, I posted a comp.sys.apple2 article named "Copy protection of most 86-90 II programs" on how to defeat a highly used bit slip protection in software products I saw as youngster.  I was a freshman in college when writing this and I lacked thoroughness, effective communication skills, and knowledge of technical writing.  That said, the post was technical and useful to a limited audience.  At KansasFest 2017, I met a highly skilled software preservationist who, the year prior, had presented a topic nearly identical to what I had posted long ago.  The diagrams in that presentation were remarkably similar to what I posted. Curious to earn some conversation time with him, I inquired of him if he had ever seen what I posted, he blurted "oh you're Michael Kelsey".   He didn't have time beyond that.

EDIT 10/19: I later figured out why.  This chap was cool enough to sponsor several folks' attendance to KansasFest.  I had entered to contest, but I didn't win any of them.  I would guess that a first impression had been made long before I arrived to Rockhurst. 

On the final day of KansasFest 2017, I gave feedback to a kind soul who helps organize KansasFest.  I suggested that an interests questionnaire be given before the event for new attendees, that during the registration process, could help make all the difference incorporating new attendees in to the circles of activity.  The event goes quickly and precious time can be lost.

I continue to wonder what happened that week of my life.  If I consider going again, how should I prepare?  Will a future KansasFest be different?

Why Akuma?

Why Akuma for my twitter avatar?

For reasons I cannot explain, I get satisfaction out of dropping the final blow to Akuma as deep within the princess' chambers as possible.  Depending on the day, I may or may not let my body join Akuma's on the floor.  That feeling of satisfaction, is the same feeling as when tagging all four repeller cores when saving the Airheart prince.  Maybe I'll choose Airheart's flaming sword next time.  For now, it's Akuma.

When my work center adopted a new wiki, people began assigning personalized avatars.  My supervisor, at the time; she adopted a cute picture of a cartoon tabby cat.  Not just a cat-person, she was a clowder-person.

I felt I should say something about myself through my choice avatar, and I opted to express my enjoyment of Apple //'s -- via the avatar, which has the signature color palette and pixel geometry -- but also a game which I found to capture the very best of the early analog joystick gaming experience.

Thanks Jordan!


@michaela2kelsey

Thinking about my ThinkPad Yoga 11e and updating to Fedora 28

I own a ThinkPad Yoga 11e (Gen3).

The biggest motivation for selecting this ThinkPad was strong community support for my X41t.  The X41t had a tremendous following but it appears the 11e is not as fortunate.

Fedora 24 provided wonderful hardware support for that ThinkPad x41t and also the later x230t.  This changed after Fedora 24.  What changed, most notably is, when issuing a shut down to the system, it will nearly complete the power off sequence, but instead shutting down provokes a beep code suggesting bad memory. Second, the touchpad doesn't work.

My short term work around is to leverage the Fedora 24 kernel since with that kernel, the touchpad and shutdown will work.  In my experience, the release 24 kernel works with Fedora 26, 27, and 28.  The long term solution will be to see if anything changed in the kernel source or kernel configuration.

The odds are good that if you have used dnf to system-upgrade, you no longer have the version 24 kernels.  My system-upgrades have always done a good job of cleaning up old kernels.  As of writing this, I extracted the 4.5.5-300 kernel from the installer ISO and rebuilt the initramfs.  As of finishing this write-up, I located an archive mirror fedora-updates for release 24 providing me with 4.11.12-100.fc24.x86_64 and put together the steps.

Overview of the steps

1. locate the Fedora 24 kernel and the kernel modules. 
2. install the RPMs or extract them (an exercise left for the reader)
3. run grub2-mkconfig

The steps
# Get the RPMs
wget https://mirrors.rit.edu/fedora/archive/fedora/linux/updates/24/x86_64/k/kernel-4.11.12-100.fc24.x86_64.rpm
wget https://mirrors.rit.edu/fedora/archive/fedora/linux/updates/24/x86_64/k/kernel-core-4.11.12-100.fc24.x86_64.rpm
wget https://mirrors.rit.edu/fedora/archive/fedora/linux/updates/24/x86_64/k/kernel-modules-4.11.12-100.fc24.x86_64.rpm
wget https://mirrors.rit.edu/fedora/archive/fedora/linux/updates/24/x86_64/k/kernel-modules-extra-4.11.12-100.fc24.x86_64.rpm
# Probably should use dnf localinstall syntax instead...too late.
rpm -ivh --force kernel-core-4.11.12-100.fc24.x86_64.rpm
rpm -ivh --force kernel-4.11.12-100.fc24.x86_64.rpm
rpm -ivh --force kernel-modules-4.11.12-100.fc24.x86_64.rpm
rpm -ivh --force kernel-modules-extra-4.11.12-100.fc24.x86_64.rpm

# EFI is well supported on this ThinkPad
# Best to uncomment the next line.
# cp /boot/efi/EFI/fedora/grub.cfg /boot/efi/EFI/fedora/grub.cfg-backup
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
reboot
# and see if it works for you!

# But if you need to regenerate the initramfs manually, this is what I used with the 4.5.5 kernel.
dracut -fv /boot/initramfs-4.5.5-300.fc24.x86_64.img 4.5.5-300.fc24.x86_64
reboot and test

The data
# And this is the list of mirrors, from which I used the first two to successfully obtain all four RPMs.

# repo = updates-released-f24 arch = x86_64 country = US 
https://mirrors.rit.edu/fedora/archive/fedora/linux/updates/24/x86_64/
http://mirror.math.princeton.edu/pub/fedora-archive/fedora/linux/updates/24/x86_64/
https://pubmirror2.math.uh.edu/fedora-buffet/archive/fedora/linux/updates/24/x86_64/
http://mirrors.kernel.org/fedora-buffet/archive/fedora/linux/updates/24/x86_64/
https://pubmirror1.math.uh.edu/fedora-buffet/archive/fedora/linux/updates/24/x86_64/
https://dl.fedoraproject.org/pub/archive/fedora/linux/updates/24/x86_64/

About the ThinkPad Yoga 11e (Gen 3)
It is a very durable design.  The keyboard is great but is absent the Application menu key. The battery life could be better but the underclocking ability of the N2940 can help extend the battery considerably, even if a bit pokey.  For me, the touchpad is miserable.  I am a person who drags his palm in close proximity to the touchpad, requiring a lot more undos.  To edit settings in NetworkManager, I need the right-click or Application menu function. The touchscreen is not a Wacom edition with a two-finger tap, but the X230t Wacom touchscreen supports two-finger tap. I realize alternatively, I could shell out and type nm-connection-editor but Windows XP tablet edition conditioned me differently. Instead tap the icon, right-click the touchpad, right-click touchpad.  Then I disable the touchpad until needed next.  I have customized my Fedora installation so my desired startup settings, including the enablement of the touchpad, persist.  I used to the same customization to keep my XFCE profile clean, which trickles down to a fresh clean browser history and bookmarks every time.

Questions and feedback?
Reach me on Twitter @michaela2kelsey