how to avoid system storage error when copying configuration to new device?

[journeyman]

Loading a configuration file from a 60D into a new 60D with matching firmware causes an error:

system.storage.Internal-0:failed command

What is the best way to avoid this?[ul]

Edit the configuration to remove the config system storage section and then load?

Inspect the new unit, find the partition ID, edit the configuration to match, load configuration?

Some other way?[/ul]

It's annoying...

[ede_pfau]

By definition of the FTNT gods, there is no 'internal storage' on a 60D, or rather, no more.

I'd cut the section out and reload.

[journeyman]

I'm happy to remove it, but it's present in a default configuration of 5.2.3. Has it been cut since then?

[ede_pfau]

Actually, Release Notes for v5.2.0 state that disk logging for (among others) the 60D had been removed. Strange that the default config still allows to configure storage. Have you tried if that works (on a 'factoryreset' 60D)?

[journeyman]

Just checked a brand new unit running 5.2.5 and it has

config system storage

    edit "Internal-0"

        set partition "0123456789ABCDEF"

        etcThe partition value is read only hence the error. That makes the configuration effectively watermarked (the serial number would be nicer in that case) and not portable between units (without error) without intervention. It's fine for me but not ideal for our on call procedures.

I am fishing for a way to prevent the error with minimum intervention at 3am. I guess deleting the disk from running configurations is the way to go, and accept that disks will pop up and require deletion whenever a hardware replacement occurs.

[ede_pfau]

I see.

Same as uuid lines, right?

[journeyman]

At least uuid doesn't throw errors - to the point that I hadn't realised the issue existed.

I have found notes from a HA cluster build in 5.2.3 that indicate it's better (I found it necessary) to leave the internal storage present rather than delete it (I tried both). In that case I took an existing configuration and loaded it into a the target device and then connected a second unit and formed a cluster. In the end I copied the partition ID of the target device into the source config and all was well.

Perhaps when I tried deleting storage I didn't also delete it from the second unit prior to forming the cluster - my notes don't say.

But no-one would have to rebuild a cluster at 3am eh? ;)