I started a separate thread since the original thread where I found it was getting into troubleshooting a specific user's problem. For the record, I found this issue here
I have a Pogo-E02 (pink). I have successfully run ALARM and (separately) bodhi's Debian from both USB sticks and USB-attached hard disks (WDC 320GB Black).
I wanted to try out the SanDisk 32G ReadyCache SSD that was on special at Newegg (USA) in mid-December 2013 since the price and capacity were acceptable to me. So I ordered a few to test.
The back of the SSD devices I received are marked with model "SDSSDRC-032G". The SSD has a unique serial number and WWN value. There is no apparent "date code" on the SSD. I have successfully used this type/model of SSD as a Linux boot/OS drive in a NanoPC running Debian "jessie".
I checked the SSD on a Linux box using "fdisk /dev/sdb" (in my case). No partition table was reported under Linux; an "fdisk 'w' command" was required to place one on the SSD. Just to be certain the SSD was "zeroed", I "blanked" the SSD using "dd if=/dev/zero of=/dev/sdb bs=1M" "/dev/sdb" in my case...YMMV).
Next, I pulled a POGO "out of production" for testing; it was "active" using a bodhi 3.12-tld image.
I configured my local DHCP server to serve it an address different that it's previous value. Then I booted the POGO without the drive attached. POGO came up and I logged in using "root" and "ceadmin" (default POGO values for SSH).
I downloaded the Doozan file as specified on ArchLinux ARM and ran it. There were no changes needed. Then I downloaded the Arch "mke2fs" binary. Then I connected the SSD to the POGO using a USB-SATA adaptor.
I created a single partition using "fdisk" (sda1 in this case). I formatted this partition using "mke2fs" and set the disk label to "ROOTFS". I mounted "sda1" to "/tmp/usb". Then I downloaded the "bodhi tld-1 rootfs tar.bz2" file to /dev/sda1 and extracted it. I sync'd the filesystem and rebooted.
SUCCESS!!! The POGO came up on "bodhi tld-1".
I made some changes to the system to suit my own preferences and rebooted. Success.
Next I downloaded the "bodhi tld-4" image files and extracted them. I followed the instructions in bodhi's thread (make a backup of the files in "/boot" before running "dkpg -i") and then rebooted.
SUCCESS!!! The POGO came up on "bodhi tld-4".
I continued to make my own changes to the system to suit my needs.
I cannot repeat any of the issues found in the other thread regarding this SSD. Perhaps my preparation method "cleans" the device of some hidden partition? I can definitely say that this device was pulled straight from the box and then "cleaned". I never made any attempt to use the SSD as a "cache drive" on a Windows machine. Perhaps that is a difference between my experience and the experiences of others?
Many thanks to bodhi for making this image available since it has saved me many many hours of trying to figure much of this stuff myself. Perhaps one day I will master the skills of "toolchains" and "cross compile" and building my own system images from scratch.
I have a Pogo-E02 (pink). I have successfully run ALARM and (separately) bodhi's Debian from both USB sticks and USB-attached hard disks (WDC 320GB Black).
I wanted to try out the SanDisk 32G ReadyCache SSD that was on special at Newegg (USA) in mid-December 2013 since the price and capacity were acceptable to me. So I ordered a few to test.
The back of the SSD devices I received are marked with model "SDSSDRC-032G". The SSD has a unique serial number and WWN value. There is no apparent "date code" on the SSD. I have successfully used this type/model of SSD as a Linux boot/OS drive in a NanoPC running Debian "jessie".
I checked the SSD on a Linux box using "fdisk /dev/sdb" (in my case). No partition table was reported under Linux; an "fdisk 'w' command" was required to place one on the SSD. Just to be certain the SSD was "zeroed", I "blanked" the SSD using "dd if=/dev/zero of=/dev/sdb bs=1M" "/dev/sdb" in my case...YMMV).
Next, I pulled a POGO "out of production" for testing; it was "active" using a bodhi 3.12-tld image.
I configured my local DHCP server to serve it an address different that it's previous value. Then I booted the POGO without the drive attached. POGO came up and I logged in using "root" and "ceadmin" (default POGO values for SSH).
I downloaded the Doozan file as specified on ArchLinux ARM and ran it. There were no changes needed. Then I downloaded the Arch "mke2fs" binary. Then I connected the SSD to the POGO using a USB-SATA adaptor.
I created a single partition using "fdisk" (sda1 in this case). I formatted this partition using "mke2fs" and set the disk label to "ROOTFS". I mounted "sda1" to "/tmp/usb". Then I downloaded the "bodhi tld-1 rootfs tar.bz2" file to /dev/sda1 and extracted it. I sync'd the filesystem and rebooted.
SUCCESS!!! The POGO came up on "bodhi tld-1".
I made some changes to the system to suit my own preferences and rebooted. Success.
Next I downloaded the "bodhi tld-4" image files and extracted them. I followed the instructions in bodhi's thread (make a backup of the files in "/boot" before running "dkpg -i") and then rebooted.
SUCCESS!!! The POGO came up on "bodhi tld-4".
I continued to make my own changes to the system to suit my needs.
I cannot repeat any of the issues found in the other thread regarding this SSD. Perhaps my preparation method "cleans" the device of some hidden partition? I can definitely say that this device was pulled straight from the box and then "cleaned". I never made any attempt to use the SSD as a "cache drive" on a Windows machine. Perhaps that is a difference between my experience and the experiences of others?
Many thanks to bodhi for making this image available since it has saved me many many hours of trying to figure much of this stuff myself. Perhaps one day I will master the skills of "toolchains" and "cross compile" and building my own system images from scratch.