Clarification: this was in fact a consequence of the cleanup here:
https://github.com/vyos/vyos-build/commit/d50707bb295dbd4bc50e3d0301fc8be605448429
not the cleanup of deprecated packages, consequently, the solution is simpler: simply revert the above. As previously mentioned, although this is not used by new installs, the file is expected to exist in a new image, when doing a compatibility-mode update from a system with legacy image tools. If the legacy images are subsequently removed from the system, the new image tools will switch out of compatibility mode, at which point the file is no longer needed.

This has a simple solution, and was an artifact of the much welcomed retirement of the packages vyatta-cfg-system and vyatta-op (T6527). One missing file is needed from the retired packages: since the legacy update tools look for a small number of scripts in the mounted image of the new image, a few need to be available for legacy compatibility. PR in preparation.

fixed as part of https://vyos.dev/T6802
https://github.com/vyos/vyos-1x/pull/4177

Already implemented in https://vyos.dev/T4940

I raised a draft PR (https://github.com/vyos/vyos.vyos/pull/357) to tackle some of the compatibility issues. I will try and finalise it in coming days

technically the limit would be defined by the http header length (and httpd configured allowed header sizes), http basic auth itself has no restrictions in the context of being Base64 encoded.
Often restrictions are from tooling side, not protocol side. I.e Apache htpasswd generated passwords and usernames (under windows) are limited to 255 chars, but again this is a tool limit, not a header limit
(Source: https://httpd.apache.org/docs/2.4/programs/htpasswd.html#restrictions)
256 (255) could be a reasonable value that matches this specific constraint.

In T6870#207379, @Viacheslav wrote:

Check please bug report guidelines https://blog.vyos.io/feature-requests-and-bug-reports-guidelines

When you create a bug, the most important thing is that it should be possible to tell if it's fixed.

You should include the following information:

    A sequence of configuration commands or a complete configuration file is required to recreate a setup where the bug occurs. Please avoid partial configs: a sequence of commands is easy to paste into the console, a complete config is easy to load in a VM, and a partial config is neither! At least not until we implement a "merge from the CLI" feature that allows pasting config file chunks into a session.

Check please bug report guidelines https://blog.vyos.io/feature-requests-and-bug-reports-guidelines

We use common-generic password which uses limits
We should change it here.
What number of symbols is better to make?

forum post with the same problem: https://forum.vyos.io/t/vyos-1-2-traffic-policy-shaper-match-interface-not-working/8389

exmaple test with shaper policy:

Implemented handling for the CLI command to set a filter by interface(rt_iif).
Implemented a command such as set qos policy limiter test class 10 match test_match interface 'eth1' to generate filters similar to those used in VyOS 1.3.

Upon review, I don't think that this is still an issue any longer in the current rolling release. When saving the config, the effective/running config tree is fetched instead of the session config, and so the incomplete session configuration is not written to disk. The vyatta-bash package also provides a "Warning: you have uncommitted changes that will not be saved." message now when the session has non-committed configuration.

This is not valid for 1.4 and 1.5
Only valid for 1.3 and older images.

https://github.com/vyos/vyos-1x/pull/4187

Thank you, this is my first actual contribution so please feel free let me know if this approach isn't the way you want to do it. If you point me in the right direction, I will implement it however you suggest. I mostly searched the source for other situations where VyOS asks this type of question and copied the idea.

Hey @insignia96
Give it a try and come back if you have questions or doubts
@Viacheslav @dmbaturin can you take a look and suggest if the approach suggested by @insignia96 is ok?

If this could be assigned to me, I am working on a patch that will prompt with ask_yes_no when session_changed() is true of the config, warning the user that the configuration has uncommitted changes and saving it may result in failure to load config on boot.

Thanks for bringing this to our attention @paulywog

I was able to update my router to VyOS 1.5-rolling-202411070006 and my xen vif interface is working once again. Thanks everyone!

the PR
https://github.com/vyos/vyos-1x/pull/4186

I've just encountered the same issue upgrading from a 1.5 build from May 2024 to the most recent a few days ago. Had very little time to investigate. Next week I'll take some more time and will report back if I find anything interesting.