October 30, 2010
October 27, 2010
⟾ 12 Minutes: Chromium OS Chromium OS is developer version so you will need time to time to Update and Rebuild Chromium OS image. This entry present skeleton how to do it.
First I will recommend look in chromium-os-dev forum for PSA announcements – these are important changes which can affect process of Updating and Rebuilding your Chromium OS image.
Update: Important PSA announcements are now part of repo sync final report.
Last Update for: 0.9.130.9 2011/01/02
Peoples perceive then Building (Compiling) of Chromium OS is SLOW !!!.
Generally IDEALLY you need for smooth compiling of Chromium OS good Internet connection, Powerful 64bit CPU and Lot of Memory (+ fast disk) .
October 15, 2010
⟾ 12 Minutes: Chromium OS Procedure for creating virtual images change recently, so here is my steps:
Last Updated for: 0.9.85 2010/10/16 1739
Chromium OS use embedded design with focus on small amount of platforms – boards.
If you don’t have compatible with Chromium OS , Virtualization can be a vital alternative.
Chromium OS is for a 32bit OS so you can probalyl run it OK on wide range of Virtualization platforms.
Many evaluators are surprised them Virtualization Tools from concrete platform can’t be installed on Chromium OS due to embedded design with Read-Only Root approach.
1. Virtual Images are now created inside of chroot
whoami chronocb cd ~/chromiumos/src/scripts/ repo sync ./image_to_vm.sh --help This script must be run inside the chroot. Run this first: /buildarea/chromiumos/src/scripts/enter_chroot.sh (cros-chroot)$ ./image_to_vm.sh --help USAGE: ./image_to_vm.sh [flags] args flags: --board: Board for which the image was built (default: 'x86-generic') --[no]factory: Modify the image for manufacturing testing (default: false) --[no]factory_install: Modify the image for factory install shim (default: false) --[no]force_copy: Always rebuild test image (default: false) --format: Output format, either qemu, vmware or virtualbox (default: 'qemu') --from: Directory containing rootfs.image and mbr.image (default: '') --[no]full: Build full image with all partitions. (default: false) --[no]make_vmx: Create a vmx file for use with vmplayer (vmware only). (default: true) --mem: Memory size for the vm config in MBs (vmware only). (default: 1024) --rootfs_partition_size: rootfs parition size in MBs. (default: 1024) --state_image: Stateful partition image (defaults to creating new statful partition) (default: '') --statefulfs_size: Stateful partition size in MBs. (default: -1) --[no]test_image: Copies normal image to chromiumos_test_image.bin, modifies it for test. (default: false) --to: Destination folder for VM output file(s) (default: '') --vbox_disk: Filename for the output disk (virtualbox only). (default: 'os.vdi') --vdisk_size: virtual disk size in MBs. (default: 3072) --vmdk: Filename for the vmware disk image (vmware only). (default: 'ide.vmdk') --vmx: Filename for the vmware config (vmware only). (default: 'chromiumos.vmx') -h,--[no]help: show this help (default: false)
Here are outputs from modified freeBSD cGPT tool inside Chromum OS build chroot and gdisk / fdisk directly from Ubuntu host:
October 14, 2010
⟾ 12 Minutes: Chromium OS To build a Chromium OS yourself you need a 64bit Linux OS, I also try Fedora 13 64bit, but for this 2 reasons I stick with Ubuntu 10.04 LTS
1. Because most developers are use a Ubuntu
2. Because kernel in Chromuim OS is based on Ubuntu LTS source tree
Installing Ubuntu Desktop 10.04.1 LTS 64bit
Having very similar kernel can help me in way, then I can troubleshoot all HW issues in Ubuntu directly,
for many debugging tasks I will need a GUI so this is why I choose Desktop version.
I use a default installation of Ubuntu Desktop 10.04.1 LTS 64bit
For regular building Chromium OS I create a dedicated partition as /buildarea (you need keep in ming then Chromium OS images have couple GB each) and I make SWAP on third partition,
because Chromium OS build setup put on third partition root file system by default,
so this setup preventing me from incidentally start Ubuntu root from Chromium OS kernel.
sudo fdisk -l /dev/sdb Disk /dev/sdb: 80.0 GB, 80026361856 bytes 255 heads, 63 sectors/track, 9729 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x0005d926 Device Boot Start End Blocks Id System /dev/sdb1 * 1 3647 29294496 83 Linux /dev/sdb2 3648 9461 46700955 83 Linux /dev/sdb3 9462 9729 2152710 82 Linux swap / Solaris df -h Filesystem Size Used Avail Use% Mounted on /dev/sdb1 28G 8.2G 18G 32% / /dev/sdb2 44G 21G 22G 49% /buildarea
Looking what HW we have on my build and evaluation machine
I use a single HW for Chromium OS building and evaluation Used $250 HW for compiling and evaluation of Chromium OS – on Single Machine, so here is some information about this HW from Ubuntu:
October 13, 2010
I was hoping to run it directly on ESXi 4.1. I’m sure I can start with any VM format that works and convert it with vCenter Converter as needed.
I was preparing some OpenSolaris JeOS based images for variety of formats including ESX 3.5 so here is my 2 cents:
First issue (if I remember it correctly and is still valid for ESX4.x). ESX don’t support IDE based disks as VM storage and virtual ide controller is only used for CD, so I think then main issue here will be then vCenter Converter will convert disk to SCSI type, but Chromium OS don’t have needed SCSI driver (drivers are reduced to get smaller and faster images).
Second issue can be change in changed CHS mapping, I saw past sometimes during IDE – SCSI conversion changes in CHS geometry so some Linux VMware player images with GRUB legacy don’t boot after conversion due this.
Yes, true is Chromium OS use as legacy loader Syslinux 3.x and GPT which protective partition by definition ignore CHS (and partition boot flag), but on some BIOSes this combination make strange thinks from simple not booting to even system just hang right after you plug drive in !
Here is all needed VMware drivers in Linux(Gentoo) Gentoo VMware Guest
VMware LSILOGIC need Fusion MPT driver in Linux
I see in todays default Chronium X86 kernel
“CONFIG_FUSION is not set”
See Linux kernel fusion
So there is SCSI disks support needed by USB disks anyway, but not needed LSI driver.
Trick is then Chromium OS today don’t use initrd, all drivers need to be in kernel so kernel size is limited by amount of included drivers, may be this is design decision because Chrome OS is to be produced per “device” ?
It can be easily tested in Desktop products when LSI (FUSION) driver is included:
1. Start original ide image in VMware Workstation in IDE mode, check if boot OK
2. Convert disk to SCSI and move it to LSILOGIC SCSI adapter
3. Start converted SCSI image in VMware Workstation or Player
Is ESX 4.x finally supporting booting OS from IDE disks ?
Yes, IDE controler is there in ESX and you can connect Virtual CD-ROM there.
Unless is specially stated somewhere is ESX 4.x release notes as new feature, IDE disks are not supported in ESX due to poor IDE perfomance and scalability, but it can work for it.
From VMware vCenter Converter Standalone 4.0.1 Release notes:
– IDE support
— Support for vSphere 4.0 as source and destination targets:
From ESX 4.0 release notes:
An IDE hard disk added to a hardware version 7 virtual machine is defined as Hard Disk 1 even if a SCSI hard disk is already present
If you have a hardware version 7 virtual machine with a SCSI disk already attached as Hard Disk 1 and you add an IDE disk, the virtual machine alters the disk numbering. The IDE disk is defined as Hard Disk 1 and the SCSI disk is changed to Hard Disk 2.
Sou you can try change disk type on converted disk manually back to IDE, reattach it as IDE and try it.
PS: I am working on x86 Chromium OS DEMO prototype where one image can be used for various IDE disk based virtualizations and direct usb boot with GRUB2 loaded and GPT protective partition converted to comply also CHS mode.
I will use as legacy boot loader GRUB2 because in will allow better debug various issues and it has better old BIOSes compatibility.