Etcher: Error parsing Info.plist at launch

[jspencer]

• Etcher version: v1.0.0-beta.18
• Operating system and architecture: macOS 10.12.3 Beta (16D30a)

The following error appears at launch:

Error: 2017-01-17 09:27:25.354 diskutil[12682:4102330] There was an error parsing the Info.plist for the bundle at URL <0x7fb6d4c09800>: NSCocoaErrorDomain - 3840
2017-01-17 09:27:25.508 diskutil[12719:4102412] There was an error parsing the Info.plist for the bundle at URL <0x7fb0781010b0>: NSCocoaErrorDomain - 3840
2017-01-17 09:27:25.683 diskutil[12758:4102505] There was an error parsing the Info.plist for the bundle at URL <0x7fb9d4c037c0>: NSCocoaErrorDomain - 3840
2017-01-17 09:27:25.806 diskutil[12799:4102581] There was an error parsing the Info.plist for the bundle at URL <0x7fa011413e60>: NSCocoaErrorDomain - 3840
2017-01-17 09:27:25.928 diskutil[12836:4102642] There was an error parsing the Info.plist for the bundle at URL <0x7ff683c033b0>: NSCocoaErrorDomain - 3840

    at childProcess.execFile (/Applications/Etcher.app/Contents/Resources/app.asar/node_modules/drivelist/lib/scripts.js:90:23)
    at ChildProcess.exithandler (child_process.js:209:7)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:191:7)
    at maybeClose (internal/child_process.js:877:16)
    at Socket.<anonymous> (internal/child_process.js:334:11)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:188:7)
    at Pipe._handle.close [as _onclose] (net.js:493:12)

I'd be happy to help debug the problem. I'm not sure if it's related to the beta OS I am running.

[jviotti]

Thanks a lot for reporting this! Can you try running the following bash script in your system and report back what you get? https://github.com/resin-io-modules/drivelist/blob/master/scripts/darwin.sh

[jspencer]

Sure thing. Here's the output.

Silicates:~ jspencer$ ./darwin.sh 
2017-01-17 13:31:17.517 diskutil[30629:5253210] There was an error parsing the Info.plist for the bundle at URL <0x7f89fdf04c10>: NSCocoaErrorDomain - 3840
device: /dev/disk0
description: "APPLE SSD SM1024L"
size: 1000555581440
mountpoints: []
raw: /dev/rdisk0
protected: False
system: True

2017-01-17 13:31:17.642 diskutil[30666:5253269] There was an error parsing the Info.plist for the bundle at URL <0x7fdde4600720>: NSCocoaErrorDomain - 3840
device: /dev/disk1
description: "Macintosh HD"
size: 862999998464
mountpoints:
  - path: /
raw: /dev/rdisk1
protected: False
system: True

2017-01-17 13:31:17.813 diskutil[30705:5253336] There was an error parsing the Info.plist for the bundle at URL <0x7fc8d66014f0>: NSCocoaErrorDomain - 3840
device: /dev/disk2
description: "FA GoFlex Desk"
size: 2000398933504
mountpoints:
  - path: /Volumes/Fulminate
raw: /dev/rdisk2
protected: False
system: False

2017-01-17 13:31:17.942 diskutil[30746:5253397] There was an error parsing the Info.plist for the bundle at URL <0x7fa0ce718d60>: NSCocoaErrorDomain - 3840
device: /dev/disk3
description: "Flash Reader"
size: 7948206080
mountpoints:
  - path: /Volumes/BOOT
raw: /dev/rdisk3
protected: False
system: False

[lurch]

There's only a few google-results for this, which would seem to suggest it's a very rare problem https://www.google.co.uk/search?q=%22There+was+an+error+parsing+the+Info.plist+for+the+bundle+at+URL%22
And the results that I did read suggest it might be caused by corruption? It looks like your diskutil might be corrupted, so maybe you need to reinstall your beta OS? *shrug*

[jspencer]

That google result doesn't look related to me. I imagine there are many reasons for a plist to be mis-parsed.

[jspencer]

here's my diskutil plist if it helps. (I happen to have fewer disks mounted than in the above output)

