Error: (0 , h.requestMetadata) is not a function

[wegank]

• Etcher version: 1.18.13 - 1.19.3
• Operating system and architecture: NixOS, x86_64-linux
• Image flashed: Arbitrary image
• What do you think should have happened: Image selected successfully, being able to select target
• What happened: Can't select any image
• Do you see any meaningful error information in the DevTools? No, same error as above.

In Nixpkgs we package Etcher on the basis of the official deb. The procedure no longer works as of 1.18.13.

Likely a continuation of #4138. Probably that issue should be reopened? @dfunckt

[Sargeanthost]

Also having this issue on Manjaro

[devM7MD]

Like you but I'm using ArchLinux :(

[polsvoice]

I'm getting this with version 1.18.14 on Garuda.

[myxor]

Same for me on ArchLinux.

[OffsetMonkey538]

Getting this on Nobara 38

[Sargeanthost]

Was initially trying on Hyprland, which is on Wayland. I download Cinnamon to test and Xorg environment and it worked for me. I used 1.8.13. Is anyone else on Wayland?

[OffsetMonkey538]

I was on wayland

[TerrorBite]

I'm getting this issue on Manjaro with the 1.18.14 version from the AUR and I'm on X11. However, it lools like 1.18.14 released just a couple of days before #4132 was merged, meaning that the fix for #4138 wasn't included in that version. So any Arch/Manjaro issues (@Sargeanthost, @devM7MD, @myxor) should hopefully be fixed when 1.19.x lands on the AUR. Maybe I can try and manually build a 1.19 package and see if it works?

[TerrorBite]

It looks like the move to building with electron-forge causes build issues on Arch, and this is why the AUR package is still on version 1.18.

[TobiPeterG]

I have the same issue on openSUSE using the RPM and appimage

[LITUATUI]

Same problem here with EndeavourOS.

[slagathor69]

Same issue on Ubuntu 22.04 with X11 using balenaEtcher-1.19.3-x64.AppImage but no error when using balenaEtcher-1.18.11-x64.AppImage

[shunkica]

Same issue with balena-etcher-1.19.3-1.x86_64.rpm on Fedora 39

[wthubhub]

also have same issue with balena-etcher-1.19.3-1.x86_64.rpm on Fedora 39

[eternallfrost]

This issue does not occur on the appimage version of Etcher

[dualrelax]

I use archlinux ,balenaEtcher-1.18.8-x64.AppImage can use

[aethernet]

Thanks for the reports guys.
This basically means the sub-process etcher-utils could not be spawned properly (or is not yet ready).
There might be more infos in the debug console.
Can you check what it says ( Ctrl + Shift + I should open it) ?

[ClassANetwork]

Thanks for the reports guys. This basically means the sub-process etcher-utils could not be spawned properly (or is not yet ready). There might be more infos in the debug console. Can you check what it says ( Ctrl + Shift + I should open it) ?

Getting the same on Fedora 39 with version v1.19.3. Tried both RPM and AppImage formats. Same result.
-1706048290684.log

[Kaiddd]

Same on Arch on both x11 and wayland, installed with yay from aur (since people above were talking abt wayland)

AppImage works fine

[pamo22]

Thanks for the reports guys. This basically means the sub-process etcher-utils could not be spawned properly (or is not yet ready). There might be more infos in the debug console. Can you check what it says ( Ctrl + Shift + I should open it) ?

node:events:491 Uncaught Error: spawn /usr/lib/balena-etcher/generated/etcher-util ENOENT
    at __node_internal_captureLargerStackTrace (node:internal/errors:490:5)
    at __node_internal_errnoException (node:internal/errors:620:12)
    at ChildProcess._handle.onexit (node:internal/child_process:283:19)
    at onErrorNT (node:internal/child_process:476:16)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21)
(anonymous) @ gui.js:3
gui.js:3 TypeError: requestMetadata is not a function
    at gui.js:278:1759
    at SourceSelector.selectSource (gui.js:278:2719)
    at SourceSelector.openImageSelector (gui.js:278:3117)

Unfortunately console does not have much info

[JBlackCat]

OS: Fedora 39
pkg: balena-etcher-1.19.4-1.x86_64.rpm

Looking at the inspector the error is thrown in the source-selector component here... https://github.com/balena-io/etcher/blob/v1.19.4/lib/gui/app/components/source-selector/source-selector.tsx#L425

requestMetadata which is imported from app is still undefined.

https://github.com/balena-io/etcher/blob/v1.19.4/lib/gui/app/app.ts#L139-L157

