Today I got my new Cubieboard. I installed Debian Wheezy on a 4 GB SD Card, but the Cubieboard also has built-in NAND memory. I wanted to place all the data for the webserver on the NAND memory for faster access. Everything went well except for moving the MySQL data directory.
At first, I just edited
datadir = /var/lib/mysql to
datadir = /nanda/mysql and moved the data directory to the NAND memory. MySQL wouldn’t start anymore.
The solution was pretty easy. I just had to reinitilize the MySQL databases (
mysql_install_db --user=mysql --ldata=/nanda/mysql). After that, I restarted MySQL and it worked!
In my case I had to reboot the whole system because I couldn’t access my databases trough PHP. This may be caused by the many attempts I have made to fix this problem.
The load on my Cubieboard was constantly above 1.0, which is way too much for a single core device, so I started searching for a solution. After looking in top, I saw that
usb-hardware-sc was probably the problem, because it was in D state (
I tried to kill it with signal 9 but of course that wouldn’t work. When searching for
usb-hardware-sc I saw that there were some other people who noticed this, but they didn’t have a solution.
At this point I contacted rm because I thought it may be a problem with his kernel. He told me it may be a problem with
script.bin, which controls the hardware configuration. Unfortunately I don’t have Android’s
script.bin anymore, so I continued my search before extracting it from the Android image.
Eventually I found a solution. It is pretty simple and it works! I just downloaded a clean
script.bin from Cubieboard’s hwpack, converted it to
./bin2fex script.bin script.fex) opened it with
vi, searched for
[usbc0] and replaced the whole block by the following:
usb_used = 1
usb_port_type = 0
usb_detect_type = 0
usb_drv_vbus_gpio = port:PB09<1><0><default><0>
usb_host_init_state = 0
Then I just converted it back (
./fex2bin script.fex script.bin), copied it to the boot partition (
cp script.bin /boot) and rebooted my Cubieboard. Now everything runs fine with a nice low load!
Another post about my new Cubieboard. The image I used had a fixed size of 2 GB. Because I wanted to use my whole 4 GB SD Card I had to extend my rootfs partition (in my case
When doing some research about resizing partitions on Linux I saw many posts about LVM. Of course I don’t have a LVM setup on my Cubieboard so I had to find another solution.
Eventually I found a solution for LVM and tried it for my setup.
p (remember the start sector of partition 2)
d (remove partition, choose partition 2)
n (create new partition, number 2, start sector of step 2, leave end sector as default)
w (write changes to disk and exit)
After this I had to reboot my system for the changes to take effect. The system still worked!
The partition has been extended but there was no file system on the extended space, so the usable space was still 2 GB. To create a filesystem on the extended space I executed the following command:
resize2fs /dev/mmcblk0p2. A few seconds later my rootfs was 4 GB!
I’m using rm’s kernel, but I couldn’t control my Cubieboard’s LEDs while using this kernel. If I used the stock kernel from Cubieboard’s hwpack it all worked.
First I thought it was disabled because I use the ‘server’ edition of the kernel, which is just a kernel with many disabled features a server doesn’t need to safe resources, but this wasn’t the case.
After some searching in the modules I saw that there is a module called
The only thing I had to do was to add the following code to script.bin:
leds_used = 1
leds_num = 2
leds_pin_1 = port:PH20
leds_name_1 = "green:ph20:led1"
leds_pin_2 = port:PH21
leds_name_2 = "blue:ph21:led2"
echo "leds-sunxi" >> /etc/modules to load the
leds-sunxi module on boot and reboot.
After the reboot it worked again, now with rm’s kernel. For more info about controlling the LEDs, take a look at this tutorial.