Fixing moonraker "dirty" flag error - Time for testing

[Staubgeborener]

Ok guys @MallocArray, @jaakko000 @Rvh91, I need some help to test this. A separate issue should help to keep the overview, because this is a little bit very special.

I created a new branch called dev.

There you can find a new install.sh script which tries to fix this dirty moonraker flag issue.

Idea: The user downloads the repository as it is, during installation you will be asked to enter the path of your "true" backup folder. You have to edit the .env file in this "true" backup folder like you did before in the klipper-backup folder. As soon as a new update is ready, it will be loaded in the klipper-backup folder, then the script looks up the path to the "true" backup folder and copies all relevant files there (except the .env).

How to do it, step by step:

1. Fork this project (remove the checkmark at 'Copy the main branch only'!)
2. Clone the repository from your account: git clone -b dev https://github.com/yourownaccount/klipper-backup/
3. cd ./klipper-backup && chmod +x *.sh
4. ./install.sh
5. The script will ask for the "true" backup folder, enter something like /home/pi/myownklipperbackup (it's up to you)
6. Check if it worked: ls -al /home/pi/myownklipperbackup
7. Edit the .env file in your own backlog folder not the one in klipper-backup!
8. Now you have to initialize the "true" backup folder git repository like this. ATTENTION: cd /home/pi/myownklipperbackup is not correct anymore! Instead, do cd ~/klipper-backup
9. Now you can change some files in your forked repository (see step 1). Moonraker should see that and tells you about a new update.
10. Hopefully this will work

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[Staubgeborener]

push

[Rvh91]

I'm sorry for not replying earlier. I will try to do this at some point, but I'm a bit stuck on time at the moment.

[MallocArray]

I will try to do this in the next few days as well

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[Staubgeborener]

last push

[SejeAnd]

Is the backlog folder refrenced in step 7, the .env.example folder in the forked github project?

[Staubgeborener]

Is the backlog folder refrenced in step 7, the .env.example folder in the forked github project?

Yes (btw backlog = backup, my bad).

[SejeAnd]

The script never asks for a "True" backup folder like stated in step 5. Should i ignore step 5 and 6 then?

[Staubgeborener]

The script never asks for a "True" backup folder like stated in step 5. Should i ignore step 5 and 6 then?

Your right, i fix'd it. Please remove the cloned repository from your system with rm -r klipper-backup and also delete the fork on your GitHub profile, so we can start from scratch. Begin again with step 1.

(Reason for this error: There was this version file in the dev branch. When you run the ./install.sh script it just saw this version file and thought, that the script was up-to-date (because local version file = version in this GitHub repository), so i simply removed this version file in order to get the installation script to work)

[cvdbout]

I've just tried this after having the same difficulties with moonraker giving a error. I am now having a new error when I try to run the backup after making changes (adding a .gitignore file to exclude .env):

fatal: could not read Password for 'https://MYPERSONALACCESSTOKEN@github.com': No such device or address

When I initially ran the script, it worked fine - I have a backup in my repo from the intial script.sh run.

.env contents:

github_token=myaccesstoken github_username=cvdbout github_repository=Klipper_Backup

back up whole folder syntax:

path_klipperdata=/home/pi/printer_data/

backup_folder=klipper

My repo https://github.com/cvdbout/Klipper_Backup

When I rerun script.sh through ssh:

Password for 'https://MYACCESSTOKEN@github.com': remote: Invalid username or password. fatal: Authentication failed for 'https://github.com/cvdbout/Klipper_Backup.git/'

I am using my access token as password

[cvdbout]

Ha, figured it out - I was being an idiot. Started again, added the .gitignore after editing the .env and it all works as it should.

[Staubgeborener]

Ha, figured it out - I was being an idiot. Started again, added the .gitignore after editing the .env and it all works as it should.

Good to hear, could you try the dev branch and backup some folders (recursively with some files in it) and some specific files?

[cvdbout]

Ha, figured it out - I was being an idiot. Started again, added the .gitignore after editing the .env and it all works as it should.

Good to hear, could you try the dev branch and backup some folders (recursively with some files in it) and some specific files?

It was the dev branch I forked (word for word as per your original post, with the exception of adding the gitignore prior to executing script.sh).

Ive set my repo to public again, link above.

I've added a folder and file called test, which updated in the repo when I ran the macro.

When I delete the folder and file in klipper, it remains in the repo, not sure if that's how it's supposed to be or not. In the console it says cannot rewrite branches: you have unstaged changes. It does update the repo with the log files though.

I'm not well versed in github specifics, but I am awesome and following instructions and minor troubleshooting.

On the Update Manager screen, the green box says unknown

[Staubgeborener]

When I delete the folder and file in klipper, it remains in the repo, not sure if that's how it's supposed to be or not. In the console it says cannot rewrite branches: you have unstaged changes.

Sadly i can confirm this. Well i have to figure out some stuff - I know where the poblem lies but must still think about how to solve this most efficiently.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[Staubgeborener]

This issue is stale because it has been open for 30 days with no activity.

I don't think so

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[Staubgeborener]

This issue is stale because it has been open for 30 days with no activity.

Disabled the auto close workflow.

[Torrosua]

Is this issue still relevant? Do you need help with testing?

[Staubgeborener]

@Torrosua this problem still exists. I know where it comes from but I can't find the time to fix this, so I'm open for any help and pull requests.

[Torrosua]

Can you describe what you know about it? I'll try to investigate too.

[Staubgeborener]

I described it here.

So: the script will clone this repository here and sets everything up so the user can use his own repository. Now moonraker has a problem: the cloned repository (which is in the local system) has now a different name, gitfiles looks different, etc but moonraker expect exactly this repository in order to run a clean update.

A little bit hard to explain. But as an example: cloning this repository leads to a working moonraker config - you can update the script with moonraker but of course you can't use it as you didn't install/set up everything in order to work with your repository. Now you run the install scripts: you can use your repository as it should be but the moonraker service is broken.

One way to get rid of this could be the following: after running the install script we leave the Klipper-backup folder on the system so the moonraker service is not broken. After hitting the update button, the script will copy the new files to the user folder. In order to realize this, the script needs to know the path of the user folder.

[Tylerjet]

@Staubgeborener I have a solution to the issue so far its been working on my fork, however there are some things like install.sh and the version file that I found are not really needed if the repo is setup properly as moonraker will already create a tracked version number based on the commit and sees when updates are available. So using install.sh to update or make any changes becomes a non-issue IMO.

I also added some checks like not copying read only files that are symbolic linked to the printer_data/config folder (ex. mainsail, fluid, KAMP) as that data doesn't change unless its also updated in moonraker manger.

I can push all my changes to a pull request for you to review or if you take a look at my fork you can pull the parts that i changed to make it work as i do have many other changes that may be breaking.

I also have a branch labeled original there, which just has the main changes. 1 is still breaking. But it doesn't remove the files or scripts that are now no longer needed. and just has the base level changes which i can make a pull request for instead if you would like.

[Staubgeborener]

@Tylerjet i already saw your fork and I stalked at the commits almost in real time.

It certainly looks very promising. I will test it myself on a mainsail system and if that solves all the problems we could start directly with the first version 1.0 (🎉).

[Tylerjet]

@Tylerjet i already saw your fork and I stalked at the commits almost in real time.

It certainly looks very promising. I will test it myself on a mainsail system and if that solves all the problems we could start directly with the first version 1.0 (🎉).

Oh Perfect just sorted out what was my last personal issue with both branches. didn't like that i was having to use eval just to make the copy work, and now that is no longer needed.

I will be doing a fresh test of my main branch tomorrow (more like later today as its 1:30 am for myself hehe) and the modified original again as well just to ensure that all steps do work and it has no issues.

Not sure which you prefer both but should be in good working order i believe.

[Staubgeborener]

@Tylerjet I see, you're still working on the stuff. I would suggest the following: Just open a pull request if you're ready. We will merge your main branch (not your original branch).

[Tylerjet]

@Tylerjet I see, you're still working on the stuff. I would suggest the following: Just open a pull request if you're ready. We will merge your main branch (not your original branch).

Sounds good, yeah had a few ideas and improvements rolling around in my head last night so going to add those first and then will do the PR.

[Staubgeborener]

I have no idea who else is following this, but thanks to @Tylerjet we have fixed this annoying bug and klipper-backup has reached version 1.0.0. :tada:

The wiki has been adapted accordingly, I advise everyone to read this article.

[cvdbout]

Great news!

[Rvh91]

Thanks for the work! I wanted to share two comments with you regarding this.

I have followed the guides: https://github.com/Staubgeborener/klipper-backup/wiki/migration

However, upon completing, and re-adding the lines specified here: https://github.com/Staubgeborener/klipper-backup/wiki/Installation%3A-Moonraker-Support

I get the warning on my klipperscreen: home/pi/klipper-backup/install.sh does not exist

Not sure if this matters at all. Just wanted to report. Also in the migration wiki, there is a small typo on step 3, where rm-r should be rm -r.

Thanks again!

[Staubgeborener]

@Rvh91

home/pi/klipper-backup/install.sh does not exist

Indeed; the file install.sh is not used anymore. The only reason why you get this message is, that you still use the old script.sh file. Just do a cat script.sh und you will see that this one doesn't match with the script.sh file in this directory. I can't tell you why. You can break down the migration wiki page in these steps:

1. Backup your .env file so you can use your old token
2. Delete old Klipper-backup
3. clone the new repository
4. adjust your .env in the new Klippers-backup.

There is one step you missed. Maybe you backuped your old script.sh file (which is not supported anymore) and copied this one in the new Klipper-backup folder. Otherwise post you whole log in you terminal so I can clearly see every step. I suggest reading the section again and do exactly every step there.