Page 1 of 11 123 ... LastLast
Results 1 to 10 of 103

Thread: I am trying to install Ubuntu to my CR-48. . .I don't have a 64-bit capable computer.

  1. #1
    Join Date
    Jul 2007
    Location
    With Tux
    Beans
    691
    Distro
    Ubuntu 10.10 Maverick Meerkat

    Exclamation [SOLVED]Installing Ubuntu on a CR-48. . .Don't have a 64-bit capable computer?

    What should I do? All I need is chroot? I downloaded and sync'd the Chromium OS dev environment ONLY for the chroot since that is all I need, and I cant use it since it only works on 64 bit. I cant get it to work after trial and tribulation either lol. Its a big PITA, its just chroot, nothing else. Everything else is either entered from the CR-48's terminal, or from native linux. Any input here? I really want a lightweight Linux box, especially one like this!

    I am following this guide:
    http://www.chromium.org/chromium-os/...ntu-on-a-cr-48

    I used this guide to try and get chroot:
    http://www.chromium.org/chromium-os/developer-guide
    Last edited by ~~Tito~~; December 23rd, 2010 at 11:17 AM. Reason: the problem is solved

  2. #2
    Join Date
    Jul 2007
    Location
    With Tux
    Beans
    691
    Distro
    Ubuntu 10.10 Maverick Meerkat

    Exclamation Re: I am trying to install Ubuntu to my CR-48. . .I don't have a 64-bit capable compu

    I solved it by ssh'ing the CGPT file into my chroot/bin folder. Then meshed these two guides together to make things simple and quick. Make sure you mostly follow the first guide, then use the 2nd guide for things that don't work for you.

    Use this for a basic chroot, then place the CGPT file in the /var/chroot/bin folder. Make sure you note where the chroot temp directory is, since that is where your .bin, and .vdi's will be, not in the Chromium OS chroot folder as the 1st guide says.

    http://help.ubuntu.com/community/BasicChroot

    http://www.chromium.org/chromium-os/...ntu-on-a-cr-48

    http://bbs.archlinux.org/viewtopic.php?id=110208&p=1
    Last edited by ~~Tito~~; December 23rd, 2010 at 11:16 AM.

  3. #3
    Join Date
    Jul 2007
    Location
    With Tux
    Beans
    691
    Distro
    Ubuntu 10.10 Maverick Meerkat

    Exclamation Re: I am trying to install Ubuntu to my CR-48. . .I don't have a 64-bit capable compu

    Oh, when you are editing the kernal, follow the guide on the chromium OS site, and get the files you need from the arch forums.

  4. #4
    Join Date
    Jul 2007
    Location
    With Tux
    Beans
    691
    Distro
    Ubuntu 10.10 Maverick Meerkat

    Exclamation Re: I am trying to install Ubuntu to my CR-48. . .I don't have a 64-bit capable compu

    One more thing, make sure you use the USB stick method of delivering the rootfs.bin. Just mount the USB stick on the CR-48, then do the dd flash command. It takes a long while, maybe a good 10 - 15 min.


    Maybe later on I will make a mashed together guide with the steps I used.

  5. #5
    Join Date
    Dec 2006
    Location
    US and A
    Beans
    919
    Distro
    Ubuntu Development Release

    Re: I am trying to install Ubuntu to my CR-48. . .I don't have a 64-bit capable compu

    I look forward to seeing your guide for this. I attempted but ran into not having a 64 bit computer.
    _,-O
    O
    (_)) ubuntu -
    -`-O

  6. #6
    Join Date
    Jul 2007
    Location
    With Tux
    Beans
    691
    Distro
    Ubuntu 10.10 Maverick Meerkat

    Exclamation Mashed up guide

    Okay, this is just a mashed together guide between the Chromium OS site, and a guide a user posted on the Arch Linux forums. Also referring to the setting up a basic chroot guide

    First things first: Things you will need!
    • Having a 2gb+ USB stick, or memory card reader with a 2gb+ card on it
    • Having an 8gb+ Usb stick, or memory card reader with a 8gb+ card on it
    • Set Up a basic chroot
    • Setting up a recovery stick for the CR-48 incase you screw up partitions
    • Setting up an ssh partner ship between the CR-48 and your linux box
    • SSH'ing the required file to be able to do the chroot commands
    • Time
    • Patience and some linux knowledge
    • Virtual Box installed
    • Ubuntu installation image for 10.10, this can be any linux distro as well.


    Peparations
    This is mostly taken from the guides from above.

    Creating a chroot

    Install the
    Code:
    dchroot
    and
    Code:
    debootstrap
    packages.
    As an administrator (i.e. using sudo), create a new directory for the chroot. In this procedure, the directory
    Code:
    /var/chroot
    will be used. To do this, type
    Code:
    sudo mkdir /var/chroot
    into a command line.

    As an administrator, open /etc/schroot/schroot.conf in a text editor. Type
    Code:
    cd /etc/schroot
    , followed by
    Code:
    gksu gedit schroot.conf
    . This will allow you to edit the file.

    Add the following lines into schroot.conf and then save and close the file. Replace your_username with your username.
    Code:
    [lucid]
    description=Ubuntu Lucid
    location=/var/chroot
    priority=3
    users=your_username
    groups=sbuild
    root-groups=root
    Open a terminal and type:
    Code:
    sudo debootstrap --variant=buildd --arch i386 lucid /var/chroot/ http://mirror.url.com/ubuntu/
    This will create a basic 'installation' of Ubuntu 10.04 (Lucid Lynx) in the chroot. It may take a while for the packages to be downloaded.
    Note: You can replace lucid with the Ubuntu version of your choice.
    Note: You must change the above mirror.url.com with the URL of a valid archive mirror local to you.
    A basic chroot should now have been created. Type sudo chroot /var/chroot to change to a root shell inside the chroot.
    Setting-up the chroot
    There are some basic steps you can take to set-up the chroot, providing facilities such as DNS resolution and access to /proc.

    Note: Type these commands in a shell which is outside the chroot.

    Type the following to mount the /proc filesystem in the chroot (required for managing processes):
    Code:
    sudo mount -o bind /proc /var/chroot/proc
    Type the following to allow DNS resolution from within the chroot (required for Internet access):
    Code:
    sudo cp /etc/resolv.conf /var/chroot/etc/resolv.conf
    Very few packages are installed by default in a chroot (even sudo isn't installed). Use apt-get install package_name to install packages.

    Open another Terminal and type the following to enter the chroot:
    Code:
    sudo chroot /var/chroot

    Now that you have the chroot set up you have to set up a recovery stick in case you ever screw up. This allows you to restore everything to how it was when you first got your CR-48. You will need another USB stick, 2gb is the perfect size. Just refer to this section to when ever you screw up then start over and go to the point you where at before you screwed up, then continue. When you run the script, don't delete the temp files, it saves you loads of time!


    Setting up SSH
    Assuming you have wifi, and have knowledge of SSH, and both the CR-48 and the Linux box you will be doing this from are connected to the same wifi network:

    Switch to VT2 (press [ Ctrl ] [ Alt ] [ --> ]), and log in as user
    Code:
    chronos
    (no password required), then run
    Code:
    sudo bash
    *You don't need to set up a password for chronos, that locks you out of login in as root with no password.

    Connect to your linux box by entering:
    Code:
    ssh {Your User name for your linux box}@{The local ip the linux box has, IE 192.168.xxx.xxx}
    Then follow the dialogs, and type yes when necessary to connect. Ignore the warnings.

    Now that you are connected type
    Code:
    exit
    and it should go back to the chronos user. Type
    Code:
    sudo bash
    to get permissions again.

    SSHing the required file
    Now that we can use ssh we have to send the CGPT file to your linux box in order to do the chroot part of the guide later.

    Make sure you are still logged in and have the proper permissions still.

    Type on the CR-48
    Code:
    scp /usr/bin/cgpt user@ubuntuHost:/var/chroot/bin
    Once it transfered successfully type this on your linux box in a terminal
    Code:
    chmod a+rx /var/chroot/bin/cgpt
    When that is done now we can start setting up the ubuntu image for the CR-48.

    Virtual Box and Setting it up to copy to the CR-48 directly

    First, although the Cr-48 CPU and BIOS is 64-bit, the kernel and rootfs are presently 32-bit. Since you're reusing the Chrome OS kernel, you'll download and use the 32-bit ubuntu-10.10-desktop-i386.iso from an Ubuntu CD mirror. For example:

    wget http://mirror.anl.gov/pub/ubuntu-iso...sktop-i386.iso

    Second, even in developer mode, the Cr-48 will only boot external drives that are signed by Google. That means we can't (easily) use the normal Ubuntu live installer. Instead, create an empty disk image file with a 5G partition on it, and use VirtualBox to install into that. Then transfer that raw partition onto the Cr-48 once you set up the partitions.

    To install VirtualBox (and its command line management tool, VBoxManage) on Ubuntu:

    Code:
    sudo aptitude install virtualbox-ose
    Create the file inside the chroot so I can use the cgpt tool, but run VirtualBox from outside.
    You need our disk image to be a little larger than 5G so it has room for the GPT headers.

    So, do the following, open a terminal, open chroot then enter this

    Code:
    cd /tmp
    Code:
    rm -rf test.bin
    Code:
    dd if=/dev/zero bs=512 seek=10486015 count=1 of=test.bin
    Code:
    cgpt create test.bin
    Code:
    cgpt boot -p test.bin
    Code:
    cgpt add -b 128 -s 10485760 -t data -l ubuntu test.bin
    From outside the chroot, translate the binary into a virtualbox disk:

    Code:
    cd /var/chroot/tmp
    Code:
    VBoxManage convertdd test.bin test.vdi --format VDI
    Launch the VirtualBox GUI (virtualbox) and create a new virtual machine with 2G of RAM(It is unnecessary to specify that amount of ram unless your machine can handle it. Specify the amount your machine will handle). Configure test.vdi as the existing hard disk (SATA port 0), and attach the Ubuntu .iso as the IDE secondary master. Everything else can be left as default.

    Boot the virtual machine and install Ubuntu onto /dev/sda1. The Chrome OS kernel does not use swap memory, so be sure to specify partitions manually. Select the middle /dev/sda1, and format it for ext2, and mount on /. The ubuntu installer should warn you that you have no swap partition, and it will therefore disable swap. This is what we want.

    Once Ubuntu is installed, working and updated, shut the virtual machine down and convert the .vdi image back into a binary:

    Code:
    VBoxManage internalcommands converttoraw test.vdi test_new.bin
    Now, we'll extract just the Ubuntu rootfs partition from the binary file:

    Code:
    dd if=test_new.bin bs=512 skip=128 count=10485760 of=rootfs.bin
    Transfer the resulting file onto the USB 8gb+ flash drive or Card reader with an 8gb+ card in it. Then have it ready when you need it for the next section.
    Last edited by ~~Tito~~; December 26th, 2010 at 01:52 AM.

  7. #7
    Join Date
    Jul 2007
    Location
    With Tux
    Beans
    691
    Distro
    Ubuntu 10.10 Maverick Meerkat

    Mashed up guide

    Making Partitions and setting up ubuntu
    Remember the Recovery stick that was made earlier in the guide? This is where it comes in handy, these commands change the partition sizes on the SSD of the CR-48 and if you screw up you can reboot and it tells you to use a recovery stick. That is why you have to make it, plus it is handy if you just want Chrome OS back for good. Since you did the preparations before hand you can just jump right in to resizing the partitions and continuing if you ever mess up.

    First go to the CR-48 terminal, then login as
    Code:
    chronos
    as usual and type
    Code:
    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
    Code:
    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):

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

    Code:
    umount /mnt/stateful_partition
    Code:
    cgpt add -i 1 -b 266240    -s 12103680 -l STATE   /dev/sda
    Code:
    cgpt add -i 6 -b 12369920  -s 32768    -l KERN-C  /dev/sda
    Code:
    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):

    Code:
    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:

    Code:
    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).

    Once it boots enter the terminal, then connect the USB Flash drive or Card reader with the card in it.

    First find what drive it is before you mount it
    Code:
    dmesg | tail
    When you find the drive name, mount it
    Code:
    mount /dev/xxx /media
    Then flash the rootfs by typing in this DD command, remember if you ever screw up you can always restore it with the USB restore stick.

    Code:
    dd if=/media/rootfs.bin of=/dev/sda7
    Once it completes, unmount the drive

    Code:
    umount /dev/XXX /media
    then take it out.

    You can see that it worked by mounting the new rootfs and looking around:

    Code:
    mkdir /tmp/urfs
    Code:
    mount /dev/sda7 /tmp/urfs
    Code:
    ls /tmp/urfs
    While we're looking, let's copy the cgpt tool into Ubuntu's rootfs. Make sure it's executable. We'll need this later.

    Code:
    cp /usr/bin/cgpt /tmp/urfs/usr/bin/
    Code:
    chmod a+rx /tmp/urfs/usr/bin/cgpt
    We'll need to copy all the kernel modules too.

    Code:
    cd /lib/modules
    Code:
    cp -ar * /tmp/urfs/lib/modules/
    That should do it.

    Code:
    umount /tmp/urfs
    You can now move on to editing your kernal and booting into Ubuntu or the linux distro of your choosing.

    Configure the kernel
    Continue on from the last step, this is still from the CR-48.

    The next step is to copy the currently running Chrome OS kernel to KERN-C (/dev/sda6). Remember, an image consists of a kernel and a rootfs on consecutive partitions. So, to figure out which kernel is running, we can check which partition is currently mounted as the rootfs:

    Code:
    rootdev -s
    If this prints
    Code:
    /dev/sda3
    (ROOT-A), then our kernel is on /dev/sda2 (KERN-A).
    If this prints
    Code:
    /dev/sda5
    (ROOT-B), then our kernel is on /dev/sda4 (KERN-B).
    Assuming our kernel is on
    Code:
    /dev/sda2
    (KERN-A), copy it to /dev/sda6 (KERN-C):

    Code:
    dd if=/dev/sda2 of=/dev/sda6
    Now we need to change the kernel command line to use our Ubuntu rootfs instead of a Chrome OS rootfs. For this, we'll use make_dev_ssd.sh, located here. The latest version has options to change individual kernel command lines. You also need to haev the common.sh file. So download it here. Make two blank files in a folder of your choosing, then paste the code for each file. Then name them appropriately. (IE, the file with the script for common.sh is named common.sh)

    Use scp to copy it from your host to the stateful partition of the Cr-48.
    NOTE THE "." after the directory
    Code:
    cd /mnt/stateful_partition
    Code:
    scp USER@HOST:/some/path/to/latest/make_dev_ssd.sh .
    Code:
    scp USER@HOST:/some/path/to/latest/common.sh .
    Extract the existing kernel command line from KERN-C, and save it to a file named foo.6 (the .6 extension is added by the script):

    Code:
    sh ./make_dev_ssd.sh --partitions '6' --save_config foo
    The default Chrome OS kernel command line looks something like this:

    Code:
    quiet console=tty2 init=/sbin/init add_efi_memmap boot=local rootwait ro noresume noswap i915.modeset=1 loglevel=1 cros_secure kern_guid=%U tpm_tis.force=1 tpm_tis.interrupts=0 root=/dev/dm-0 dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=1 dm="vroot none ro,0 1740800 verity /dev/sd%D%P /dev/sd%D%P 1740800 1 sha1 50adbfb72bb1efda0c1a86dcd1c1d6a0b46726d1" noinitrd
    The only editor on the Cr-48 is qemacs, so open foo.6 with qemacs:

    Code:
    qemacs foo.6
    Edit the file to look like this:

    Code:
    console=tty1 init=/sbin/init add_efi_memmap boot=local rootwait ro noresume noswap i915.modeset=1 loglevel=7 kern_guid=%U tpm_tis.force=1 tpm_tis.interrupts=0 root=/dev/sda7 noinitrd
    Then save (Ctrl-x Ctrl-s) and exit (Ctrl-x Ctrl-c). qemacs occasionally gets confused, so double-check to be sure you have the right content:

    Code:
    cat foo.6
    Finally, use make_dev_ssd.sh to replace the kernel command line in KERN-C:

    Code:
    sh ./make_dev_ssd.sh --partitions '6' --set_config foo
    The kernel command line is part of the kernel partition, and the entire partition must be cryptographically signed in order to work. We can't replace the command line part without affecting the entire kernel partition. The script will save a backup copy before replacing the partition content, but we shouldn't need it.

    Setting boot priority

    At this point we should have the following situation:

    Image-A is an official Google Chrome OS which can boot either in normal mode or dev-mode.
    Image-B is (or will be after the first autoupdate) another official Google Chrome OS which can boot either in normal mode or dev-mode.
    Image-C is Chrome OS kernel with a modified command line and an Ubuntu rootfs, which can only boot in dev-mode.

    Next, we adjust the priority among the images so we can try out our Ubuntu image. The image priority is an attribute of its kernel partition. Run
    Code:
    cgpt show /dev/sda again
    , to see the kernel priorities:

    NOTE THIS WONT BE THE ONLY THING THAT SHOWS UP
    Code:
    localhost ~ # cgpt show /dev/sda
    ...
          4096     32768       2  Label: "KERN-A"
                                  Type: ChromeOS kernel
                                  UUID: D176DC60-81F1-654E-8953-E3D28019738C
                                  Attr: priority=3 tries=0 successful=1
    ...
         36864     32768       4  Label: "KERN-B"
                                  Type: ChromeOS kernel
                                  UUID: F1A2C65C-CC22-FF4A-A8BC-67BA233F3D40
                                  Attr: priority=0 tries=15 successful=0
    ...
      12369920     32768       6  Label: "KERN-C"
                                  Type: ChromeOS kernel
                                  UUID: B6954485-4295-9749-956A-C315B01FB684
                                  Attr: priority=0 tries=15 successful=0
    The priority determines the order in which the BIOS tries to find a valid kernel (bigger is higher, zero means don't even try). The tries field is decremented each time the BIOS tries to boot it, and if it's zero, the kernel is considered invalid (this lets us boot new images without looping forever if they don't work). The successful field overrides the tries field, but is only set by the OS once it's up and running.

    Let's change the priority of KERN-C to 5:

    Code:
    cgpt add -i 6 -P 5 -T 1 -S 0 /dev/sda
    This makes KERN-C the highest priority, but only gives us one chance to boot it. That way if it doesn't work, we're not completely stuck.

    If you reboot now, you should come up in Ubuntu! Note that Computer Science Standard Answer #1 applies: It Works For Me™

    If something went wrong and Ubuntu crashes or you powered off, the tries field for KERN-C will have been decremented to 0 and you'll fall back to booting Chrome OS.

    Assuming that Ubuntu booted and you could log in, go to Applications->Accessories->Terminal to get a shell, and run

    Code:
    sudo cgpt add -i 6 -P 5 -S 1 /dev/sda
    This will mark the Ubuntu kernel as valid, so it will continue to boot next time.

    Now you can switch back and forth between the official Chrome OS release and Ubuntu just by flipping the dev-mode switch. Going from dev-mode to normal mode erases STATE (/dev/sda1), but much more quickly. Going from normal to dev-mode again would normally do a slow erase of /dev/sda1, but since we're booting Ubuntu that doesn't happen.

    This works because although KERN-C has the highest priority, it isn't signed by Google. In dev-mode that's okay, but in normal mode it will be rejected by the BIOS. Since we've set the successful flag to 1, the BIOS won't mark it invalid but will just skip it each time. This makes the normal-mode boot time slightly longer, but only by a second or two.

    Of course you could also switch between images from within dev-mode just by manually setting the priorities with cgpt before rebooting.

    Note that if the normal image autoupdates, it will probably change the kernel priorities so that Image-C is no longer the highest and the next time you switch to dev mode, you will
    a) have a long wait,
    b) still be running Chrome OS, and
    c) have to use cgpt to raise the KERN-C priority again.

    But, because autoupdate only switches between Image-A and Image-B, the Ubuntu kernel and rootfs shouldn't be affected.
    Last edited by ~~Tito~~; December 24th, 2010 at 01:35 AM.

  8. #8
    Join Date
    Jun 2007
    Location
    Hikkaduwa, Sri Lanka
    Beans
    2,656
    Distro
    Ubuntu 14.04 Trusty Tahr

    Re: I am trying to install Ubuntu to my CR-48. . .I don't have a 64-bit capable compu

    I've only been running chromeos on my Eee PC.
    With the Hexxeh image I ran sudo apt-get update ubuntu-desktop.
    It seemed to run OK but it ran out of space.
    When I tried to expand the partitions gparted would crash.

  9. #9
    Join Date
    Jul 2007
    Location
    With Tux
    Beans
    691
    Distro
    Ubuntu 10.10 Maverick Meerkat

    Wink Re: I am trying to install Ubuntu to my CR-48. . .I don't have a 64-bit capable compu

    The CR-48 has 16gb on an internal SSD. This is a dual booting method. The install should have about 6gb free space, and thats plenty for a small linux box.

    EDIT: I meant there is 6gb available to install too. Which is plenty for a small linux box.
    Last edited by ~~Tito~~; December 27th, 2010 at 11:33 AM.

  10. #10
    Join Date
    Oct 2007
    Location
    127.0.0.1
    Beans
    33
    Distro
    Ubuntu 11.04 Natty Narwhal

    Re: I am trying to install Ubuntu to my CR-48. . .I don't have a 64-bit capable compu

    @Tito,

    Replying to this thread using 10.10 Netbook edition from my CR-48. Everything worked out of the box as you detailed. I can confirm that it works for me too!

    Thanks for taking the time to organize the mashup in a sensible way. I had no difficulty whatsoever.

    Look forward to enjoying my dual boot while testing the Chrome OS and keeping another productive foot in my Ubuntu environment.

Page 1 of 11 123 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •