#Google chrome install error fedora 23 update#
#Google chrome install error fedora 23 verification#

The /boot partition must sadly be ext2, since the nv-uboot images Google provide don’t have ext4 support enabled, and I don’t fancy building new images myself.

HOME – hold the /home filesystem (ext4, LUKS encrypted, ~11 GB).

BOOT – hold the /boot filesystem (ext2, unencrypted, 200 MB).

ROOT – hold the Fedora root filesystem (ext4, unencrypted, 4 GB).

The goal for the Fedora installation is to delete the ROOT-A, ROOT-B and STATE partitions from ChromeOS, and replace them with 3 new partitions: The important thing is that STATE, ROOT-A and ROOT-B are all at the end of the partition table. Notice from the offsets, that the order of the partitions on flash, does not match the partition numbers.

EFI-SYSTEM – EFI firmware files – empty by default.

ROOT-B – ChromeOS root filesystem to go with backup kernel.

ROOT-A – ChromeOS root filesystem to go with primary kernel.

KERN-B – holds the 2nd (backup) kernel image.

KERN-A – holds the 1st (primary) kernel image.

It uses GPT rather than MBR, and sets up 12 partitions, though 4 of these (ROOT-C, KERB-C, reserved, reserved) are completely unused and 2 are effectively empty (OEM, RWFW) on my system.

ChromeOS Partition Layoutīefore continuing it is helpful to understand how ChromeOS partitions the internal flash. We still have the annoying 30 second sleep at boot time, and we still can’t do secure boot of our Fedora install, but we at least get an interactive boot console for troubleshooting which is important for me. It is, however, possible to setup a chained bootloader, so that the built-in uboot will first boot nv-uboot, which is a variant of the bootloader that has the console enabled and boots any kernel without requiring them to be signed. I’ve seen hints in Google+ that you can get around this by opening up the case and working some magic with a soldering iron to set the flash writable again, but I don’t fancy going down that route. The Chromebook bootloader can’t be (easily) replaced since the flash it is stored in is set read-only. The bootloader is also locked down, so you can’t get access to the normal u-boot console – if you want to change the kernel args you need to re-generate the kernel image, which is not so much fun when troubleshooting boot problems with new kernels. You’re also stuck with an annoying 30 second sleep in the bootloader splash screen which you can only get around by pressing ‘Ctrl-D’ on every startup. The result is that while you can run non-ChromeOS operating systems, they’ll always be a second class citizen – since the developer keys are publically available, in developer mode, it’ll happily boot anyone’s (potentially backdoored) kernels.

#Google chrome install error fedora 23 verification#

There is no provision for providing your own verification keys to the bootloader, so the only way to run non-ChromeOS images is to switch to “Developer Mode” and sign kernels using the developer keys. The bootloader is setup todo “SecureBoot” of Google ChromeOS images only by default. The Samsung ARM Chromebook bootloader is a fork of u-boot.

If you don’t want to read about what the script does, skip to the end ChromeOS bootloader

#Google chrome install error fedora 23 update#

I decided to take his start, update it to Fedora 18 and then extend its capabilities. Igor Mammedov of the Red Hat KVM team, has previously written a script for automating the install of Fedora 17 onto the internal flash device, including the setup of chained bootloader with nv-uboot. With Fedora 18 now out, I thought it time to try again, this time replacing ChromeOS entirely, installing Fedora 18 ARM to the 16GB internal flash device.

Posted: March 31st, 2013 | Filed under: Fedora | Tags: arm, automated, chromebook, fedora, install, samsung | 23 Comments »īack in November last year, I wrote about running Fedora 17 ARM on a Samsung Google Chromebook, via an external SD card.