However, Google support reached out to me after a 3-week gap, so they're working on it. I had sort of assumed that "we'll pass it on to the developers" was a polite way of saying "we've sent that to /dev/null," but that's apparently not the case.
]]>Good work papabean... though I am not sure how this was seen as a reasonable design decision in the first place.
They meant to lock out multiple instances on the same computer by denying to work on virtual machines.
But I still don't understand why.
I was informed that the new method of interface naming would be passed along to the developers responsible for the Google Music Manager.
Was able to get it working, like others here, by creating the /dev/null symlink for the udev rules.
Good work papabean... though I am not sure how this was seen as a reasonable design decision in the first place.
]]>Was able to get it working, like others here, by creating the /dev/null symlink for the udev rules.
]]>ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules
and rebooting did revert to the old naming scheme.
This is the only thing needed for current Google Music Manager version to work.
Thank you again!
]]>You need to mask 80-net-name-slot.rules.
]]>So I changed my network naming scheme back to the old system (eth0 and wlan0) and lo and behold, the f*cking thing works again.
Can you please tell me how you did it or point me to a guide that explains the renaming process?
Also... if anyone knows... Why is the naming scheme changed? Is there any consequence in going back to the old scheme?
Thank you so much in advance...
]]>Anyway, hopefully this might help someone, as it is unfortunately the only way I have found to upload my music to google play.
]]>