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.
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.
