Cubical Monolith 2013 06

2013-06-29:

I mounted the power supply, one of the (3) ethernet switches and a new DC distribution board for 12VDC.

2013-06-29-001-low.jpg2013-06-29-005-low.jpg

I still have 28-more Cubie boards to install, an additional (2) ethernet switches, and most likely a bunch of muffin fans as well. I still need to disassemble it again and trim some acrylic where it broke, and reposition the powered usb hub.

2013-06-28:

I ordered (4) more Cubie boards tonight from George Ioakimedes at IO Technologies, LLC http://iotllc.com/ Their web store is https://store.iotllc.com/

I got the order in late so I might not get these as fast as the others.

I have decided to use 12vdc for the ethernet switches, I had a pair of Netgear FS116 10/100 switches that were powered with that. I have to work on a 12vdc distribution board with fuse protection now.

The second power supply I built last night has been working all day in the worst sort of heat and it looks like this one might be in better shape, albeit much larger and much louder!

I can't wait to integrate 4-more Cubie boards into the cluster.

This weekend I hope to permanently mount one of the ethernet switches and the powered usb hub, and perhaps trim some of the excess acrylic I've been meaning to cut off.

2013-06-27:

The other power supply went into thermal shutdown (even with the cover off!) about the same time so I am sitting here modifying another salvaged supply. This one is much larger and should be fine.

It has been beyond hot here in the US southwest lately. "But it's a dry heat!" sigh.

Anyway I've cut the 5VDC leads away from the wiring harness and am about to start testing the new supply. This time I think I will attempt to keep the 12vdc available for all the fans I might need.

I pulled the power supply circuit board out of it's chassis so I can unsolder all the unused leads.

2013-06-27-001-low.jpg

I hope to take my time and also do this one right the first time. That is why for this one I am going to unsolder the unused wiring instead of just clipping it back.

Earlier today node01 (1 of 3 compute nodes) went offline I don't know why yet. I power cycled it and it came back just fine.

In comparison all the tower of pi RPI units have been up for +20 days embedded in those heavy duty cases as well! No fans just thermal conduction.

Updated: 2300MT
Here is the new power supply wired in and this time I also left the 12vdc available as I have a feeling I am going to need it, if nothing else for fans but I might need it for some ethernet switches.

2013-06-27-003-low.jpg2013-06-27-004-low.jpg

The fan in the new supply is horrendously-loud. If it handles at least 32 cpus, various fans and "gizmos" I will have to deal with it.

2013-06-26:

The power supply went into thermal shutdown almost exactly the same time as yesterday (it has been very hot!) so I'm going to run it for 24 hours with the top removed. If it doesn't shut down for 24-hours I will attempt to mount a third fan on top to see if I can extract the heat that way.

I've been considering the problem of handling 32+ usb-ttl console cables. Even if I have a series of USB hubs attached to dedicated "terminal server" units I think the largest powered usb hub I could find is 16-ports and isn't powered by 5vdc. I think what I might have to do is run all the wiring to some kind of "patch panel" to allow me to select which console I want to attach to.

2013-06-25:

I finally measured the current output, right now with (4) cubie boards, (1) OCZ SSD, a powered USB hub: 2.5A

Updated: 1912MT My spiffy "new" repurposed supply is going into thermal shutdown it seems. It keeps powering down. It just started about an hour ago but it was very hot here inside today.

It was on continuously for 2 days without an issue so I'm not sure. I have a theory that an open slot along the side was causing the "pusher/puller" fan arrangement to not pull air through the supply properly so I sealed that temporarily with a piece of tape.

I really regret throwing a bunch of "useless" computer power supplies away recently.

2013-06-25-001-low.jpg

Updated: 2231MT I've been thinking about how to get all these ttl serial consoles hooked up to one interface so that I could select which host serial console I can access. It's either that or devise some kind of multiplexed physically-switched matrix with a lot of cabling. I was examining how to connect the standard usb serial cable with the boards stacked so closely and it's not going to be easy. I'd want to be able to select up to 64 inputs (host consoles).

