SD Card Duplication Explorations

Initial Proposal:

1. Dupping requires src and dest to be data, rather than being open as running filesystem.
2. Curating -- dubbing (adding and subtracting content) is best done via IIAB, and Tim's admin console.
3. Windows laptops are the norm (age range 2005-2018), and the target platform.
4. Hard disk sizes in the 2005 time frame were 320GB (and may not have 128GB free today) -- therefore might require USB adapter for SD card (0)
5. Skill sets preclude terminal interactive solutions (preferable -- menu driven similar to raspi-config).
6. A solution we provide should run on any x86 machine (legacy and EFI loaders)
7. We should verify that dest is large enough before attempt to copy.
8. We should minify/truncate to a size that is just small enough to accommodate smallest SD automatically, (removes the expand step).
9. Our dupping solution should use gettext to adapt the menus to proper language.
10. If possible, the driving script should run on rpi headless, and with connected keyboard and monitor (but only if it does not add too much complexity).
11. If possible, the minify function should permit downgrade to 64GB and 32GB SD cards.
12. This dupping script/function should be part of the IIAB base.

Respones to Initial Proposal

1. Adam says dupping == dubbing -- same thing
2. Adam takes issue with #2, claiming that etcher.io GUI is similar to adding content -- though constitutes a separate/larger challenge with interactive-not-batch workflow/GUI questions.
3. Adam thinks most hard disks on TLC's laptops will have 128GB free space -- laptops newer than 2005
4. Adam suggests vnc from windows machine to a GUI on the rpi.
5. Adam thinks that English is suficient for current customers
6. Adam seems to really be pushing Etcher. I wonder what benefits he sees that I do not. Much of their code is written in javascript, and introduces a lot of complexity. In linux, some error checking, and a simple "dd" is all that we really need. And Etcher needs to be specially crafted for each base operating system, rather than a one size fits all (that tiny core provides)
7. Tim thinks older (2005) machines may be 32bit -- suggests that our solution should be 32bit --requires less memory also.
8. Tim asks whether script runs on rpi or windows. I was hoping that tiny core solution would run at either.
9. Tim thinks the SD copy function belongs in iiab-factory
10. Tim responds http://www.imgburn.com/ could also be a model -- my quick browse suggests that it is mostly aboout CD's and DVD's -- not much about SD's and MMC's.
11. Tim wants device to device rather than device->image->new device. I agree
12. Tim wants rpi to be a client drive. I think nfs does that, but when I google, what surfaces is Samba, which my experience says can become complicated in a hurry. see https://blogs.msdn.microsoft.com/saponsqlserver/2011/02/03/installation-configuration-of-windows-nfs-client-to-enable-windows-to-mount-a-unix-file-system/

Initial experiment -- Device to Device on RPI -- rejected

Advantages

1. OS and software already installed
2. User experience already in place, either with keyboard/monitor, or headless via ssh. Nothing new.
3. GUI simulation (similar to raspi-config) available for both #1 and #2 above
4. Requires fast USB stick for booting the OS (so that source is data -- not running OS).

Disadvantages

1. Requires SD card adapter
2. Requires correct USB stick for running OS -- not all sticks work.
3. Source SD card must be inserted into the motherboard after boot has begun, to force booting from the USB stick -- cumbersome.
4. Technology Learning Coordinator (TLC) is likely to need some time (2-7 hours) to perform the copy, and is likely to need to take the rpi home. (potential to forget at least one of the pieces (Power supply, rpi, USB stick, source SD, destination SD, SD adapter).
5. Then TLC needs to get all the pieces back the next day, and properly assembled, and tested.

Second experiment -- Tiny Core Linux on TLC's laptop

Advantages

1. Can run on both MBR and UEFI loaders, 32Bit and 64Bit machines (one size fits all)
2. Simple requirements -- Download an image, and burn it to a USB stick -- already done with rpi images.
3. Takes advantage of almost universal SD card slot on most laptops.
4. With the addition of SD to USB adapter, can accommodate device to device copying.
5. Lets the TLC, with the new image stored on her laptop, become an agent in supplying updates to neighboring schools.
6. Running on a laptop, the copy has a better chance of running to completion, if it has the energy stored in the laptop battery to take over when the power fails).

Progress is slow -- 6/19/18

1. A runaway untested script wiped out the Windows 10 on my test laptop.
2. I've learned how to create mbr/uefi dual boot sticks.
3. Need to automate the creation of sticks, because getting the right packages by hand is too error prone.
4. Initial copy rate of dd'ing onto hard disk was disappointing -- only 6.6MB/sec.
5. But rate in #4 was copying 512 byte sectors. Increasing the buffer space to 4096 yields a 20MB/sec rate (this may be close to the SD's max read speed -- class 10)
6. Functions at the main menu:
   1. Copy SD card to hard disk, or another SD card
   2. Shrink hard disk image
   3. Copy a hard disk image to SD card
   4. Delete hard disk image
   5. Exit to terminal
7. Hard disk image name includes user name, and a label field (also includes the git hash, date of copy)
8. Out of memory symptoms, not yet diagnosed
9. Main menu functions #2, #4, #4 not yet implemented.