I don't ENVY you, or maybe I do?

This post is about HP's AMD-based Envy x360 (2019) and the upgrade threshold of RAM and SATA 2.5" SSD.

In January (2020) a family member asked me for advice on a new laptop that would consolidate all of the old tower PC and laptop data.  Advice from another family member, sought out before me, was to find a dual drive HP with 32GB of RAM and a 2TB drive.  To me, that sounded like a $2,000 investment.

I fielded back my recommendation of buying from a hassle-free provider, "try before you buy," and choose a newer 9th or 10th generation Intel-based system.  A mainstream computer outlet was suggested, and I countered with Costco and then Amazon.  An older lady with whom I was working brought her personal Alienware laptop because the store sales person had recommended she get a gaming laptop.  Seeing it first hand, it was more laptop than she needed, by a long shot.  As for my family member, when the nearest city with those kinds of stores is 60 miles away, you benefit from knowing what you want before going in the store.

Over several days we volleyed makes and models  between us until I finally saw an opportunity.  Woot had some refurbished HP's.  I have had good experience with HP's refurbished products. In the assortment was an Envy x360 with a 256 GB m.2 and an AMD Ryzen 2500U (Passmark of 6,824 where my i7-7700HQ gets 6,985).   Research indicated it could be upgraded with more than 8 GB of RAM and a secondary SATA disk.  It can, but not out of the box.  You must buy the drive caddy.

I spent $449 on the laptop. Another $229.99 on a 1.92 TB SATA SSD. Another $16.88 on the caddy.  Once all the parts arrived I tracked down a How To.  I was not successful finding a How To video for the 15-cp0053cl, but I located the service manual.

The service manual shows how to remove and replace memory and how to remove and replace the M.2 SSD, but it did not show clearly where the memory or M.2 are located. Based on an exploded illustrated parts diagram, the memory and M.2 should be on the underside of the motherboard.  I located a metallic shield on the underside that was slightly larger than the area summation of the both. I delicately pried from under one corner of the shield, and to my surprise it popped up quite easily.  I moved around under the shield perimeter leaving the black tape as a sort of "hinge."  I hinged it back and found both the memory and the M.2.

The service manual says the largest SATA disk is 1 TB.  The 2 TB SATA SSD is fully recognized.  The service manual says the largest RAM is 12 GB.  It supports my combination of 16 GB PC4-19200 and 8 GB PC4-19200 for a total of 24 GB PC4-19200.  Having written this original post on March 22, 2020, I came back a month later to comment on a final RAM configuration.  I found a forum where one person upgraded their ENVY with two 16 GB PC4-19200 (BLS16G4S240FSD).  I ordered a Crucial PC4-21333 (2666) 16 GB (2R) module to match the SK HYNIX 8 GB PC4-21333 (2666V) HP supplied, and it did not work in either slot.  It also did not function correctly in a Dell Precision 3520 where the part is listed as supported.  Instead of dealing with a RMA, I opted to work with Crucial support, who convinced me the RMA refund was a better no-cost option.  Performing a RMA through Crucial meant I would have to pay return shipping.  I sent that bad stick back to the seller (via Amazon) and chose to order OWC PC-21333 16 GB modules in a 32 GB (2x module) kit.  The modules came in a few days. I tested the modules in the ENVY and all I found was a blinking power light and a CAPS light blinking an error code.  The PC4-21333 is, however, supported in the Dell Precision 3520 and I am pleased to report it is working quite well.  The ENVY now has the 24 GB of SK HYNIX PC4-19200 RAM formerly serving the Dell Precision.  Although this is not ideal, it will suffice.

I hope others find this useful.

http://h10032.www1.hp.com/ctg/Manual/c06001791