2013-06-23: The soul of my new machine.

I had the time today to rework a discarded pc power supply that had 5vdc@19A so I spent quite a few hours getting this right the first time. I clipped back the 12vdc and 3.3vdc voltages and wrapped the stubs in heat shrink inside the case. I am not sure I have the 5vdc sensing line connected right, I have to research that more. I combined all the 5VDC lines into a larger 10ga cable as well as all the ground wiring. I will be pulling about 16A when all is completed so 10ga is appropriate.

I ran the power up line (must ground this to turn on the supply) out to a plain old-fashioned toggle switch. How retro!

2013-06-23-002-low.jpg2013-06-23-012-low.jpg2013-06-23-015-low.jpg2013-06-23-016-low.jpg2013-06-23-020-low.jpg2013-06-23-022-low.jpg

I re-worked all the Cubieboard power wiring and also wired the usb hub into a separate power feed so it has full access to 5A as needed. If this repurposed power supply holds up, it will handle at least 32 cubie boards. I need to investigate sequenced power up which will probably mean time delay relays or some nonsense like that. As you can see I have 3 of 4 cpus connected to ethernet now I was testing the difference in latency vs wifi just to trouble an MPI performance issue I am seeing.

Cubieboard vs Raspberry Pi (Cubie running 1ghz Raspberry 900mhz)

mpi@master:~$ sysbench --test=cpu --cpu-max-prime=20000 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing CPU performance benchmark

Threads started!

Done.

Maximum prime number checked in CPU test: 20000

Test execution summary:
    total time:                          657.6808s
    total number of events:              10000
    total time taken by event execution: 657.6616
    per-request statistics:
         min:                                 65.39ms
         avg:                                 65.77ms
         max:                                 87.69ms
         approx.  95 percentile:              65.69ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   657.6616/0.00

mpi@master:~$
mpi@master:~$
mpi@master:~$

pi@node01 ~ $ sysbench --test=cpu --cpu-max-prime=20000 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing CPU performance benchmark

Threads started!

Done.

Maximum prime number checked in CPU test: 20000

Test execution summary:
    total time:                          1863.3323s
    total number of events:              10000
    total time taken by event execution: 1863.2702
    per-request statistics:
         min:                                100.99ms
         avg:                                186.33ms
         max:                                357.04ms
         approx.  95 percentile:             214.29ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   1863.2702/0.00

2013-06-22 The birth of the "Cubical Monolith"

I had some time today to work on the new system. I am still working on the rack design so I can fit as many cubie boards as possible into the physical space. I won't remove the protective coating from the acrylic panels until the project is near completion. I will have to disassemble and reassemble the rack a few times to fix problems with the design.

2013-06-22-003-low.jpg 2013-06-22-010-low.jpg
I completed most of the outer structure today. I will have to disassemble everything several times to trim extra acrylic where marked and drill out the rivets which was an experiment that didn't go as well as I'd hoped. I need to get different rivets and try again.

Right now the control node and it's ssd disk are being powered from the Tower of Pi power supply and fed from the power distribution panel off a 5A fuse. The other three compute nodes are being powered from the usb hub shown above. I have to attach the new unit's power supply shortly but I am still missing some AC chassis-mount components (power receptacle and a fuse/circuit breaker) before I can complete that.

Right now the three compute nodes are using wifi dongles and the master control node (and nfs server) is hardwired into the Tower of Pi ethernet switch. This will have to suffice until I can get some more gig-e switches that are powered by 5vdc.

2013-06-21

Here are some images of what the latest prototype looks like. I hope to build this into a 32-node parallel compute cluster.

This is a fully-functioning cluster now, the master node is running john the ripper on (3) nodes, mpi is set up and fully integrated into my compute node image and all the ancillary stuff like python, etc is working well. I have to use wifi on the compute nodes for now until I can get more ethernet switches integrated into the rack frame.

