Anyone else with archiving that stopped working lately with 1.4 rolling-release?

I noticed the other day that archiving that is archived configs in /config/archive stopped working with date 2 july.

Anyone else who have experienced the same?

The commit file seemed to have correct content but lr.state pointed to a config from 2 july so something bad have happend in between (and I have had alot of commits and saves and reboots the past week since this vyos box is in my lab).

In my case the workaround was easy to make it work again:

  1. sudo bash
  2. Create an offline backup (just in case): scp /config/archive/boot.config user@server:/path/boot.config.230710
  3. mkdir /config/archive/old
  4. mv /config/archive/* /config/archive/old
  5. Verify that /config/archive/boot.config still exists otherwise copy it back from the old directory like so: cp /config/archive/old/boot.config /config/archive
  6. reboot
  7. After reboot make sure that commit/save works and new archive-files have been created in /config/archive

@Apachez I gather this was during an upgrade (from comments in lobby); could you please share the version numbers of the initial image and the upgrade image ?

The initial version was from 2023-06-29:

VyOS 1.4-rolling-202306290317

I have since updated that 2-3 times towards latest as of today 2023-07-10:

VyOS 1.4-rolling-202307100526

The last archives were from 2023-07-02 but I had both commited, saved and rebooted the installation since.

The broken archives remained when updating to VyOS 1.4-rolling-202307100526 so the workaround mentioned in first post seems to have fixed this.

If the error returns I will file this as a bug but in the meantime Im just curious if somebody else have experienced this - otherwise its probably something I did at around 2th july which I later cannot reproduce so there is nothing to bugreport about :slight_smile:

I honestly think this is related to the config file corruption that is happening during upgrades/reboots.

There is one of the related tasks T5347
As I mentioned before the best and quick way to fix a bug is open a bug-report on
Without it any bug couldn’t be fixed. As it is our official bug tracker system. Please add a bug report next time if you find something wrong.

I got the impression that it was prefered to first create a forum thread and if reproducable and more have verified to file it as a bug?

So I should change to file as a bug at instead?

@Apachez, the major bug was resolved in T5347; if other issues arise, then you can ask here or search bug tracking for known issues, but then kindly open a bug-report as suggested by @Viacheslav