Supports DDR4 1.2-V 2666 and 2400 memory in the following conƭgurations ● 16-GB (8-GB × 2) ● 12-GB (8-GB + 4-GB) ● 8-GB (8-GB × 1 or 4-GB × 2) Storage Support for a 1-TB, 7200-rpm, SATA 7.0-mm hard drive Support for the following solid-state drives: ● 256-GB, M.2 2280, peripheral component interconnect express (PCIe)3×4, non-volatile memory express (NVMe), SuperSpeed (SS) solid-state drive with triple-level cell (TLC) ● 256-GB, 2280, PCIe, NVMe solid-state drive with TLC ● 128-GB, M.2 2280, SATA-3 solid-state drive with TLC Supports the following hard drive and solid-state drive combinations: 1-TB, 7200-rpm, SATA 7.0-mm hard drive + 256-GB, 2280, PCIe, NVMe solid-state drive with TLC 1-TB, 7200-rpm, SATA 7.0-mm hard drive + 128-GB, M.2 2280-SATA3 solid-state drive with TLC

The parts sourced as follows:

• Amazon (by word of TechBargains) had the Micron 5100 MAX 2 TB for $229.99 (March 2020)
• Amazon had the PartEgg caddy for $16.88. It listed as PartEGG SSD Hard Drive Cable + SATA HDD Hard Drive Caddy Bracket with 2X Rubber Rails for HP Envy X360 15-BP 15-CP000 15-CN 14-CD 15-BP101TX 15m-CN0xxx 15m-CP0011DX 15-BQ000CL

While it lasts, this is what the caddy looks like.

$

•  

qrencode, you won't make scannable OTP codes, so who the heck QR you?

I previously wrote about my adventure backing up all data on my ZTE before sending it to ewaste recycling. Part of that backup was preserving my OTP MFA codes.  This blog entry is limited to a tiny bit of historical information and how I made viable OTP MFA codes with qrencode for Microsoft Authenticator.

I learned the importance of having a backup plan years ago after I had established my first OTP account on the ZTE. The ZTE was running slowly and I proceeded to wipe it. I forgot about that MFA registration until the next time I was prompted for the MFA code.  At that point I began to register MFA OTP on a second device.

In November 2017 I picked up a Verizon PAYG LG VS810PP to help activate a BYOD hotspot. I kept the LG in service as a backup MFA device. When adding a new MFA OTP accounts on the ZTE, I captured the QR code and later scanned it in to Microsoft Authenticator on the LG.

Having lost the original LG box, and within that box, the plastic backing to keep the battery in place, the LG needed to go away. 

Keeping the QR codes can be handy in case you lose your only OTP device or in the event you want to migrate to a newer device.  The issue is how to store QR codes.  Surely QR codes can be encrypted, but they are the result of the OTP URI metadata. An easier approach I found is to retain metadata containing the issuer, secret, and account and keep all OTP entries in a comma-separated values (CSV) file and encrypt that file.

In December I obtained the Microsoft Authenticator database from /data/com.azure.authenticator/databases/PhoneFactor.

The challenge I ran into in early December was the inability to generate viable QR codes for use with Microsoft Authenticator.  I rummaged through documentation like https://github.com/google/google-authenticator/wiki/Key-Uri-Format and https://stefansundin.github.io/2fa-qr/, of which the latter is rather nice because it allowed me to compare a 2fa-qr generated QR with the output of qrencode. No matter why I tried, I was unable to create an exact QR of that which 2fa-qr creates, but I did get a QR to work.

You might be thinking "why don't you use 2fa-qr."  My answer is "because I do not know the provenance or insides of 2fa-qr and for all I know, it could be logging user input data to a server."

To make a short story shorter, this is the command line that finally generated a QR code that Microsoft Authenticator would accept:

qrencode -8 -c -l L -o /tmp/qr.png -v 3 "otpauth://totp/zanzamar@earthling.net?secret=FFFFFFFFFFFFFFFF"