mpi@master:/master/tmp/john/john-1.7.9-jumbo-7/run$ sh cluster-status.txt
+ mpirun -n 3 -f /master/mpi_tests/machinefile ./john --status=john
  0: guesses: 0 time: 0:10:49:57 0.00% (2) c/s: 10.34
  2: guesses: 0 time: 0:10:49:57 0.00% (2) c/s: 10.38
  1: guesses: 0 time: 0:10:49:58 0.00% (2) c/s: 10.35
SUM: guesses: 0 time: 0:10:49:59 0.00% (2) c/s: 31.08 avg10.36
+ mpirun -np 3 -f /master/mpi_tests/machinefile /master/mpi_tests/system
Fri Jun 21 09:35:01 MDT 2013 node02 09:35:01 up 11:35, 1 user, load average: 1.00, 1.01, 1.05
Fri Jun 21 09:35:01 MDT 2013 node01 09:35:01 up 11:35, 1 user, load average: 1.07, 1.05, 1.05
Fri Jun 21 09:35:04 MDT 2013 node03 09:35:04 up 11:01, 1 user, load average: 1.00, 1.03, 1.05

mpi@master:/master/mpi_tests$ ./stress
+ mpirun -np 3 -f ./machinefile ./system
Fri Jun 21 09:38:06 MDT 2013 node01 09:38:06 up 11:38, 1 user, load average: 1.00, 1.03, 1.05
Fri Jun 21 09:38:06 MDT 2013 node03 09:38:06 up 11:04, 1 user, load average: 2.87, 1.92, 1.39
Fri Jun 21 09:38:06 MDT 2013 node02 09:38:06 up 11:39, 1 user, load average: 1.06, 1.03, 1.05
+ mpirun -np 3 -f ./machinefile ./cpi
Process 3 of 3 is on node03
Process 2 of 3 is on node02
Process 1 of 3 is on node01
pi is approximately 3.1415926544231318, Error is 0.0000000008333387
wall clock time = 0.063348
+ mpirun -f machinefile python helloworld.py
Hello, World! I am process 1 of 1 on node02.
Hello, World! I am process 1 of 1 on node03.
Hello, World! I am process 1 of 1 on node01.
+ set +x
+ mpirun -np 3 -f ./machinefile ./system
Fri Jun 21 09:38:09 MDT 2013 node03 09:38:09 up 11:04, 1 user, load average: 2.87, 1.92, 1.39
Fri Jun 21 09:38:09 MDT 2013 node02 09:38:09 up 11:39, 1 user, load average: 1.06, 1.03, 1.05
Fri Jun 21 09:38:09 MDT 2013 node01 09:38:09 up 11:39, 1 user, load average: 1.00, 1.03, 1.05
+ mpirun -np 3 -f ./machinefile ./cpi
Process 2 of 3 is on node02
Process 3 of 3 is on node03
Process 1 of 3 is on node01
^CCtrl-C caught... cleaning up processes
2013-06-21-001-low.jpg 2013-06-21-005-low.jpg 2013-06-21-012-low.jpg 2013-06-21-014-low.jpg 2013-06-21-010-pdu.jpg 2013-06-21-021-low.jpg 2013-06-21-010-low.jpg

2013-06-19

Updated: A note on shrinking filesystems. I've been looking into it quite a lot ever since my attempts at making all the requisite changes with loopback images failed.

root@tester:/master/tmp# dd if=4gb-1gb-cubie-node.img of=/dev/sdc bs=1M count=3781

3781+0 records in
3781+0 records out
3964665856 bytes (4.0 GB) copied, 2859.5 s, 1.4 MB/s
root@tester:/master/tmp#