Since requestMetadata is initially defined as undefined there needs to be an additional check in selectSource to know that requestMetadata has been defined. It appears the only way to know this is listening for the emitted scan event, but I didn't deep dive on a solution.

[nath1as]

still an issue on arch

[kdh8219]

Archlinux, Is this same problem?

[harperbolic]

same problem, archlinux

[Niskeletor]

Experiencing the same issue here on Manjaro and Garuda Linux with balena-etcher-2:1.18.14-1.

Just as @Kaiddd commented, I can confirm that the balenaEtcher-1.5.109-x64.AppImage version works fine on both systems.

[wasantosfi]

Same issue here on ElementaryOS and Zorin OS with balenaEtcher-1.19.5-x64.AppImage.
Confirmed that balenaEtcher-1.18.11-x64.AppImage worked on both systems.

[dmophir]

Experiencing this problem on my Dell XPS 9520 running Arch Linux. This is with balenaEtcher v1.18.14 from AUR, v1.18.12 AppImage, and v1.19.5 AppImage. Running GNOME 45.4 on Wayland with Intel GPU.

[rglidden]

I got the same error with balena-etcher-1.19.22-1.x86_84.rpm package installed on Rocky Linux 9.4. Then I downloaded the ETCHER FOR LINUX X64 (64-BIT) (ZIP) file, this one doesn't report the error and I can create a bootable USB stick successfully.

Running into the same issue with balena-etcher-1.19.22-1.x86_64.rpm on Fedora Workstation 40. Downloading the .ZIP version for Linux appears to work properly. Digging a little further:

$ diff -dur . /usr/lib/balena-etcher/
diff: ./balenaEtcher: No such file or directory
diff: /usr/lib/balena-etcher/balenaEtcher: No such file or directory
Binary files ./resources/app.asar and /usr/lib/balena-etcher/resources/app.asar differ
Binary files ./resources/etcher-util and /usr/lib/balena-etcher/resources/etcher-util differ

The balenaEtcher files are symlinks, so not surprised there are errors. Ignoring those, the etcher-util file appears to be different. Doing a really quick check of file sizes:

$ ls -l resources/etcher-util 
-rwxr-xr-x. 1 rglidden rglidden 131041590 May 30 10:42 resources/etcher-util
$ ls -l /usr/lib/balena-etcher/resources/etcher-util 
-rwxr-xr-x. 1 root root 54583696 Jul 17 09:53 /usr/lib/balena-etcher/resources/etcher-util

The etcher-util included in the RPM package is significantly smaller. Running the etcher-util directly:

$ /usr/lib/balena-etcher/resources/etcher-util 
Pkg: Error reading from file.
$ ./resources/etcher-util 
waiting for connection...
no connections or heartbeat for 10000 ms, terminating

Looks like the version of etcher-util that's getting bundled with the .RPM package is corrupted somehow. So I tried:

$ sudo cp ./resources/etcher-util /usr/lib/balena-etcher/resources/etcher-util

And now the version that was installed via RPM is working properly with the "fixed" version of etcher-util.

Not sure what's different, but I suspect something with the .rpm (and maybe .deb?) build is failing or causing corruption, where the version in the .zip file is not.

[ubuntupunk]

Same issue on AntiX running Debian 11

[volkertb]

Just encountered the same issue on Clear Linux OS, version 42210.

I ran into this error with both v1.19.21 and v1.19.22 of the AppImage. As others here have mentioned, v1.18.12 works fine on this same OS.

[rglidden]

Not sure what's different, but I suspect something with the .rpm (and maybe .deb?) build is failing or causing corruption, where the version in the .zip file is not.

I did a bunch of investigation, and found root cause of the problem, at least for the .RPM packages. By default, rpmbuild will strip executables to remove debug symbols and other unnecessary data from the executables before bundling them into the .rpm package. However, because of how etcher-util is compiled by electron, there is a bunch of necessary JavaScript code embedded in the executable that needs to be there. rpmbuild is erroneously removing the JavaScript code from this file, causing it to fail. This in turn causes the front-end to produce the Error: (0 , h.requestMetadata) is not a function message when etcher-util fails to start properly.

I submitted PR #4304 to work around the issue, at least for RPM builds. Ideally we could pass a custom .spec file into rpmbuild, but this is currently not possible. So the PR just disables the strip command by overriding it via an rpm macro.

