Polishing some Chrome

This is a short recap on my lack of progress over the last few months in making stock Chrome a solid platform for compatible hardware. I halted work on it when I found myself unable capture the kernel that most Chrome builds deploy to the KERN-A or KERN-B partition after successfully updating the ROOT-A or ROOT-B partition. 

By accident, I stumbled on to the very tool I needed in a bit of code for SuperSU.  That tool is futility.  The command line syntax of futility is self-explanatory.  After ChromeOS reports that you are up to date, use futility to extract the vmlinuz. The next dialog requires you have cros_debug passed to the kernel at boot and that a shell (CTRL-ALT-T) grants you root. UEFI boot is assumed in this example.  The EFI partition is normally partition #12 (/dev/sda12) and for my example I have mounted it under /tmp/sda12.

futility vbutil_kernel --get-vmlinuz /dev/sda4 --vmlinuz-out /tmp/sda12/syslinux/vmlinuz.B

The futility binary can also yank out the command line for the kernel, albeit having unresolved variables, for the kernel.  With a little comparison to existing entries in the grub configuration, it seems pretty straight forward that by fetching the PARTUUID for the newly updated partition and combining that with the remainder of the verity syntax, verity can be enabled.

In the small ground made moments before writing this up, I cut a corner by specifying root=/dev/sda5, but still cheered loudly when Chrome booted and reflected the upgrade from 68 to 76. 

Despite the small victory and the ease it would seem there is in automating updates with less than 10 commands, it is unlikely I will contribute any future updates on this blog.

While searching for answers to some of my own Chrome on PC laptops, I discovered that alternatives are bountiful. With several alternative sources for a Chrome hybrid installation available, FydeOS, AtB, Chromefy, any other write-up should be provided only because it has something the others lack and something and audience connects with. The alternative offerings keep improving and simplifying the update process, which in essence achieves what I finally scored today with futility, even if it does not have a parallel to my desire to preserve factory image integrity.

Furthermore, now that TPM's have become a standard part of Chromebooks, I suspect my fascination with making an uber Chromebook from an i3 or higher Windows or Linux laptop will fade, simply due to the challenge and implication of neutering kernel-based TPM security.

As a reminder, my objective was to provide a deployment method using only stock Chrome image, with Play Store support where factory offered, and result in a system successfully applies updates.  Now that this is complete, I am moving on.