Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
journeyman
Contributor

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

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...

  • 6 REPLIES 6
    ede_pfau
    Esteemed Contributor III

    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.

     


    Ede

    "Kernel panic: Aiee, killing interrupt handler!"
    Ede"Kernel panic: Aiee, killing interrupt handler!"
    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
    Esteemed Contributor III

    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)?


    Ede

    "Kernel panic: Aiee, killing interrupt handler!"
    Ede"Kernel panic: Aiee, killing interrupt handler!"
    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
    Esteemed Contributor III

    I see.

    Same as uuid lines, right?


    Ede

    "Kernel panic: Aiee, killing interrupt handler!"
    Ede"Kernel panic: Aiee, killing interrupt handler!"
    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? ;)

    Labels
    Top Kudoed Authors