Silicates:~ jspencer$ diskutil list -plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>AllDisks</key>
    <array>
        <string>disk0</string>
        <string>disk0s1</string>
        <string>disk0s2</string>
        <string>disk0s3</string>
        <string>disk0s4</string>
        <string>disk1</string>
    </array>
    <key>AllDisksAndPartitions</key>
    <array>
        <dict>
            <key>Content</key>
            <string>GUID_partition_scheme</string>
            <key>DeviceIdentifier</key>
            <string>disk0</string>
            <key>Partitions</key>
            <array>
                <dict>
                    <key>Content</key>
                    <string>EFI</string>
                    <key>DeviceIdentifier</key>
                    <string>disk0s1</string>
                    <key>DiskUUID</key>
                    <string>666FFEE1-D842-42AE-8151-CD81FB8F43AB</string>
                    <key>Size</key>
                    <integer>314572800</integer>
                    <key>VolumeName</key>
                    <string>EFI</string>
                    <key>VolumeUUID</key>
                    <string>E783267B-A4C3-3556-B751-DBED770EB996</string>
                </dict>
                <dict>
                    <key>Content</key>
                    <string>Apple_CoreStorage</string>
                    <key>DeviceIdentifier</key>
                    <string>disk0s2</string>
                    <key>DiskUUID</key>
                    <string>A108D4A2-6BEB-42E8-B027-0E2BE7D69DEC</string>
                    <key>Size</key>
                    <integer>863356751872</integer>
                </dict>
                <dict>
                    <key>Content</key>
                    <string>Apple_Boot</string>
                    <key>DeviceIdentifier</key>
                    <string>disk0s3</string>
                    <key>DiskUUID</key>
                    <string>E5AA547A-29BE-432B-BF47-6EC7CF8EDB58</string>
                    <key>Size</key>
                    <integer>650002432</integer>
                    <key>VolumeName</key>
                    <string>Recovery HD</string>
                    <key>VolumeUUID</key>
                    <string>79DB13DE-63DA-3260-99ED-C38931ED89E7</string>
                </dict>
                <dict>
                    <key>Content</key>
                    <string>Microsoft Basic Data</string>
                    <key>DeviceIdentifier</key>
                    <string>disk0s4</string>
                    <key>DiskUUID</key>
                    <string>F47F9FDC-A09C-4DE7-BCC7-E8C8AF97E01C</string>
                    <key>Size</key>
                    <integer>128233504768</integer>
                    <key>VolumeName</key>
                    <string>BOOTCAMP</string>
                    <key>VolumeUUID</key>
                    <string>A3309520-C8B7-43E7-B03B-BC2804CD04BB</string>
                </dict>
            </array>
            <key>Size</key>
            <integer>1000555581440</integer>
        </dict>
        <dict>
            <key>Content</key>
            <string>Apple_HFS</string>
            <key>DeviceIdentifier</key>
            <string>disk1</string>
            <key>MountPoint</key>
            <string>/</string>
            <key>Size</key>
            <integer>862999998464</integer>
            <key>VolumeName</key>
            <string>Macintosh HD</string>
        </dict>
    </array>
    <key>VolumesFromDisks</key>
    <array>
        <string>Macintosh HD</string>
    </array>
    <key>WholeDisks</key>
    <array>
        <string>disk0</string>
        <string>disk1</string>
    </array>
</dict>
</plist>

[jspencer]

Oh I see what you are saying, the error is coming from the OS itself (well, diskutil). Maybe you can work around the problem? It seems like maybe the required details are still output? Or you could switch to the plist output of diskutil rather than the human readable output.

Silicates:~ jspencer$ diskutil info /dev/disk0
   Device Identifier:        disk0
   Device Node:              /dev/disk0
   Whole:                    Yes
   Part of Whole:            disk0
   Device / Media Name:      APPLE SSD SM1024L

