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

**~~Tito~~** · December 23rd, 2010

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

**~~Tito~~** · December 23rd, 2010

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

**~~Tito~~** · December 23rd, 2010

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.

**~~Tito~~** · December 23rd, 2010

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.

**bwhite82** · December 23rd, 2010

I look forward to seeing your guide for this. I attempted but ran into not having a 64 bit computer.

**~~Tito~~** · December 23rd, 2010

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!

Follow the instructions here:
http://www.google.com/support/chrome...answer=1046510

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.

**~~Tito~~** · December 23rd, 2010

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.

**C.S.Cameron** · December 24th, 2010

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.

**~~Tito~~** · December 24th, 2010

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.

**okdok** · December 24th, 2010

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

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

Thread Tools

Display

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

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

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

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

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

Mashed up guide

Mashed up guide

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

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

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

Bookmarks

Bookmarks

Posting Permissions