The above works great for a single code.  However, I have a handful of services that either require or permit MFA. I was seeking a routine to generate all the OTP QR codes for bulk repeat scanning in Microsoft Authenticator.  The above is not an actual OTP account, but rather what I fabricated to compare between 2fa-qr and qrencode.

The Microsoft Authenticator app uses an SQLite database named PhoneFactor and sqlitebrowser opens it.  In sqlitebrowser I invoked a query of "select * from accounts;"

The query output was displayed and I selected all the content. I copied and pasted in to a text editor (geany), performed a search and replace on " " (in the actual file, it is a tab character in between the quotes)  with a comma (,) and conveniently provided a .csv extension.

With a usable data source, I came up with the one liner loop. IIRC there are shell variable extraction methods I could have substituted in place of cut.  For now, I'll use cut.

NUM=1; cat ./otp.csv | sed -e 's/"//g' -e 's/ /%20/g' -e 's/@/%40/g' | while read LINE; do ACCOUNT=$(echo $LINE | cut -d, -f4); SECRET=$(echo $LINE | cut -d, -f7); ISSUER=$(echo $LINE | cut -d, -f3); qrencode -v 3 -8 -c -l -L L -o /tmp/qr-${NUM}.png "otpauth://totp/${ACCOUNT}?secret=${SECRET}&issuer=${ISSUER}; NUM=$((NUM+1)); done

With the QR codes visible in a file browser with image preview, I  scanned my OTP secrets in to Microsoft Autheticator.

After all eight OTP secrets were imported, I double-checked the OTP codes against my LG phone.  Only after confirming that all the OTP codes were identical, between the new phone with Microsoft Authenticator and the LG, did I factory wipe the LG.

I hope others find this useful.

EDIT 2020-01-05

While setting up a secondary device for MFA, I forced myself to learn the bash method of breaking the CSV lines in to tokens.
The format of the SQLite database has columns:

ms_mfa_entry_number, big_zeros_number, OTP_ISSUER,OTP_ACCOUNT,empty,1,OTP_SECRET,empty

ADDR[3] = OTP_ISSUER
ADDR[4] = OTP_ACCOUNT
ADDR[6] = OTP_SECRET - perhaps because the actual 6th column is empty so 7 assumes the place of 6?

IFS=',';NUM=1; cat ./otp.csv | sed -e 's/"//g' -e 's/ /%20/g' -e 's/@/%40/g' | while read -ra ADDR; do qrencode -v 3 -8 -c -l -L L -o /tmp/qr-${NUM}.png "otpauth://totp/${ADDR[3]}?secret=${ADDR[6]}&issuer=${ADDR[2]}; NUM=$((NUM+1)); done

Are you the valet?

Early November I wanted to extract the data I had on my very first TracFone Android device, a ZTE Valet.  It turns out the ZTE Valet is easily temp rooted.  Search for RootMyValet and a github result is the starting point.  Buried under the github lib directory (IIRC) is the roothandler binary.  I mention this because I spent days looking for the cited roothandler binary in su packages as described by the README.

All along I was misunderstanding the README.   The README states to locate my favorite su package, and extract the su binary.  It then instructs to copy the roothandler file in to the same /data/local/tmp directory as where the su binary is dropped, which gave me the impression roothandler is bundled with my favorite su package.  But enter another issue, the Valet is Android 4.1 and all the recent su binaries I extracted required PIE (not to be confused with Android P/pie). 

Eventually I found an old enough su without PIE, but not before taking an alternate path with KingRoot and discovering KingRoot not only failed to root, but successfully installed a bunch of shims to phone home statistics to qq.com and yahoo, and fails to offer the ability to uninstall.

Now I had two problems.  The mostly well mannered "malware" KingRoot -- and -- I still did not have a backup.

First off, the native Android ADB backup didn't produce anything but 504 byte sized file and Move to IOS crashed.  I tried another backup program from the Play Store, but it too, crashed. How bad is KingRoot?  After setting up a hostapd + dnsmasq + tcpdump, I didn't see anything other than small packets headed toward qq and yahoo, but that doesn't mean it didn't lift some data during the initial installation.  I'll save that for some later point in time.