root@tester:/master/tmp# e2fsck -f /dev/sdc2
e2fsck 1.42.5 (29-Jul-2012)
The filesystem size (according to the superblock) is 953793 blocks
The physical size of the device is 951680 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? yes
root@tester:/master/tmp#
root@tester:/master/tmp# resize2fs -M -f /dev/sdc2
resize2fs 1.42.5 (29-Jul-2012)
Resizing the filesystem on /dev/sdc2 to 214045 (4k) blocks.
(this step takes quite awhile, but you can see the card reader very busy resizing the filesystem)
The filesystem on /dev/sdc2 is now 214045 blocks long.
root@tester:/master/tmp# blockdev --rereadpt /dev/sdc
root@tester:/master/tmp# sync
root@tester:/master/tmp# e2fsck -f /dev/sdc2
e2fsck 1.42.5 (29-Jul-2012)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
root: 32289/54880 files (1.3% non-contiguous), 207185/214045 blocks
root@tester:/master/tmp#

I've been too busy to work on anything but I was examining the sound hardware on a cubie (I have 5 of them now!) I forgot to mention how quickly IO Technologies, Inc. ships packages. They get here rapidly (this is the second order where this has been the case) so yes, I am complimenting them. I'm not being induced to say that either. I'm going to keep buying at least another 20 units from them.

Let there be audio

You have to install "alsa alsa-utils" and then you can usually install some audio applications. I have to locate some more low profile 2.5mm cables the clearance between the headphone jack and the line in is so narrow.

root@tester:~# alsactl init
Found hardware: "sun4i-CODEC" "codec Mixer" "" "" ""
Hardware is initialized using a generic method
root@tester:~# aplay -D hw:0,0 /usr/share/sounds/alsa/Front_Center.wav
Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
root@tester:~#
root@tester:~# cat /proc/asound/cards
 0 [sun4icodec     ]: sun4i-CODEC - sun4i-CODEC
                      sun4i-CODEC  Audio Codec
 1 [sun4isndhdmi   ]: sun4i-sndhdmi - sun4i-sndhdmi
                      sun4i-sndhdmi

I was not able to get mpg123 working, but I did get mpg321 working. I guess this is where we part company oh venerable mpg123, at least for now.

I have built and tested and configured (2) cubie boards so far and I stopped to get the sound working so I could test how well the audio hardware works. I'm only using analog audio at the moment I don't have anything capable of hdmi audio here.

I've never used X on the Cubie, it's something I might have to try soon just so I can take a look at some of it's performance using the GPU and perhaps looking at frame rates for some sort of multimedia applications.

Right now I'm more interested in building a parallel computing cluster based around the Cubie board.

I'm pretty sure I won't be using SATA o any of the compute nodes. I've built an image for the compute nodes and I am continuing to refine that as well.

I'm very pleased I got audio working on the new "master" node it seems the cubie board has decent audio hardware I just need to study it later.

I've got 2 of the 3-new systems up and running but I'm running out of time tonight to finish.

2013-06-14

I ordered (3) more cubie board systems from George Ioakimedes at IO Technologies, LLC http://iotllc.com/ Their web store is https://store.iotllc.com/

He's got these cool acrylic plates available now, I ordered a couple to see if they will fit into my next project design.

cubieboard_case1_1024x1024.jpg

I need a way to mount a lot of these units into a very small space yet provide the best ventilation possible to keep them running cool.

I am working on a few drawings now when I've finalized my plans I will publish them here.

The usb problem I mentioned earlier was on an image that had a problem, when I reverted to an older kernel it was gone.

If I ever have any spare time I will have to build a cross-compiler environment for the ARM but right now most people like me just would be happy with working 1GB images.

I have a few and if you were in my shoes I'll get you an image but I can't afford to host a lot of bandwidth so I'm not going to post one. I also need to learn how to physically shrink the file down to a much smaller file after re-sizing the filesystem. I think I will have to zap some things with parted, and add up every byte then perform a dd with precision.

I wish I had the time to do all that right now.

Feel free to contact me as my mail is the same as this site name of course. Just replace the initial dot.

