12-29-2018, 06:15 PM
Hi forum,
I guess this is more of a suggestion to the release manager for pine64 and less of a question.
While I appreciate the dd image format's simplicity, it would make a lot more sense to distribute images lest wastefully.
Part of the reason I mention that is because the dd image that is distributed has a corrupt partition table, so it can't be copied to an SD card via more efficient means.
I run into this problem regularly and I myself am a fan of a couple of methods:
1) the bash binary
https://www.linuxjournal.com/content/add...ll-scripts
This is more useful if you want to add obscurity (not security) to the images you distribute
2) a zip file, along with 2 bash scripts that implement *an API*
This method is a bit more complex.
script 1: flash.sh
usage: flash.sh [--device|-d <device>] [--tmpdir|-t <tempdir>]
device - a block device e.g. a default could be /dev/mmcblk0, exported as $DEVICE
tempdir - a temporary directory e.g. see man mktemp, exported as $TMPDIR
in turn, script 1 sources script 2, and script 2 exposes a few shell functions.
script 2: details.sh
fetch(): fetches all source files to $TMPDIR specified by script1
urls are encoded in the details.sh file
small files (e.g. patch files) can be stored in the .zip file locally
large files can be fetched from the internet
prepare(): applies patches
partitions device
resizes partitions as appropriate
a really compact and scriptable way to specify a partition layout that can fill up space to the end of the disk (so you don't need to have 8GB, 16GB, and 32GB files) is using sfdisk
https://linux.die.net/man/8/sfdisk
http://download.vikis.lt/doc/util-linux-...k.examples
flash(): could use dd, or not
a more efficient means for Pine64 would be to distribute .ext4 files or .vfat files that can be mounted as loop devices (using losetup)
3) fastboot
This is arguably the standard way of distributing Android factory images and is described in detail at the link below
https://source.android.com/setup/build/running
4) There is always yocto too.. ¯\_(ツ)_/¯
Really, there must be a better alternative than sitting here, waiting for 26 billion zeros to be written to an sd card.
Cheers,
C
I guess this is more of a suggestion to the release manager for pine64 and less of a question.
While I appreciate the dd image format's simplicity, it would make a lot more sense to distribute images lest wastefully.
Part of the reason I mention that is because the dd image that is distributed has a corrupt partition table, so it can't be copied to an SD card via more efficient means.
I run into this problem regularly and I myself am a fan of a couple of methods:
1) the bash binary
https://www.linuxjournal.com/content/add...ll-scripts
This is more useful if you want to add obscurity (not security) to the images you distribute
2) a zip file, along with 2 bash scripts that implement *an API*
This method is a bit more complex.
script 1: flash.sh
usage: flash.sh [--device|-d <device>] [--tmpdir|-t <tempdir>]
device - a block device e.g. a default could be /dev/mmcblk0, exported as $DEVICE
tempdir - a temporary directory e.g. see man mktemp, exported as $TMPDIR
in turn, script 1 sources script 2, and script 2 exposes a few shell functions.
script 2: details.sh
fetch(): fetches all source files to $TMPDIR specified by script1
urls are encoded in the details.sh file
small files (e.g. patch files) can be stored in the .zip file locally
large files can be fetched from the internet
prepare(): applies patches
partitions device
resizes partitions as appropriate
a really compact and scriptable way to specify a partition layout that can fill up space to the end of the disk (so you don't need to have 8GB, 16GB, and 32GB files) is using sfdisk
https://linux.die.net/man/8/sfdisk
http://download.vikis.lt/doc/util-linux-...k.examples
flash(): could use dd, or not
a more efficient means for Pine64 would be to distribute .ext4 files or .vfat files that can be mounted as loop devices (using losetup)
3) fastboot
This is arguably the standard way of distributing Android factory images and is described in detail at the link below
https://source.android.com/setup/build/running
4) There is always yocto too.. ¯\_(ツ)_/¯
Really, there must be a better alternative than sitting here, waiting for 26 billion zeros to be written to an sd card.
Cheers,
C