Author Topic: How to boot Ubuntu on a Cr-48 Part 1  (Read 1891 times)

Offline javajolt

  • Administrator
  • Hero Member
  • *****
  • Posts: 36005
  • Gender: Male
  • I Do Windows
    • windows10newsinfo.com
How to boot Ubuntu on a Cr-48 Part 1
« on: December 14, 2010, 07:07:58 PM »
Introduction

While Chrome OS verified boot protects against unintended system modification by malicious or buggy software, the ability to hack your own device is an intentional design feature of Google Chrome notebooks. The instructions for building your own version of Chromium OS, and installing it on a Cr-48 are given elsewhere. Some enthusiasts, however, may want to install something completely different. This page provides an example, showing how the official Chrome OS software can coexist with Ubuntu, a popular linux distribution.

These instructions work on the Cr-48 as originally shipped. There are several magic numbers that may differ on other Chromium OS-based machines.

In the examples below:

Quote
The Cr-48 shell is formatted like this.

The Chromium OS build chroot is formatted like this.

The standard linux workstation shell is formatted like this.

Fair warning

This is kind of a cheat. The Cr-48's boot process does not support initrd, which is required by Ubuntu. That leaves us three possibilities:

1. Use the existing Chrome OS kernel with the Ubuntu rootfs.
2. Recompile the Ubuntu kernel to do without initrd (ugh).
3. Modify the Chrome OS bootstub to handle initrd (double-ugh).

Let's take door #1.

Free up some SSD space for Ubunt

To begin our journey, first switch the Cr-48 into developer mode and reboot.  When you see the blue frowny face with the "Chrome OS verification is turned off" message, either wait 30 seconds or hit Ctrl-D to boot immediately. This screen is always shown when booting in developer mode, to ensure that someone doesn't change your OS without your knowledge.

Switch to VT2 (press [ Ctrl ] [ Alt ] [ => ]), and log in as user 'chronos' (no password required), then run sudo bash.

To prevent the lock screen from logging you out of VT2, leave Chrome OS parked on the login screen. To prevent the backlight from dimming while in VT2, run sudo initctl stop powerd.

Take a look at the SSD layout. It should be something like this (the UUID values will all be different, of course):

Quote
localhost ~ # cgpt show /dev/sda
     start      size    part  contents
         0         1          PMBR (Boot GUID: 045E5C92-6F57-9B46-BDCC-99BFF876E469)
         1         1          Pri GPT header
         2        32          Pri GPT table
    266240  22622208       1  Label: "STATE"
                              Type: Linux data
                              UUID: 1844A16D-AEC9-7C4B-9553-C3EB4814F6BB
      4096     32768       2  Label: "KERN-A"
                              Type: ChromeOS kernel
                              UUID: D176DC60-81F1-654E-8953-E3D28019738C
                              Attr: priority=3 tries=0 successful=1
  27082752   4194304       3  Label: "ROOT-A"
                              Type: ChromeOS rootfs
                              UUID: 0193CA51-DA12-9847-A715-C90433E55F60
     36864     32768       4  Label: "KERN-B"
                              Type: ChromeOS kernel
                              UUID: F1A2C65C-CC22-FF4A-A8BC-67BA233F3D40
                              Attr: priority=0 tries=15 successful=0
  22888448   4194304       5  Label: "ROOT-B"
                              Type: ChromeOS rootfs
                              UUID: B3361FB5-4DAC-9344-B7E5-870B7AC5FEA1
        34         1       6  Label: "KERN-C"
                              Type: ChromeOS kernel
                              UUID: B6954485-4295-9749-956A-C315B01FB684
                              Attr: priority=0 tries=15 successful=0
        35         1       7  Label: "ROOT-C"
                              Type: ChromeOS rootfs
                              UUID: 5B5202B5-F74B-714E-9538-ADE56B2E5662
     69632     32768       8  Label: "OEM"
                              Type: Linux data
                              UUID: 84971802-0D1C-504B-9CB5-DEA896F0AD3F
        36         1       9  Label: "reserved"
                              Type: ChromeOS reserved
                              UUID: 77375DA6-8F07-704A-BBF4-2BCA662BFDFF
        37         1      10  Label: "reserved"
                              Type: ChromeOS reserved
                              UUID: 6880F478-EB05-8B4B-B951-94A96076263E
        38         1      11  Label: "reserved"
                              Type: ChromeOS reserved
                              UUID: 12DDC236-8FDF-4049-9A2D-10FAB17D3AA9
    233472     32768      12  Label: "EFI-SYSTEM"
                              Type: EFI System Partition
                              UUID: 045E5C92-6F57-9B46-BDCC-99BFF876E469
  31277199        32          Sec GPT table
  31277231         1          Sec GPT header

The units are 512-byte disk sectors.