As far as the RootMyValet presence on github, I gather that the RootMyValet.apk is purely a UI to invoke roothandler easily, and the github repo is the wrapper around the whole kit, which includes the apk for the optional UI invocation.

After crawling through the source code and finding a reference to a getroot function, I figured the github repo was an 'apk' that I am supposed to build myself. With that all cleared up and in possession of the roothandler binary, I prepared my own version of the script that roothandler executes.

In my own script, I had it chdir to /data and run 'busybox find | busybox cpio > /sdcard/data.cpio".  This is a simplified version of the actual command as I don't recall the precise flags that the cpio plugin of this busybox required, but it suffices to say it would have been  similar to "ov -H crc" or "ov -H newc".

If you're struggling to follow me up to this point, I used the platform-tools ADB binary, which allowed me to get a shell.  In that shell I was able to invoke roothandler and roothandler, in turn, invokes the shell script (as described in the README) to run as root anything you require during the temp root.

Happy, I got my backup successfully migrated my OTP and organization's Duo multi-factor to different devices.

Update
I dug in a bit more in to the behavior of KingRoot on a Valet.  It does work on the Valet, provided your /data volume is not encrypted.  If you encrypted your Valet using the Android setting, KingRoot will not succeed, but it will install the hooks to ship telemetry.

After it succeeds on an unencrypted Valet, and after installing SuperSU, invoke adb shell and type su. 

In this repeat attempt, I took these steps.
1. install KingRoot and launch.
2. Try Root - it succeeds.
3. install SuperSU
4. Grant SuperSU permission in KingRoot
5. adb shell, and try su, but it failed with Segmentation fault.
6. reboot the phone
7. run KingRoot again, and Try Root
8. adb shell, and try su, this time it worked.

Making the switch from IOS to Android - an iPhone Notes rescue story

In August 2019 I picked up a Pixel XL to replace my soon to be unsupported iPhone 6. I mostly use a phone for jotting down notes, texting, satisfying my curiosity on wikipedia, reading Science Daily, capturing interesting photo moments, navigation, and the weekly phone call. Almost any modern phone satisfies my use case, aside from one requirement: it needs to receive regular security updates.

The Pixel XL received test versions of Android 10, which implied it would receive a full edition. As long as I can tolerate the differences, Android 10

S&D iPhone 7's on a particular Amazon-owned deal site were above $360 and a open box new Pixel XL listed for $210.  The Pixel seemed to be a cost effective way to meet my needs.

I ordered a battery case, which is normal for any phone I pack around. Wearing the battery case, it's not huge -- it's annoyingly "Phabulous," yet I am committed to see this through.

To get my content migrated, I used the Pixel's migration assistant with the Pixel crossover dongle and the lightning cable.  It moved photos, text messages, call history, and a fairly impressive "vis-a-vis" of apps; however, app data for those it located in the Play Store, didn't make the transfer.  For instance, my TracFone app had to set up all over again.  Office Lens lacked any of the associated captures, but that did not bother me.

To my chagrin, my images sent and received via texts were not there.  Add to that, my iPhone notes had no corresponding app to receive them.  Notes were not there.

With Apple's iCloud service, you might be thinking "why is this an issue?  You can access your notes from iCloud."  I could, yes, but my data size is over the free 5GB, and I already have a OneDrive subscription and for reasons, funding iCloud instead of OneDrive is not presently an option.

Linux is all I use, and despite what others might classify as limitations, it has certain applications which make deviation from the trodden path, possible.

Committed to retiring the iPhone 6 and wanting to keep my health trend data from a Viatom app, I tried idevicebackup2. It works and produces an (optionally) unencrypted backup.  The result is a big tree of hex numbered directories under which it stores some number of hexadecimal GUIDish files under the folder tree.  Using