A better solution would be to add a custom .spec file to the repo, then pass that into electron-installer-redhat via the new options.specTemplate parameter. That option has been added in electron-userland/electron-installer-redhat@ab6694f but the feature has not yet been included in the latest release (currently v3.4.0).

I haven't had a chance to look into the AppImage yet, but it could be a similar issue.

[rglidden]

I haven't had a chance to look into the AppImage yet, but it could be a similar issue.

I took a really quick look at the AppImage, which is also failing for me on Fedora Workstation 40. It looks like it's a different issue that's causing the same error message. Running the .AppImage file directly fails with the same error message. But extracting the image with ./balenaEtcher-1.19.22-x64.AppImage --appimage-extract then running the resulting ./squashfs-root/AppRun works fine. And inspecting the extracted files, it looks like the etcher-util in the AppImage is not corrupted like the one in the RPM was.

I might try to take a deeper look at it later. Sounds like a good opportunity to learn how AppImages work under the hood. :)

[rglidden]

Did a little more investigation on the AppImage. What's happening here is a bit different. In lib/gui/app/modules/api.ts there is a bit of code that tries to spawn the etcher-util program. From what I can tell, there two copies of this utility - one unprivileged that scans the source image, and a privileged one that handles writing to the target device.

In the current AppImage, spawning either of these instances fails. Digging a bit further into the code, there is this routine that tries to determine the location of the etcher-util program:

async function writerArgv(): Promise<string[]> {
	let entryPoint = await window.etcher.getEtcherUtilPath();
	// AppImages run over FUSE, so the files inside the mount point
	// can only be accessed by the user that mounted the AppImage.
	// This means we can't re-spawn Etcher as root from the same
	// mount-point, and as a workaround, we re-mount the original
	// AppImage as root.
	if (os.platform() === 'linux' && process.env.APPIMAGE && process.env.APPDIR) {
		entryPoint = entryPoint.replace(process.env.APPDIR, '');
		return [
			process.env.APPIMAGE,
			'-e',
			`require(\`\${process.env.APPDIR}${entryPoint}\`)`,
		];
	} else {
		return [entryPoint];
	}
}

This code is failing whenever it's in an AppImage. It's building up a command line that fails to execute, or at least fails to do the correct thing and start the utility. I was able to work around the first instance of this error for the unprivileged access by passing in the flag that indicates whether the child process needs to be privileged or not so that for the unprivileged helper it just returns the standard entryPoint which results in correctly running the helper from the currently mounted AppImage. This allows the GUI to properly read the source image and allows you to select the target device.

However, it still fails when it gets to actually writing to the target device, because at that point (as the comment above correctly notes) the mounted AppImage is no longer available to the root account, so it needs to spawn and mount a new copy of the AppImage.

I haven't figured out why exactly this is failing as I'm not exactly a JavaScript developer myself, and I don't fully understand what processes the -e "require(...)" portion of the arguments above. There are a lot of layers here, as the call goes through:

flowchart LR
  AppImage --> AppRun 
  AppRun --> balena-etcher
  balena-etcher --> electron 
  electron --> JavaScript

Loading

And I'm not really sure which step in the process is responsible for deciding to run etcher-util instead of running the GUI when it spawns that child process. But something in that chain is definitely failing to do the correct thing.

I'll keep poking at it, but hopefully this helps someone more familiar with the code narrow in on the issue.

[JungeWerther]

I did run into the same problem on MacOS Monterey 12.6.5 but after reloading the program, I was able to flash without issues. I had Etcher on this machine in the past, always worked, deleted it at some point, then reinstalled. For reference

[sanderjo]

no error when using balenaEtcher-1.18.11-x64.AppImage

That solved if for me on my Ubuntu 24.04.

Thanks.

[TickDracy]

Same issue on Ubuntu 22.04 with X11 using balenaEtcher-1.19.3-x64.AppImage but no error when using balenaEtcher-1.18.11-x64.AppImage

Thanks a lot. That one works as expected!

[bartola-valves]

Same issue on Sonoma 14.4.1. Restarted the app and worked ok.

[meldalinn]

Same issue on windows 1.19.21

[visualblind]

Did a little more investigation on the AppImage. What's happening here is a bit different. In lib/gui/app/modules/api.ts there is a bit of code that tries to spawn the etcher-util program. From what I can tell, there two copies of this utility - one unprivileged that scans the source image, and a privileged one that handles writing to the target device.

In the current AppImage, spawning either of these instances fails. Digging a bit further into the code, there is this routine that tries to determine the location of the etcher-util program:

