"Error opening image" for raspberrypi-ua-netinst
See original GitHub issue- Etcher version: 1.4.5-1
- Operating system and architecture: Arch Linux x64
- Image flashed: raspberrypi-ua-netinst-v2.2.1.zip
- Do you see any meaningful error information in the DevTools?
{"stack":"Error: Invalid archive image\n at Object.exports.createError (/opt/Etcher/resources/app.asar/lib/shared/errors.js:253:17)\n at Object.exports.createUserError (/opt/Etcher/resources/app.asar/lib/shared/errors.js:292:18)\n at hooks.getEntries.then (/opt/Etcher/resources/app.asar/lib/sdk/image-stream/archive.js:181:20)\n at tryCatcher (/opt/Etcher/resources/app.asar/node_modules/bluebird/js/release/util.js:16:23)\n at Promise._settlePromiseFromHandler (/opt/Etcher/resources/app.asar/node_modules/bluebird/js/release/promise.js:504:31)\n at Promise._settlePromise (/opt/Etcher/resources/app.asar/node_modules/bluebird/js/release/promise.js:561:18)\n at Promise._settlePromise0 (/opt/Etcher/resources/app.asar/node_modules/bluebird/js/release/promise.js:606:10)\n at Promise._settlePromises (/opt/Etcher/resources/app.asar/node_modules/bluebird/js/release/promise.js:685:18)\n at Async._drainQueue (/opt/Etcher/resources/app.asar/node_modules/bluebird/js/release/async.js:138:16)\n at Async._drainQueues (/opt/Etcher/resources/app.asar/node_modules/bluebird/js/release/async.js:148:10)\n at Async.drainQueues (/opt/Etcher/resources/app.asar/node_modules/bluebird/js/release/async.js:17:14)\n at <anonymous>","message":"Invalid archive image","description":"The archive image should contain one and only one top image file","report":false}
Should an archive file only contain one top image file? This would seem, in the context of making it easy for users to get raspberrypi-ua-netinst onto an SD card, too much of a constraint.
Issue Analytics
- State:
- Created 5 years ago
- Comments:5 (2 by maintainers)
Top GitHub Comments
@milkmiruku The main reason I noted “for now” is because before going into that we need to recognize the images being written on a deeper level than what we do right now, but we do have plans to extend it that you can see here and here (different feature requests but they basically share the same concept of handling the post-write process)
@thundron Might there be a rational? Given you note “at least for now.”, is it worth opening an issue for a feature request?