find . -type f -exec file {} \;

is informative and reveals the file type. Common types are Apple binary data, ASCII text, an SQLite database, a JPEG, and PNG. From this information I assembled a pipeline to include a grep for image files.  With image files, I figured I could begin to determine the app-to-image relationship and locate the apps and their corresponding files, like the database or ASCII text, or for that matter, my iPhone Notes.

I opened the Notes app on my iPhone and located a message with a distinct word that is unlikely to be found anywhere in the backup tree.  I used

grep -r "Lincoln" ./*

where the current directory (. and thus the . in ./*) is the parent directory I specified in the idevicebackup2 command line.

I found the file and copied it to a scratch space.  I used the 'file' command on it and it revealed an SQLite DB. 

I installed sqlitebrowser and opened the file.  I found that the note zdata was compressed and a simple online search yielded the syntax I needed to extract the data.  I arrived at this script which extracted everything that I cared about: the text.  I had two notes with attachments.  Upon reviewing them in my iPhone, I still put no value on keeping them.  According to the DB file, I had 473 notes.

This is the command I used. I hope it can be of help to others!

bash% COUNTER=1; while [ $COUNTER -lt 474 ]; do ZCOUNT=${COUNTER}; [ $ZCOUNT -lt 100 ] && ZCOUNT="0${ZCOUNT}"; [ $COUNTER -lt 10 ] && ZCOUNT="00${ZCOUNT}"; sqlite3 ./notes.sql3 "SELECT writefile('/home/mk/Documents/object${ZCOUNT}.gz', zdata) FROM ZICNOTEDATA WHERE z_pk = ${COUNTER};"; zcat /home/mk/Documents/object${ZCOUNT}.gz | strings > /home/mk/Documents/note-${ZCOUNT}.txt; COUNTER=$((COUNTER+1)); done

More about the TPM-iness

Last week while fumbling around through the source code for tpm_managerd, I noticed some mock units.  I got the crazy idea, what if those mock units could chat back to the TPM client and make it all happy; except that sounds like a good idea until it isn't.  Clearly the TPM needs to store key details.  If I sufficiently understand the TPM's role, and if cryptohomed thinks it has stored the key that it will need next boot, but said key did not get stored, thanks for the exercise in cryptoshredding.

The chromefy / croissant team has done a great job of making swtpm available. Kudos to croissant for helping support Chrome on devices absent a TPM2.  I have previously ranted why, personally, I do not condone third party binaries like what croissant delivers, but that set aside, providing future chrome users a way to build their own and overlay it atop an integral filesystem sounds plausible, but only thanks to the croissant team paving the way.

Admist my searching for the steps that croissant uses to build a TPM capable image, I found chromefy's steps to leverage the older Chromebook's TPM components.  Then...lightbulb comes on. 

Why not script-o-matically download two images to install an official EFI Chrome build.  At least until swtpm is absolutely required?
1. Download banjo and park under /tmp/source/TPM
2. Download release with TPM2 requirement and park under /tmp/source/ROOT-A
3. Good idea or bad? Take partition #7 (ROOT-C), resize, and store a overlay - a ext4 rootfs if you wanted.
4. Use futility to extract the EFI vmlinuz and update partition #12
5. If an initramfs can't be exposed (tested CPIO and it didn't work), edit grub to mount partition #5 - yep, no difference from croissant at this point.
6. Resize STATE and format. 
7. Create and store a remerge script on partition #7 which basically does all of the above so updates* can be incorporated by downloading the latest TPM1 available and merge with the new update on partition #5.

* - With a FALCO I updated to the latest August 29, 2019 build.  Falco was released September 29, 2013 and despite the five year life-cycle for Chrome devices, it received an update.  What does this mean in respect to the warning I received that my BANJO installation wouldn't receive any future updates?  At this point more investigate must happen.

Ah, probably all crazy speak.

The pretender: Fooling 3dmark SkyDiver to test your card

This is a quick post about a funny discovery I made when testing a GTX 460 I received second-hand.  I also received a GTX 550 knowing that it needed a GPU fan replaced, but, in a PC built from the usual modular pieces, I put in both cards just to see if the drivers would squawk about the SLI cable I affixed between them.  It did not, but it neither activated SLI.  I ran the Sky Diver benchmark and the GTX 460 completed.  Power off. I slapped on a fan to the GTX 550 which required removal of the GTX 460 due to the unsightly tape-fastened fan and it benched slower than the GTX 460. Power off. Swapped in GTX 460 in place of the GTX 550, and launched the benchmark.  But the benchmark stated I needed a capable video card.  It reported the GTX 460 as the video card installed in the system.  Power off.  Removed the ad-hoc fan from the GTX 550 and installed it in the slot neighboring the GTX 460.  Power on with both cards. Run benchmark.

My takeaway: you stand a chance of benching other DirectX 12 cards if 3dmark's Sky Diver detects you have at least one card capable of running the benchmark.  

This does make me wonder how awful a GT 630 performs on Sky Diver. The passmark video score for a GTX 460 is around 2,600 and the GT 630 - later generation but really tiny - was below 900.

Good eve-ning

In my last post,  I stated that I was all done installing Chrome OS on ordinary PC laptops.  For the next month, I have changed my mind. The same evening as writing this post, I gave one last visit to my Chrome installations, and accidentally discovered a fix to a sign-in problem I had with Eve on my devices.  Almost all of my devices on which I can sandbox Chrome OS are absent a TPM 2.0 module, which I believed was the reason why I could never complete sign-in on a fresh install.

The discovery happened while upgrading an installation of Glimmer.  Glimmer successfully updated from 68 to 76. By grabbing the PARTUUID and a little magic with sed, verity booted with vmlinuz extracted from /dev/sda4.  Skip over the next point. I included it only to jog my own memory.

• The actual image resided on an SD-CARD on which I had installed Glimmer as a way to squeeze some extra life out of a ASUS Chromebook with a crippled eMMC.  Although updates would attempt to install, it reported that no updates were available solely because on the ThinkPad Yoga 11e (20de) the internal disk drive didn't have /dev/sda4 and higher.  Apparently a check is made before downloading, and part of the check validates there's a partition to accept the update.

After the update, I had a new message stating that this was the last release of Chrome for my device.  It also meant that no further updates were allowed. That triggered my interest to follow in the footsteps of Project Croissant and see if Eve would work as far back as a BayTrail CPU.

With this current update of Glimmer, I had no idea where the system recorded the flag that no further updates were allowed.  Even by advertising it as an Eve, no new updates were available.  I rolled back to 68, which invalidated my stateful partition - not exactly unexpected - but after getting to a console,  I redeployed Eve to a resized /dev/sda5.  This redeploy involved taking advantage of /dev/zram0 to hold the expanded contents of the Eve .zip  and losetup -P to expose the partitions.  Then a dd of /dev/loop1p3 to /dev/sda5, capturing /dev/loop1p2's, /dev/loop1p4's vmlinuz and kernel configs, and finally the /dev/loop1p12 EFI partition contents.

Eve booted with vmlinuz.A from its EFI partition, but didn't with the /dev/loop1p2 derived vmlinuz.  I realized that Eve has two different kernels in the dl-edge recovery image. The /dev/loop1p2 derived image was larger than vmlinuz.A.  /dev/loop1p2 also has cros_recovery in the kernel config.  This suggested I ought to use kernel derived from /dev/loop1p4.  And, so, I discovered that the /dev/loop1p4 derived kernel worked with verity.

I expected wireless, bluetooth and sound to be asbent.  eve-release/R76-12239.92.0 doesn't come with firmware for the Intel 7260-AC, and it doesn't load support for the sound chipset in my device, but modprobe snd-hda-intel solves it.  I learned that with verity turned on, I must pass lsm.module_locking=0 at boot.  I then used the same technique I previously wrote up for my Dell Latitude 5175 to get wireless working on the ThinkPad Yoga 11e.  Surprisingly, I was not presented with a fresh Chromebook setup dialog; however, the installation continued to report that it was the last update for my system.

This was good and bad news. The good news is that I was able to get Eve working with my BayTrail. That bad news is that the stateful partition would have to be powerwashed, and I would almost certainly be unable to complete initial setup sign-in.

The normal symptom from a newer ChromeOS on a BayTrail/Haswell has been a BIOS boot loop, the screen fades to white, or I can't complete initial setup sign-in.

To rid myself of the update flag, I would have to powerwash.  After powerwashing, instead of the Chrome splash, I experienced a boot loop in to the all to familiar recovery dialog.  Instead of counting up to 5 minutes, it rapidly rebooted barely giving time black & white to see the recovery screen.

I booted a live CD and formatted the stateful partition of the internal disk to ext4 with a volume name of STATE.  I rebooted back to Eve, and sign-in failed, as expected.  Sign-in would get just beyond MFA, and then spin for about 5 minutes before reporting that sign-in failed.

I repeated the sign-in process and the system became unresponsive. I then used CTRL-ALT-F2 and signed in to the text console as root.  There was a delay of several seconds before the text console came active. I ran the command top, and observed that flashrom was using a fair amount of CPU.  I killed off flashrom, and a new flashroom process appeared to have spawned in its place.  I killed it again, and top finally indicated the CPU was nearly idle.  I returned to the Chrome interface and I was now prompted with settings for my account.

This can many any number of things, but here are two possibilities:

1. Eve now ignores TPM as a requirement and retry signing in will now complete first-time setup of a Chromebook.
2. Eve tries to flash updates before permitting setup (sign in) of a new Eve Chromebook, and if that process times out, so does signing in.  Killing off the flash updates might be accelerating the sign in process.
3. Dumb luck and timing. EDIT: 09-22-2019. I powered up the laptop and couldn't get signed in. I this happened on the 09-12-2019, but happened again. Although I had previously formatted STATE ext4, I found hints of legacy glimmer configuration under /mnt/stateful_partition/encrypted. Eve somehow snagged an update_engine config directive files and what looks like cache content, to which end removing them resolved the no more updates available issue, but after a restart, I could not get signed in.  Perhaps a previous accidental partial boot to glimmer corrupted STATE, or perhaps the purge of the glimmer containing data did me in.  I repeated the wipe of STATE.  And just like the issue on 09-12, I was unable to get signed in.  For what it is worth, I proved that even when Eve is allowing me t sign in, I can't get signed in when offline.  If I close the lid on an active session, I can resume.  If I power off, to get logged in next time, I have to be online.  Therefore, removing tpm_managerd isn't helping. Neither was killing flashrom on setup, other than, flashrom did appear to be a long running process during initial eve setup. Takeaway: It looks like that in addition to putting a layer over /lib/firmware, I'll have to put a layer over the place where swtpm should be deployed.   To keep with my desire to only use code from trusted sources, I will need to automated building my own swtpm.  I see Crossiant distributes the source code in the same spot as the .tar archive, yet the paranoid side of me thinks that binaries which process and contain sensitive user credentials are a good target for bad actors.  Building this myself is not the result I would like to have with eve; however, I feel it is better than building my own ROOT-A -B or -C, with or with other's projects, and then have to learn how to lock it back up with verity.  Or worse, disable verity.

Here's a strange behavior on my ThinkPad Yoga 11e running Eve:

• Pressing SPACE-n-m produces a beep. EDIT: 09-16-2019 this actually appears to be a key-jamming indicator.  B-N-M also does it, but J-K-L does not.  H-J-K-L also beeps.