jviotti
commented
8 years ago Hi @dlech ,
Coincidentally, this is a feature we've been internally discussing (in Gitter, so not really internally after all) as part of our "Extended Archives" feature (see the WIP manifest here: https://github.com/resin-io/etcher/pull/707).
We've implemented configuration support in our Resin CLI (https://github.com/resin-io/resin-cli) already, but we're looking to extract this functionality and make it generic in Etcher.
This is what we currently have
resin-image-fs: A very handy and reliable module to perform file operations in image's FAT partitions (like move, copy, replace, etc). It currently only supports FAT, but nothing prevents us from adding support for other file systems as long as its feasible to do so in a cross-platform fashion. We should also remove the "Resin" piece of the module, as it suggests the module is Resin.io-only.- A way to define "questions" to ask the user, for example:
options: [
message: 'Processor'
name: 'processorType'
type: 'list'
choices: [ 'Z7010', 'Z7020' ]
,
message: 'Coprocessor cores'
name: 'coprocessorCore'
type: 'list'
choices: [ '16', '64' ]
]- The answers from the options presented to the user are passed to
resin-device-operations, a module used by the Resin CLI which accepts a set of configuration "commands" and executes them on an image. Check the following commands as an example:
[
command: 'copy'
from:
partition:
primary: 1
path: '/bitstreams/parallella_e16_headless_gpiose_7010.bit.bin'
to:
partition:
primary: 1
path: '/parallella.bit.bin'
when:
coprocessorCore: '16'
processorType: 'Z7010'
,
command: 'copy'
from:
partition:
primary: 1
path: '/bistreams/parallella_e16_headless_gpiose_7020.bit.bin'
to:
partition:
primary: 1
path: '/parallella.bit.bin'
when:
coprocessorCore: '16'
processorType: 'Z7020'
]The actual commands make use of resin-image-fs.
This is what we're missing
- Polishing the way options and commands are declared. We want to ditch the concept of "commands" and use a more "high-level" way of declaring what a file goes somewhere, etc; since the current approach is very imperative.
- Add support for common "schema-like" languages, like JSON, YAML, INI, etc; and allow users to define that a certain value goes in a certain "key" of a certain file. We manage the rest.
- Maybe templating support?
In any case, this is all taking shape and we don't have anything clear at the moment, but if you're interested, we're discussing a lot of this stuff in Gitter, so I suggest you to keep an eye there.
Given that you opened this issue, lets make this the home of more organized discussion about this topic.
ensonic
alexandrosm
lurch
davidferguson
konmouz
WasabiFan
shaunmulligan
Shou
By one-off, I mean changing some small thing about the image, like the hostname or a static ip address. One use case is for classrooms that may be using embedded devices and want to set them up without having to boot and log into each device (comes from here).
I'm guessing to make this work, the image file would have to have a FAT partition since that is pretty much the only partition type that works on all OSes without additional software. A simple solution might be to have the image file could have extended meta data mount this partition and open a configuration file in the OS default text editor when the image burn is finished instead of ejecting the drive. Or even better, a simple text editor built into Etcher so that Etcher can eject the drive when editing is finished.
For example, in our ev3dev OS for Raspberry Pi, users always need to edit
config.txtto select which add-on board they are using since there are multiple add-on boards and they cannot be automatically detected.