2017-01-17 16:08:57.159 diskutil[39833:5461441] There was an error parsing the Info.plist for the bundle at URL <0x7fc7a8403470>: NSCocoaErrorDomain - 3840
   Volume Name:              Not applicable (no file system)
   Mounted:                  Not applicable (no file system)
   File System:              None

   Content (IOContent):      GUID_partition_scheme
   OS Can Be Installed:      No
   Media Type:               Generic
   Protocol:                 PCI-Express
   SMART Status:             Not Supported

   Disk Size:                1.0 TB (1000555581440 Bytes) (exactly 1954210120 512-Byte-Units)
   Device Block Size:        4096 Bytes

   Read-Only Media:          No
   Read-Only Volume:         Not applicable (no file system)

   Device Location:          Internal
   Removable Media:          Fixed

   Solid State:              Yes
   OS 9 Drivers:             No
   Low Level Format:         Not supported

Silicates:~ jspencer$ diskutil info -plist /dev/disk0 
2017-01-17 16:12:13.876 diskutil[39915:5463476] There was an error parsing the Info.plist for the bundle at URL <0x7fbfc0f07ad0>: NSCocoaErrorDomain - 3840
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Bootable</key>
    <false/>
    <key>BusProtocol</key>
    <string>PCI-Express</string>
    <key>CanBeMadeBootable</key>
    <false/>
    <key>CanBeMadeBootableRequiresDestroy</key>
    <false/>
    <key>Content</key>
    <string>GUID_partition_scheme</string>
    <key>DeviceBlockSize</key>
    <integer>4096</integer>
    <key>DeviceIdentifier</key>
    <string>disk0</string>
    <key>DeviceNode</key>
    <string>/dev/disk0</string>
    <key>DeviceTreePath</key>
    <string>IODeviceTree:/PCI0@0/RP17@1B/SSD0@0/IONVMeController</string>
    <key>Ejectable</key>
    <false/>
    <key>EjectableMediaAutomaticUnderSoftwareControl</key>
    <false/>
    <key>EjectableOnly</key>
    <false/>
    <key>FreeSpace</key>
    <integer>0</integer>
    <key>GlobalPermissionsEnabled</key>
    <false/>
    <key>IOKitSize</key>
    <integer>1000555581440</integer>
    <key>IORegistryEntryName</key>
    <string>APPLE SSD SM1024L Media</string>
    <key>Internal</key>
    <true/>
    <key>LowLevelFormatSupported</key>
    <false/>
    <key>MediaName</key>
    <string>APPLE SSD SM1024L</string>
    <key>MediaType</key>
    <string>Generic</string>
    <key>MountPoint</key>
    <string></string>
    <key>OS9DriversInstalled</key>
    <false/>
    <key>ParentWholeDisk</key>
    <string>disk0</string>
    <key>RAIDMaster</key>
    <false/>
    <key>RAIDSlice</key>
    <false/>
    <key>Removable</key>
    <false/>
    <key>RemovableMedia</key>
    <false/>
    <key>RemovableMediaOrExternalDevice</key>
    <false/>
    <key>SMARTStatus</key>
    <string>Not Supported</string>
    <key>Size</key>
    <integer>1000555581440</integer>
    <key>SolidState</key>
    <true/>
    <key>SupportsGlobalPermissionsDisable</key>
    <false/>
    <key>SystemImage</key>
    <false/>
    <key>TotalSize</key>
    <integer>1000555581440</integer>
    <key>VirtualOrPhysical</key>
    <string>Unknown</string>
    <key>VolumeName</key>
    <string></string>
    <key>VolumeSize</key>
    <integer>0</integer>
    <key>WholeDisk</key>
    <true/>
    <key>Writable</key>
    <true/>
    <key>WritableMedia</key>
    <true/>
    <key>WritableVolume</key>
    <false/>
</dict>
</plist>

At least the error appears first when it outputs a plist, so it might be easier to skip.

In any event, I'll file a bug for this with Apple.

[lurch]

Obviously it'd be better for this to be fixed "upstream" (i.e. by Apple) than Etcher adding workarounds for a beta release of an OS ;-)

[jspencer]

Yes, truly.
I've filed a bug for this rdar://30064041 I'll update this bug with details since the resolutions are not public.

Hopefully it's fixed before release, or it really is just corruption on my system alone.

[lurch]

Thankyou @jspencer

[jviotti]