async function writerArgv(): Promise<string[]> {
	let entryPoint = await window.etcher.getEtcherUtilPath();
	// AppImages run over FUSE, so the files inside the mount point
	// can only be accessed by the user that mounted the AppImage.
	// This means we can't re-spawn Etcher as root from the same
	// mount-point, and as a workaround, we re-mount the original
	// AppImage as root.
	if (os.platform() === 'linux' && process.env.APPIMAGE && process.env.APPDIR) {
		entryPoint = entryPoint.replace(process.env.APPDIR, '');
		return [
			process.env.APPIMAGE,
			'-e',
			`require(\`\${process.env.APPDIR}${entryPoint}\`)`,
		];
	} else {
		return [entryPoint];
	}
}

This code is failing whenever it's in an AppImage. It's building up a command line that fails to execute, or at least fails to do the correct thing and start the utility. I was able to work around the first instance of this error for the unprivileged access by passing in the flag that indicates whether the child process needs to be privileged or not so that for the unprivileged helper it just returns the standard entryPoint which results in correctly running the helper from the currently mounted AppImage. This allows the GUI to properly read the source image and allows you to select the target device.

However, it still fails when it gets to actually writing to the target device, because at that point (as the comment above correctly notes) the mounted AppImage is no longer available to the root account, so it needs to spawn and mount a new copy of the AppImage.

I haven't figured out why exactly this is failing as I'm not exactly a JavaScript developer myself, and I don't fully understand what processes the -e "require(...)" portion of the arguments above. There are a lot of layers here, as the call goes through:

flowchart LR
  AppImage --> AppRun 
  AppRun --> balena-etcher
  balena-etcher --> electron 
  electron --> JavaScript

Loading

And I'm not really sure which step in the process is responsible for deciding to run etcher-util instead of running the GUI when it spawns that child process. But something in that chain is definitely failing to do the correct thing.

I'll keep poking at it, but hopefully this helps someone more familiar with the code narrow in on the issue.

Thanks @rglidden 🙏. At least someone is looking deeper into this issue. I'd like ot know how you got that far but I know this is not the forum for those kind of questions.

[rglidden]

I'd like ot know how you got that far but I know this is not the forum for those kind of questions.

Well, it might help someone else troubleshoot it further, so... All I did was clone the repo, install the dev dependencies (I know enough about JavaScript that npm ci should install everything) then checked in package.json to see that npm run make will run electron-forge to build all the software.

From there, I just modified the code to add extra debug logs where needed (use CTRL-SHIFT-I to see the logs while Etcher is running), then by reading the code, a bit of trial and error, and unpacking the resulting AppImage, I narrowed in on the areas that are failing. Some of the earlier comments in this thread and others also helped a bit.

I'm confident that etcher-util is not starting when running in the AppImage. I just still don't understand what's supposed to respond to those command-line parameters to make it run. As far as I can tell, nothing processes the command-line arguments, unless there's some magic in Electron or JavaScript in general that I don't fully understand.

[QinCai-rui]

same issue here on macos 12 while trying to flash Fedora-KDE-Live-x86_64-40-1.14.iso

[QinCai-rui]

hmm weird... restarting the program helped

[akhonabhokani]

For me, simply running balenaEtcher-1.19.21 as Administrator solved the problem.

[holcus]

same issue, fedora 40, kde, wayland
installing older balena-etcher-1.18.10.x86_64.rpm works

[Peppernrino]

This has been driving me nuts as well... decided to finally dig in. :)

Debian 12
1.18.13+

Upon comparing the file changes from 1.8.12 to 1.8.13, I noticed there is a new file - lib/util/source-metadata.ts ... maybe this has something to do with it?

Other notable changes are upgrades to electron and java packages.

I am cuurently using 1.8.12 through AM with am --launcher /home/AppImages/balenaEtcher-1.18.12-x64.AppImage and that seems to be working fine for now.

[booknownick]

Unsure if this was the actual fix, but i'm on MacOS Sequoia and right clicking the application, get info and changing the read only permissions to read write for all users and drives worked for me.

[stash86]

can confirm on windows that close then re-open the app work

[thegreatyellow67]

Same error opening source on LMDE6 with balenaEtcher-1.19.21-x64.AppImage version.
I've fixed downgrading to last running version for me balenaEtcher-1.18.12-x64.AppImage. I've tried versions after 18.1.12 and same error.

[tannertechnology]

Same error opening source on 1.19.21-1.x86_64 RPM and appimage. Running OpenSUSE Tumbleweed. Closing and reopening has no effect.

The 1.18.11 appimage works fine.