I will help you obtain a usable image and you can go from there. Right now on the net you can find images with non-working usb, no nfs-kernel support but samba, a completely full disk partition (how lame is that?), and one only supporting 512M on the 1GB Cubie.

If you have any questions about anything I'll try to help as well but I'm still learning a lot about the systems and I'm using them as I'm learning so I've been able to utilize them right now. I have one system that's been on 24x7 for almost 2-months and the second about a month without any issues.

It's getting very hot nowadays and the units are holding up well so far.

2013-06-13

I'm seeing some issues with the sata controller or the ssd disk. The ssd disk is an OCZ Vertex 2 series 100gb on a very short cable with a good power supply (separate but same ground) as the Cubieboard… It only seems to happen under heavy IO and doesn't appear to be fatal as the disk operation succeeds without issue.

I was writing an image from ssd to the usb micro sd card using 1M block sizes when the below happened.

Yes, I was doing this on the serial console. The image was fine as well as I booted it right afterwards…

root@master:/master/tmp# dd if=cubie-1GB-debian-2gb.img of=/dev/sdc bs=1M
<3>ata1.00: exception Emask 0x10 SAct 0x1 SErr 0x280100 action 0x6 frozen
[  187.310000] ata1.00: exception Emask 0x10 SAct 0x1 SErr 0x280100 action 0x6 n
<3>ata1.00: irq_stat 0x08000000, interface fatal error
[  187.320000] ata1.00: irq_stat 0x08000000, interface fatal error
<3>ata1: SError: { UnrecovData 10B8B BadCRC }
[  187.330000] ata1: SError: { UnrecovData 10B8B BadCRC }
<3>ata1.00: failed command: READ FPDMA QUEUED
[  187.340000] ata1.00: failed command: READ FPDMA QUEUED
<3>ata1.00: cmd 60/00:00:00:af:0c/01:00:03:00:00/40 tag 0 ncq 131072 in
         res 50/00:00:00:af:0c/00:00:03:00:00/40 Emask 0x10 (ATA bus error)
[  187.350000] ata1.00: cmd 60/00:00:00:af:0c/01:00:03:00:00/40 tag 0 ncq 13107n
[  187.350000]          res 50/00:00:00:af:0c/00:00:03:00:00/40 Emask 0x10 (ATA)
<3>ata1.00: status: { DRDY }
[  187.360000] ata1.00: status: { DRDY }
<6>ata1: hard resetting link
[  187.370000] ata1: hard resetting link
<6>ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[  187.720000] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
<6>ata1.00: configured for UDMA/133
[  187.750000] ata1.00: configured for UDMA/133
<6>ata1: EH complete
[  187.750000] ata1: EH complete
<3>ata1.00: exception Emask 0x0 SAct 0x7 SErr 0x0 action 0x6 frozen
[  288.040000] ata1.00: exception Emask 0x0 SAct 0x7 SErr 0x0 action 0x6 frozen
<3>ata1.00: failed command: READ FPDMA QUEUED
[  288.050000] ata1.00: failed command: READ FPDMA QUEUED
<3>ata1.00: cmd 60/00:00:00:0b:19/01:00:03:00:00/40 tag 0 ncq 131072 in
         res 40/00:00:00:af:0c/00:00:03:00:00/40 Emask 0x4 (timeout)
[  288.060000] ata1.00: cmd 60/00:00:00:0b:19/01:00:03:00:00/40 tag 0 ncq 13107n
[  288.060000]          res 40/00:00:00:af:0c/00:00:03:00:00/40 Emask 0x4 (time)
<3>ata1.00: status: { DRDY }
[  288.070000] ata1.00: status: { DRDY }
<3>ata1.00: failed command: READ FPDMA QUEUED
[  288.080000] ata1.00: failed command: READ FPDMA QUEUED
<3>ata1.00: cmd 60/00:08:00:0a:19/01:00:03:00:00/40 tag 1 ncq 131072 in
         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[  288.090000] ata1.00: cmd 60/00:08:00:0a:19/01:00:03:00:00/40 tag 1 ncq 13107n
