The "intellibook" netbook contains a rtl8192se pci network chip that is not currently included in the android-x86 builds. I could not get a complete self-build image to work so I decided to add the neccessary drivers to the existing release from 20120101. This has the added benefit that the installation contains the google apps, which are not included in the source download. The image can be downloaded from http://www.android-x86.org/releases/build-20120101 (android-x86-4.0-asus_laptop-20120101.iso).
Extract the iso image and the contained squashfs image and mount the contained filesystem image as a loopback device.
$ bsdtar -C android-image -xf android-x86-4.0-asus_laptop-20120101.iso
$ cd android-image
$ unsquashfs system.sfs
$ sudo mkdir /mnt/iso
$ sudo mount ./squashfs-root/system.img /mnt/iso -o loop
In the android-x86 build the boot
folder is in a separate location so we move it from the extracted image to repack it later.
$ mkdir -p ~/Temp/boot
$ mv android-image/isolinux ~/Temp/boot
In you android-x86 build environment edit device/asus/laptop/laptop_defconfig
and apply the following patch:
diff --git a/laptop/laptop_defconfig b/laptop/laptop_defconfig
index befb89e..f8d4320 100644
--- a/laptop/laptop_defconfig
+++ b/laptop/laptop_defconfig
@@ -1242,10 +1242,12 @@ CONFIG_RT2X00_LIB_FIRMWARE=y
CONFIG_RT2X00_LIB_CRYPTO=y
CONFIG_RT2X00_LIB_LEDS=y
# CONFIG_RT2X00_DEBUG is not set
-# CONFIG_RTL8192CE is not set
-# CONFIG_RTL8192SE is not set
-# CONFIG_RTL8192CU is not set
-# CONFIG_WL is not set
+CONFIG_RTL8192CE=m
+CONFIG_RTL8192SE=m
+CONFIG_RTL8192CU=m
+CONFIG_RTLWIFI=m
+CONFIG_RTL8192C_COMMON=m
+CONFIG_WL=m
Build the image
$ make -j8 iso_img TARGET_PRODUCT=asus_laptop
Copy the kernel modules and dependency information to the mounted filesystem image.
$ sudo cp -r out/target/product/laptop/system/lib/modules/3.0.8-android-x86-asus-laptop+/kernel/drivers/net/wireless/rtlwifi /mnt/iso/lib/modules/3.0.8-android-x86-asus-laptop+/kernel/drivers/net/wireless
$ sudo cp -r out/target/product/laptop/system/lib/modules/3.0.8-android-x86-asus-laptop+/modules.* /mnt/iso/lib/modules/3.0.8-android-x86-asus-laptop+
Copy the firmware from a local Ubuntu installation.
$ sudo cp -r /lib/firmware/rtlwifi /mnt/iso/lib/firmware
Unmount the filesystem image and rebuilt the iso.
$ sudo umount /mnt/iso/
$ mksquashfs squashfs-root/system.img system.sfs
$ cd ..
$ genisoimage -vJURT -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -input-charset utf-8 -V "Android-x86 LiveCD" -o android-image.iso ~/Temp/boot/ android-image/ramdisk.img android-image/initrd.img anndroid-image/initrd.img android-image/install.img android-image/system.sfs android-image/kernel
Modify the image so it is also bootable from an USB stick.
$ isohybrid android-image.iso
Write the modified iso image to the USB stick connected to /dev/sdb
.
$ sudo dd if=android-image.iso of=/dev/sdb
CFML tags have a similar format to HTML tags. They are enclosed in angle brackets (< and >) and generally have zero or more named attributes, though some tags (e.g. cfset, cfif) contain an expression rather than attributes. Many CFML tags have bodies; that is, they have beginning and end tags with text to be processed between them. For example:
#value# Bob! Other tags, such as cfset and cfftp, never have bodies; all the required information goes between the beginning (<) character and the ending (>) character in the form of tag attributes (name/value pairs), as in the example below. If it is legal for tags not to have a body, it is syntactically acceptable to leave them unclosed as in the first example, though many CFML developers choose to self-close tags as in the second example to (arguably) make the code more legible. Even if the tag can have a body, including a body may not be necessary in some instances because the attributes specify all the required information. In these cases, as with the second example above, the end tag (and hence, the tag body) may be omitted and the tag may be self-closing as in the following example:[8] Various tags offer the ability to type-check input parameters (e.g. cffunction, cfparam, cfqueryparam) if the programmer declares their type specifically. This functionality is used with cfqueryparam to secure web applications and databases from hackers and malicious web requests such as SQL injection.Built-in tags
Nearly 100 tags and many more functions make up the heart of the CFML language. The following lists CFML tags by their function or purpose.[9]
Application framework
Communications
Control
Flow-control
Database manipulation
Exception handling
Data output
Debugging
Display management
Extensibility
File management
form
Internet protocol
Page processing
Security
Variable manipulation
Other tags (cfimage, cfregistry etc.)