On Chrome OS there are several bootable images, each composed of a kernel and a root filesystem (rootfs).  For a given image, the kernel and rootfs are stored on a pair of consecutive partitions.  Two of these images, Image-A and Image-B, are for official Chrome OS:

• KERN-A and ROOT-A on partitions /dev/sda2 and /dev/sda3

• KERN-B and ROOT-B on partitions /dev/sda4 and /dev/sda5

When the Chrome OS autoupdater downloads a new image (every six weeks or so, as new versions are pushed out), it alternately stores it in Image-A and Image-B - whichever image isn't currently running.  The autoupdater even runs in developer mode, as long as we are running an official Chrome OS image.

For Ubuntu, we'll use the currently unassigned Image-C, composed of KERN-C and ROOT-C on partitions /dev/sda6 and /dev/sda7, respectively.

However, initially they are too small so, first we need to grow them by stealing from the upper half of the stateful partition, STATE (/dev/sda1).  Initially, STATE is 22622208 512-byte sectors, or just under 11 GB.  From this we'll set aside 16 MB for KERN-C, and 5 GB for ROOT-C.

Quote
umount /mnt/stateful_partition
cgpt add -i 1 -b 266240    -s 12103680 -l STATE   /dev/sda
cgpt add -i 6 -b 12369920  -s 32768    -l KERN-C  /dev/sda
cgpt add -i 7 -b 12402688  -s 10485760 -l ROOT-C  /dev/sda

Using these values ensures that only the original STATE partition is affected.

Now the partition table should look something like this (changes in bold):

Quote
localhost ~ # cgpt show /dev/sda
     start      size    part  contents
         0         1          PMBR (Boot GUID: 045E5C92-6F57-9B46-BDCC-99BFF876E469)
         1         1          Pri GPT header
         2        32          Pri GPT table
    266240  12103680       1  Label: "STATE"
                              Type: Linux data
                              UUID: 1844A16D-AEC9-7C4B-9553-C3EB4814F6BB
      4096     32768       2  Label: "KERN-A"
                              Type: ChromeOS kernel
                              UUID: D176DC60-81F1-654E-8953-E3D28019738C
                              Attr: priority=3 tries=0 successful=1
  27082752   4194304       3  Label: "ROOT-A"
                              Type: ChromeOS rootfs
                              UUID: 0193CA51-DA12-9847-A715-C90433E55F60
     36864     32768       4  Label: "KERN-B"
                              Type: ChromeOS kernel
                              UUID: F1A2C65C-CC22-FF4A-A8BC-67BA233F3D40
                              Attr: priority=0 tries=15 successful=0
  22888448   4194304       5  Label: "ROOT-B"
                              Type: ChromeOS rootfs
                              UUID: B3361FB5-4DAC-9344-B7E5-870B7AC5FEA1
  12369920     32768       6  Label: "KERN-C"
                              Type: ChromeOS kernel
                              UUID: B6954485-4295-9749-956A-C315B01FB684
                              Attr: priority=0 tries=15 successful=0
  12402688  10485760       7  Label: "ROOT-C"
                              Type: ChromeOS rootfs
                              UUID: 5B5202B5-F74B-714E-9538-ADE56B2E5662
     69632     32768       8  Label: "OEM"
                              Type: Linux data
                              UUID: 84971802-0D1C-504B-9CB5-DEA896F0AD3F
        36         1       9  Label: "reserved"
                              Type: ChromeOS reserved
                              UUID: 77375DA6-8F07-704A-BBF4-2BCA662BFDFF
        37         1      10  Label: "reserved"
                              Type: ChromeOS reserved
                              UUID: 6880F478-EB05-8B4B-B951-94A96076263E
        38         1      11  Label: "reserved"
                              Type: ChromeOS reserved
                              UUID: 12DDC236-8FDF-4049-9A2D-10FAB17D3AA9
    233472     32768      12  Label: "EFI-SYSTEM"
                              Type: EFI System Partition
                              UUID: 045E5C92-6F57-9B46-BDCC-99BFF876E469
  31277199        32          Sec GPT table
  31277231         1          Sec GPT header

At this point we should destroy the STATE partition contents, because otherwise at the next boot the startup scripts may notice that it's corrupted and will erase it using the old size (obtained from dumpe2fs) and not the new one. Best to be safe and just zap it now. This will take a couple of minutes to run:

Quote
dd if=/dev/zero of=/dev/sda bs=131072 seek=1040 count=47280

To speed up SSD access, we use a block size of 131,072 bytes (128 KB), which aligns with the SSD erase size.

And now reboot so that the startup script recreates the required files in the stateful partition. This will do a safe wipe first, so you'll have to wait a bit (again).

At this point we're through fiddling with the partition table, so you may want to go back to VT2 and set a password according to these instructions.

« Last Edit: December 15, 2010, 02:47:50 AM by javajolt »