[  288.090000]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (time)
<3>ata1.00: status: { DRDY }
[  288.100000] ata1.00: status: { DRDY }
<3>ata1.00: failed command: WRITE FPDMA QUEUED
[  288.100000] ata1.00: failed command: WRITE FPDMA QUEUED
<3>ata1.00: cmd 61/10:10:28:09:c4/00:00:05:00:00/40 tag 2 ncq 8192 out
         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[  288.110000] ata1.00: cmd 61/10:10:28:09:c4/00:00:05:00:00/40 tag 2 ncq 8192 t
[  288.110000]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (time)
<3>ata1.00: status: { DRDY }
[  288.120000] ata1.00: status: { DRDY }
<6>ata1: hard resetting link
[  288.130000] ata1: hard resetting link
<6>ata1: SATA link down (SStatus 0 SControl 300)
[  288.480000] ata1: SATA link down (SStatus 0 SControl 300)
<6>ata1: hard resetting link
[  288.550000] ata1: hard resetting link
<6>ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[  288.900000] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
<6>ata1.00: configured for UDMA/133
[  288.920000] ata1.00: configured for UDMA/133
<4>ata1.00: device reported invalid CHS sector 0
[  288.930000] ata1.00: device reported invalid CHS sector 0
<4>ata1.00: device reported invalid CHS sector 0
[  288.940000] ata1.00: device reported invalid CHS sector 0
<6>ata1: EH complete
[  288.950000] ata1: EH complete
<3>ata1.00: exception Emask 0x12 SAct 0x2 SErr 0x800500 action 0x6 frozen
[  289.120000] ata1.00: exception Emask 0x12 SAct 0x2 SErr 0x800500 action 0x6 n
<3>ata1.00: irq_stat 0x08000000, interface fatal error
[  289.130000] ata1.00: irq_stat 0x08000000, interface fatal error
<3>ata1: SError: { UnrecovData Proto LinkSeq }
[  289.140000] ata1: SError: { UnrecovData Proto LinkSeq }
<3>ata1.00: failed command: READ FPDMA QUEUED
[  289.140000] ata1.00: failed command: READ FPDMA QUEUED
<3>ata1.00: cmd 60/00:08:00:52:19/01:00:03:00:00/40 tag 1 ncq 131072 in
         res 50/00:08:00:52:19/00:00:03:00:00/40 Emask 0x12 (ATA bus error)
[  289.150000] ata1.00: cmd 60/00:08:00:52:19/01:00:03:00:00/40 tag 1 ncq 13107n
[  289.150000]          res 50/00:08:00:52:19/00:00:03:00:00/40 Emask 0x12 (ATA)
<3>ata1.00: status: { DRDY }
[  289.160000] ata1.00: status: { DRDY }
<6>ata1: hard resetting link
[  289.170000] ata1: hard resetting link
<6>ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[  289.640000] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
<6>ata1.00: configured for UDMA/133
[  289.660000] ata1.00: configured for UDMA/133
<6>ata1: EH complete
[  289.670000] ata1: EH complete

2013-06-12

I finally had some time to work on making the right image with 1GB kernel support.

I also noticed my sd card reader suddenly won't detect if there is any media on the original cubie it always worked fine on. I think I need to examine the procedure to nuke old devices and recreate them as I think udev went bonkers on me. I know the sd reader is working as it is recognized and works normally on 2 laptops plus an Raspberry Pi unit I use for testing. I'm not sure what the heck yet.
ETA It is the new kernel of course. I am not sure what happened yet. I know since I booted the test system on various images I'd saved and sure enough the sd reader is fine. I'm going to assume it's something broken with udev until I know otherwise. I've had no time to investigate it as my real job is taking all my time.

