Thunderbolt being called Bluetooth PAN?

Sonic84
Contributor III

Hello, I'm getting a really weird issue when imaging some Macs. The Thunderbolt Ethernet adapter is being mislabeled as Bluetooth PAN by OS X and it's breaking some of my network related scripts and JAMF enrollment to the JSS. This bug appeared for me in Mac OS X 10.8.5 and has continued to manifest in Mac OS X 10.9.0. We've escalated to Apple but are getting stuck in a "we need more logs/can't reproduce on our end" loop. I said some Macs earlier because this issue is very hit-or-miss. I have reliably got the error to manifest on a MacBook Pro 13" retina late-2013 and reliable NOT manifest on a MacBook Pro 15" retina late-2013.

The issue seems to manifest the boot right after Casper imaging, then "goes away" after casper is done running packages set to install at reboot.

Has anyone else run into this bug?

5 REPLIES 5

asditsupport
New Contributor III

I've experienced a similar issue but for us it didn't cause any major problems since we didn't have any script(s) in place. Even though it didn't cause a problem to us, I did a minor research and read something about the NetBoot version used to deploy the image. Ideally it should be created using the exact OS and hardware as the client going to be imaged. I haven't yet tested it out for this particular problem so I cannot assure you that this is the ultimate solution.

Have you used any other software to deploy and test?

bbass
Contributor

That's pretty much what we found as well. The master image was created on a machine that was different and when the new machine was booted the interfaces were all jumbled. Eventually, we solved this issue by using including some lines in a "first boot" script. Our template was based on Rich Trouton's work. I think the gist of it is here:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/first_boot

When using these scripts the machine makes several configuration changes before it boots. We simply added a few lines so that a machine would create a new location and populate it with the correct interfaces, switch to that location, and then delete the "Automatic" location that had the incorrect interfaces. Something like this:

#!/bin/sh
## -- Several lines unrelated configurations here --
# Create a default set of network locations
/usr/sbin/networksetup -createlocation Default populate
/usr/sbin/networksetup -switchtolocation Default
/usr/sbin/networksetup -deletelocation Automatic

This might not be exactly what you are looking for but it worked flawlessly for us.

asditsupport
New Contributor III

What I would recommend is to create a base image and deploy (to a similar hardware) using a NetBoot of the similar OS and hardware to test if the network adapters are named properly. This might at least get a few variables off the table.
We do it strictly this way due to the high volume of machines we image. We do not leave anything to chance and so far it has paid off.

Sonic84
Contributor III

Hello, I created the netboot image I'm using from the custom build of 10.9 that came on the late 2013 MacBook Pro 15" (build 13A3017, Mach Kernel v13.0.2). This flavor of 10.9 seems to boot all three late 2013 models I have. I'm continuing to use my 10.8.4 netboot for pre-late-2013 systems. Unfortunately I have not done much testing with older systems. The late-2013 models I have are on loan and I have limited time with them.

On my late 2013 MacBook Pro 13" lab system, I'm deploying the custom build of 10.9 that it shipped with: build 13A2093, Mach Kernel v13.01. This system is consistently running into the "network interface misnamed" issue.

On my late 2013 MacBook Pro 15" lab system, I'm deploying the custom build of 10.9 that it shipped with: build 13A3017, Mach Kernel v13.0.2. This system is consistently NOT running into the network interface misname issue.

On my late 2013 iMac 27" lab system, I'm deploying the normal build of 10.9 that is installed from the AppStore with: build 13A603, Mach Kernel v13.0.0. So Far... This system is NOT running into the network interface misname issue. Though I have only reimaged it a few times while I test the configuration I'm developing.

I'm not entirely sure if it has to do with the netboot. Network setting changes by the live-OS of the netboot are written to /dev/disk1/CasperBoot not /dev/disk0/Macintosh HD. Even is settings were written to Macintosh HD, they'd be deleted when Casper Imaging lays down the the base DMG. In all of my tests, the the 10.9 netboot I'm using has not suffered from the naming issue. Even if the settings are somehow retained from the netboot environment, shouldn't the correct settings stick? Am I missing something?

Sonic84
Contributor III

Hello, I've done some more testing with Apple, the workaround we're using is to delete the contents of /Library/Preferences/SystemConfiguration/ on the core image. This gets around the "bug" of Thunderbolt Ethernet being called "Bluetooth PAN" and network settings not being saved the first boot after Mac OS X is installed.

I added a script in my image config to delete the path contents mentioned:

rm -Rf "$1"/Library/Preferences/SystemConfiguration/*