Mac Studio is dead, long life Mac Studio

Ok beside of the joke in the post title, I am trying to recover whatever I can recover from the /opt/Autodesk folder from the dead Mac Studio, and it seems it is going ok. Since I bought another Mac a few days back, I wanna ask how manually I can copy files from the recovered /opt folder to fit correctly in a new installed Flame so I can have my projects back, I am sure it is not a simple replacement after installation.
I am aware that the easiest and cheapest way is to go to project/*/batch and re-open them again in the new fresh installed Flame to recover my batches, but I would appreciate a better workaround to avoid doing that on more than 80 batch in progress.

The short answer about a Time Machine backup won’t please anyone since I discovered that since 3 months my auto backup decided not to work as planned.

I would appreciate easy solutions

Best regards from Paris

1 Like

If you can clone everything in /opt/Autodesk from the old Mac to the new Mac and clone everything from the frame store(s) from the old Mac to the new Mac and make sure the mount paths are the same then I would think a new install of Flame on the new Mac would pick it up. Or you could at least then try the recover stone+wire database procedure to force it to rescan the frame store and hopefully link up with the projects db.

But I would try the cloning/copy steps before installing Flame on the new Mac or at least make sure all services in the Service Monitor app are stopped on the new Mac before copying files.

I did this on linux and it didnt work and I lost everything…I think it is beacuse it is workstation id linked, every machine has a unique ID number and I think that number is attached to every project.

Can you share what happened to the Mac Studio, what’s the damage?

You may have luck contacting support for assistance.

1 Like

I think cloning the whole machine may give better results as the new machine will take on the same system prefs like network settings. Doesnt wtg and backburner use that info?

Restore from archive.

Software fault, no hardware issue apparently

Hello everybody
Solution found, done by one of the best brains around, it looks like magic, it involved rewriting some cfg files, not able to tell more coz my neurons are smoking now
Thanks for your interventions

2 Likes

@chadi - I got you brother, it’s always great to spend time with you.

If anyone else experiences the inexplicable pink screen of death on an ARM mac:

  • Don’t listen to the Apple Genius - don’t wipe your drive.

  • Start the computer in Target Disk Mode and connect to another Mac.

  • Transfer the entire /opt/Autodesk directory to the new Mac.
    (The crucial files are all over the place so lift the entire directory)

  • Make a backup of /opt/Autodesk/cfg/network.cfg to your home directory.
    (This is where the Autodesk UUID is stored)

  • Make a backup of /opt/Autodesk/sw/cfg/stone+wire.cfg to your home directory.
    (This is where your framestore is defined)

  • Make a backup of /opt/Autodesk/clip to your home directory.
    (This is where your projects are defined)

  • If your framestore is on your mac, then copy the entire directory and match the path on the new mac to that of the original.

  • Install flame on the new mac.

  • Validate that your UUID has not changed.

  • License flame, and permit file/folder access.

  • Create a test project.

  • Use MediaHub->Projects to observe the integrity of your projects.

  • Start flame in your rescued project(s).

  • Archive promptly and thoroughly.

  • Lobotomize your pink screen mac and restore from Time Machine if possible.

  • Remember to wipe /opt/Autodesk from the old mac otherwise you will have all kinds of nasty conflicts.

  • Reinstall flame on the freshly lobotomized mac.

  • Carry on, nothing to see here, these aren’t the droids you’re looking for.

14 Likes

That was a fantastic idea. Well done. I hope I never have to do it.

1 Like

Adding this for future searches, How to migrate project metadata to a new drive or workstation in Flame

5 Likes

I’m in the minority but I think that some software might benefit from accompanying ‘best practices’ and ‘optimal setup’ guides, instead of material that explains how to fix things once things have gone wrong.

The same approach could be applied to industries as a whole.

Even a’ hole industries.

1 Like

The best practice in this instance would be to always be current on Flame archives. [Flame Archiving Overview]

@motoronlysync - That’s another really good reference to add into this thread.

I agree that having an up to date archive can get you out of a jam, and encourages a sense of security when using flame.

Other topics that would be useful are:

  • Storage (the difference between stonefs and standardfs)
  • Networking (data and metadata networks)
  • Identity management (why similar user accounts are actually different)
  • Project management (local / shared / hybrid approaches)
  • Business continuity (coping with earthquakes, fires and upgrades)

I think of it like a pit crew for formula 1 - nobody talks, everything gets done in a few seconds and your guy wins the race.

or

you bring your racecar into the pit, someone tells you that you’re out of gas, another says that your tyres are bald, and someone else tells you that all the other cars are passing you - all true, but it doesn’t get you to the chequered flag, the champagne and global adulation…

I don’t have enough digits and appendages to indicate how many issues I personally see where the archive strategy at a facility consists of hope and avoidance. I write scripts to try and make it a little easier, but Archiving should be a higher priority in my opinion. Who wants to rebuild a whole project just to change a legal line for the client.

As for the rest on your list, I’ll take a stab at the top two and bottom ones for you.

  • There are no stonefs volumes anymore. Your partition or “stone” is just a folder now.
  • Data and Metadata, this article has served me well over the years. if you have items that would be beneficial to include, let me know and I can update this document.
  • Are you aware that a quick call to Geico can save you 15% on your auto and renters insurance? Given your racing analogy, I feel it’s important to address the insurance aspect to keep you fully covered. Drive safely.
1 Like

We are in alignment.

Archiving a facilities’ most important resource should not be left to the unqualified and underpaid, but it frequently is, and continues to be.

I wrote scripts for the last few years to automate flame archives.
I also write scripts to zfs send and/or rsync.

All of these can be added to a cron tab.

It’s true that stonefs is just a folder and we’re not managing our own private SANs any longer, but you need it (for how much longer who can tell?)

Data and metadata separation on macOS is less of an issue (if an issue at all).

2025 eliminates the flame user so identity management and computing continuity is important.

Operating system updates are crucial for the widening array of threat vectors and the continued emergence of decades old sleeper threats (so much for due diligence and information superiority).

Hardware failures and software induced hardware failures (see pink screen of death) do not frequently make a big splash on people’s business plans, and can be crippling for some.

As for formula 1 racing, the best insurance is to rely on the world’s best, to mingle with the world’s best, and have a duplicate of everyone and everything on one of the two trucks in the paddock (or the 3rd truck in the belly of the 747 on the runway).

I wouldn’t wait for the independent contractor with his own truck and imperial measurement toolset.

Besides, I haven’t driven a car regularly for the last 10 years…