2013-06-11

I finally received the card reader and I quickly built a CubieBoard 1GB image that worked well on the second Cubie board. I had an issue with the original image it was too large even to write to a 4GB micro sd card so I was able to resolve that.

First, I wrote the image onto an 8gb card. Once I confirmed it booted and appeared to be intact I performed an e2fsck on it (/dev/sdc) and then I used the "Raspberry Pi" methodology to expand the card out to 8gb.

Yes, you may use this method to expand any size card of course, just plug in the values derived from the parted operation below.

root@master:/master/tmp# parted /dev/sdc -ms unit s p| grep "^2" | cut -f 2 -d:
133120s

The output from the script above is what you'll use for fdisk input below:

root@master:/master/tmp# fdisk /dev/sdc <<EOF
p
d
2
n
p
2
133120s
^M
w
EOF

Reboot immediately then after booting also immediately issue:

root@master:/var/tmp# resize2fs /dev/mmcblk0p2

2013-06-08

I built a "sled" today for the second Cubie board and an SSD drive.

2013-06-10-001-small.jpg

I am waiting on parts to finish wiring up the power supply using a fuse protection board to protect the equipment. I also need an chassis-mount AC power socket, and the circuit breaker/fuse parts.

I mounted the Cubie board and then have begun to mount an SSD. I was busy testing 3 new SSD disks on it tonight so I didn't mount one in yet. I guess I will use one of the OCZ SSD since the Corsair has a handy usb 2.0 interface but only works under windows (in usb mode) and it might be handy to keep in my laptop bag.

I'll take a picture of this later perhaps. I still haven't finalized the design of the new system I am building but one component of it will be this sled with the Cubie and an SSD mounted running Debian: Linux tester 3.4.29-20130407.1341-rm1+ #34 Sun Apr 7 19:56:56 YEKT 2013 armv7l GNU/Linux

So far I have tested (2) brands/models of SSD with the Cubie SATA interface:

  • Corsair R120 120gb
  • OCZ Vertex 2 100gb

So far they are working flawlessly

The parameters for the mkfs procedure are optimized for SSD.

root@tester:~# fdisk /dev/sda
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklab                                             el
Building a new DOS disklabel with disk identifier 0x0b6dfd55.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): pr

Disk /dev/sda: 100.0 GB, 100030242816 bytes
255 heads, 63 sectors/track, 12161 cylinders, total 195371568 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0b6dfd55

   Device Boot      Start         End      Blocks   Id  System

Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p):
Using default response p
Partition number (1-4, default 1):
Using default value 1
First sector (2048-195371567, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-195371567, default 195371567):
Using default value 195371567

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
root@tester:~# mkfs.ext4 -O extent -b 4096 -E stride=128,stripe-width=128 /dev/sda1
mke2fs 1.42.5 (29-Jul-2012)
Discarding device blocks: done
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=128 blocks, Stripe width=128 blocks
6111232 inodes, 24421190 blocks
1221059 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
746 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

root@tester:~# mount /dev/sda1 /mnt
root@tester:~# df
Filesystem     1K-blocks   Used Available Use% Mounted on
rootfs           1634524 485276   1066252  32% /
/dev/root        1634524 485276   1066252  32% /
devtmpfs          256580      0    256580   0% /dev
tmpfs              51336    172     51164   1% /run
tmpfs               5120      0      5120   0% /run/lock
tmpfs             102660      0    102660   0% /run/shm
/dev/mmcblk0p1     62370  12150     50220  20% /boot
none              131072      0    131072   0% /var/tmp
none              131072      0    131072   0% /tmp
/dev/sda1       96150564 192176  91074152   1% /mnt
root@tester:~#

2013-06-07

I hope to get the sd card reader this weekend (pick it up from the Post Office) so maybe I will be able to get a working 1gb image. Otherwise I cannot as none of the loopback methods I devised seem to be working OR writing the image isn't working correctly on windows.