Thanks a lot for the investigations @jspencer. While this is definitely an OS bug, invalid YAML pairs (e.g: the output you see in the middle of diskutil output) should already be ignored by default (see https://github.com/resin-io-modules/drivelist/pull/99), so this issue shouldn't happen anyway. We'll investigate!

[jspencer]

I heard back from Apple Engineering on this issue, they pointed me towards user-installed filesystems. I had installed FUSE at some point ( https://osxfuse.github.io ) and it was installed at /Library/Filesystems/
After removing everything from /Library/Filesystems, this bug cleared up. It still appears to be a bug in diskutil that it can't handle the error though and they may well fix it before release.

If anyone else runs into this, Apple's filesystems are installed at /System/Library/Filesystems/ so it's worth checking there for anything weird (though deleting anything important there will seriously hose your computer) and also checking ~/Library/Filesystems/ which is another place user-installed filesystems can live.

[jspencer]

To be clear, the file I removed was /Library/Filesystems/fusefs.fs

[lurch]

Thanks for the updated info, hopefully this is a bug Apple will fix before they release :)

[jviotti]

Sounds great! Let's keep this open to debug why drivelist was not ignoring those lines out of the box.

[jspencer]

10.12.3 was released with the bug. Still should be rare for people to have third-party filesystems installed.

[jviotti]

@lurch I just realized this is a variation of https://github.com/resin-io/etcher/issues/1025. Drivelist is ignoring the invalid output correctly (I double checked) however an error is thrown because they are being sent to stderr.

Maybe its good enough to shut up stderr output from diskutil? Alternative, we can pipe its stderr to stdout, so it will get analyzed by the parser, and thus automatically ignored.

E.g:

diff --git a/scripts/darwin.sh b/scripts/darwin.sh
index d2636c3..b03a04c 100755
--- a/scripts/darwin.sh
+++ b/scripts/darwin.sh
@@ -12,7 +12,7 @@ DISKS="`diskutil list | grep '^\/' | get_until_paren`"
 mount_output="`mount`"

 for disk in $DISKS; do
-  diskinfo="`diskutil info $disk`"
+  diskinfo="`diskutil info $disk 2>/dev/null`"

   device=`echo "$diskinfo" | get_key "Device Node"`

Or:

diff --git a/scripts/darwin.sh b/scripts/darwin.sh
index d2636c3..7a38698 100755
--- a/scripts/darwin.sh
+++ b/scripts/darwin.sh
@@ -12,7 +12,7 @@ DISKS="`diskutil list | grep '^\/' | get_until_paren`"
 mount_output="`mount`"

 for disk in $DISKS; do
-  diskinfo="`diskutil info $disk`"
+  diskinfo="`diskutil info $disk 2>&1`"

   device=`echo "$diskinfo" | get_key "Device Node"`

What do you think?

[jviotti]

In any case, do you think we will ever get something worth inspecting from the stderr output of the scripts? Maybe we should check for situations where an error might happen and exit the script with non zero exit code and shut up stderr from it.

[jviotti]

Another alternative is to pipe stderr to stdout for the whole script, and delegate the responsibility of omitting or rejecting stuff to the parser.

[lurch]

Given that we can't know in advance which errors (sent to stderr) are safe to ignore, and which aren't, I still think the best option (that I also suggested here) would be to filter stderr against a whitelist of "safe to ignore" regexes. Yes it means these platform-specific lists will have to be maintained and might grow over time, but it means there's no risk of us ignoring any 'real' (important) errors.

[jviotti]

In my recent drive scripts refactoring (https://github.com/resin-io-modules/drivelist/pull/134, https://github.com/resin-io-modules/drivelist/pull/135) I enabled the set -e option, which will cause the entire script to fail if any of the called commands return an exit code other than zero. With that option enabled, I'm thinking ignoring stderr if the whole script exists with exit code zero is not that bad.

What do you think?

[lurch]

Yeah, I guess that sounds reasonable, since if a command exits with status code 0, then anything printed to stderr _should_ be a warning rather than an error :)
Would it be possible to still log stderr output somewhere, e.g. to DevTools?

[jviotti]

Done: https://github.com/resin-io-modules/drivelist/pull/137. I'm using the https://github.com/visionmedia/debug module to print the scripts stderr to (the parent process) stderr if debug mode is enabled. I'll enable this on Etcher once that PR gets merged and we will see stderr in DevTools.