RetroPie forum home
    • Recent
    • Tags
    • Popular
    • Home
    • Docs
    • Register
    • Login
    Please do not post a support request without first reading and following the advice in https://retropie.org.uk/forum/topic/3/read-this-first

    Question about upgrading and config overwrites

    Scheduled Pinned Locked Moved Help and Support
    10 Posts 2 Posters 5.6k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      movisman
      last edited by

      Hi,

      I just have a quick question regarding updating in full from a binary based installation.

      I recently started my Retropie instance from scratch on 3.6 (as I was on old 3.0 before and a fresh image was always better than upgrading because of Jessie). Everything is running as I like, and so far, when upgrading anything, I update the script, and then I update/install the components I wish to update based on the changes made and if I need/want them.

      However if I wish to do a full upgrade to say, 3.7 based on the binary installation, will it overwrite any files which I am likely to have edited? For example es_systems.cfg, emulators.cfg, runcommand.cfg, etc, etc, or anything else eg. core options, changes to shaders, etc? I know the retroarch configs don't overwrite and a new one is written as retroarch.cfg.rp-dist, keeping your old one intact with a new skeleton one. But just wondering how other files are treated. If say, a config file gets a series of updates to add functionality, I assume this will overwrite your old one, meaning you lose any edits you made. I guess I would then need to merge my changes back into the new config file.

      It doesn't matter if something did go wrong, because I have full .img backups of the SD as well as offline WIP versions of any files which I edited from the default. But I have always been curious about how it works (full update installation over the top) vs. doing every component individually as required.

      Sorry if this is a silly question. I have read the wiki of course, but I am not quite clear how the script treats existing files. Can someone help me clear this up?

      Thanks!

      1 Reply Last reply Reply Quote 0
      • BuZzB
        BuZz administrators
        last edited by

        /etc/emulationstation/es_systems.cfg will be changed - you can copy that to /opt/retropie/configs/all/emulationstation/es_systems.cfg to manage it yourself

        Generally configs are not overwritten. There may be a case or two we have missed though.

        To help us help you - please make sure you read the sticky topics before posting - https://retropie.org.uk/forum/topic/3/read-this-first

        M 1 Reply Last reply Reply Quote 0
        • M
          movisman @BuZz
          last edited by

          @BuZz

          Thanks BuZz.
          No probs with es_systems.cfg, I have only made basic edits to remove .iso and .bin for PSX from there so that's a 2 minute job if it's overwritten. Or I can just copy it as you suggest.

          So in theory, nothing in opt\retropie\configs\all would be touched. I assume the only time anything would be overwritten in here is if the workings of a particular config file changed dramatically? (unlikely I guess)

          What about changes to default shaders or changes to theme related files? Would these only be overwritten if there is an update to the shader or theme in question?

          I guess any changes in \etc\init.d and \etc are liable to be overwritten. I have only a couple of edits here though which are very simple.

          Thanks!

          1 Reply Last reply Reply Quote 0
          • BuZzB
            BuZz administrators
            last edited by

            you can control extensions by copying platforms.cfg from ~/RetroPie-Setup to /opt/retropie/configs/all and then that will be used when updating es_systems.cfg - but you would need to keep it up to date manually then.

            Nothing should be overwritten in that folder correct.

            To help us help you - please make sure you read the sticky topics before posting - https://retropie.org.uk/forum/topic/3/read-this-first

            M 2 Replies Last reply Reply Quote 0
            • M
              movisman @BuZz
              last edited by

              @BuZz

              Hi BuZz,

              Thanks very much for your help. I will do a full binary install and I soon will be able to tell what's been overwritten pretty quickly, if anything. Will let you know if anything unexpected happens.

              Cheers!

              1 Reply Last reply Reply Quote 0
              • M
                movisman @BuZz
                last edited by

                @BuZz

                I just did a full update, if interested here are my initial findings:

                es_systems.cfg overwritten as expected (as explained above)
                crt-pi shader (which i had updated) was overwritten with the older version (even though it was updated yesterday?)

                Both files created a .old copy but the copy does not appear to be the pre-upgrade file, it is just a copy of the new file? They appear to match.

                All of the emulator specific emulator.cfg files in /opt/retropie/configs/insertsystemhere were overwritten with a new copy, meaning my default emulator changed back to default on any system which I had selected a preferred emulator for, eg. Master System, Megadrive, Nintendo, Sega CD. Any idea why this might be?

                Apart from that, so far I cannot see anything else from the upgrade which has caused issues. The above literally took me 15 minutes to sort.

                Cheers

                1 Reply Last reply Reply Quote 0
                • BuZzB
                  BuZz administrators
                  last edited by

                  Yes, the default per system emulator will be overwritten currently, so I should change that. Thanks.

                  the crt-pi shader won't be updated until a new retroarch is packaged, but actually, that could be improved as the shaders / overlays could be installed at the configure stage instead. I'll probably change that too.

                  To help us help you - please make sure you read the sticky topics before posting - https://retropie.org.uk/forum/topic/3/read-this-first

                  M 1 Reply Last reply Reply Quote 0
                  • M
                    movisman @BuZz
                    last edited by

                    @BuZz

                    Thanks for clarifying this, understood about the shader thing, I didn't realise it currently worked this way. I was going to ask if you wanted me to raise an issue in Github for those two items but I see you have already done it, thanks :)

                    The only other thing, which I mention above, is when my crt-pi.glsl and es_systems.cfg were overwritten, I was expecting the .old copies which were made to be my old file. But when I checked the content it looked like the file was just a copy of the new one. I might have been going mental, and maybe I need to test this again to be sure. But i'm pretty certain that was the case.

                    Cheers

                    1 Reply Last reply Reply Quote 0
                    • BuZzB
                      BuZz administrators
                      last edited by

                      Not sure where the old copies came from, as right now this area gets overwritten - it's not set to rename anything to .old - you sure you didn't create them when changing ? If you rename your custom version it should avoid it being overwritten.

                      To help us help you - please make sure you read the sticky topics before posting - https://retropie.org.uk/forum/topic/3/read-this-first

                      M 1 Reply Last reply Reply Quote 0
                      • M
                        movisman @BuZz
                        last edited by

                        @BuZz

                        Ha, now you are making me seriously doubt myself. I swear the .old files had a modified date of when the update took place. If I was imagining this (which it sounds like I was if the code is not set to do this), there is a chance I would have kept a remote copy due to previous tweaks to both files.

                        I'll just make a mental note to see what happens when I next upgrade, the .old files have been removed now.

                        Thanks again.

                        1 Reply Last reply Reply Quote 0
                        • FloobF Floob referenced this topic on
                        • First post
                          Last post

                        Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.

                        Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.