@trae32566 Thanks I can confirm it is a bug with using commit-archive location, there is a separate task https://vyos.dev/T5348
Thanks

As shared with @Viacheslav , I see the following on a 1.4 VM, built last week:

@Viacheslav So I figured out what's causing it..it looks like for some reason my commit-archive configuration on the secondary side (which works fine normally) is causing the hanging. As soon as I remove the set system config-management commit-archive on the secondary side, everything starts working fine, even with my full firewall configuration. Has this been tested at all with commit-archive? Could there be some sort of bug happening with it? Here's the section of the secondary side config, for reference:

[system config-management]
- commit-archive {
-     location "sftp://<someUser>:<somePass>@stor01a-rh9.int.trae32566.org/int/cr01b-vyos"
-     source-address "fd52:d62e:8011:fffe::3"
- }

Yeah I tried increasing the timeout to the maximum (300) and it still timed out, but I'll try config-sync mode 'set' I guess. The config is fairly large; 549 lines of just set firewall.

In T775#151897, @trae32566 wrote:

@Viacheslav I'm not sure why, but it appears that after doing this, there is high CPU usage on the secondary side, and eventually it stops responding entirely (bgp sessions go down, no response to anything via icmp) and has to be hard reset; it won't even respond to a console login attempt:

This makes me think something in my firewall configuration is making it unhappy. I can paste my full firewall config somewhere if you'd like, but I'd prefer if it's not public for security reasons (is email fine?).

@Viacheslav I'm not sure why, but it appears that after doing this, there is high CPU usage on the secondary side, and eventually it stops responding entirely (bgp sessions go down, no response to anything via icmp) and has to be hard reset; it won't even respond to a console login attempt:

In T775#151894, @trae32566 wrote:

@Viacheslav I think that fixed it...sorta. It looks like now it does sync successfully, though it appears to time out after awhile for some reason:

trae@cr01a-vyos:~$ configure
[edit]
trae@cr01a-vyos# set firewall name INT_TO_LOCAL rule 80 destination address 192.168.253.2-192.168.253.3                                                                                                                                                                                                                    
[edit]
trae@cr01a-vyos# commit
INFO:vyos_config_sync:Config synchronization: Mode=load, Secondary=cr01b-vyos.int.rtr.trae32566.org

An error occurred: HTTPSConnectionPool(host='cr01b-vyos.int.rtr.trae32566.org', port=443): Read timed out. (read timeout=60)
ERROR:vyos_config_sync:An error occurred: HTTPSConnectionPool(host='cr01b-vyos.int.rtr.trae32566.org', port=443): Read timed out. (read timeout=60)

That being said, it does appear to have set the config on the other side:

trae@cr01b-vyos# show firewall name INT_TO_LOCAL rule 80
 action accept
 description "API access"
 destination {
     address 192.168.253.2-192.168.253.3
 }
 protocol tcp
 source {
     address 192.168.253.2-192.168.253.3
 }
trae@cr01b-vyos# cat /var/log/nginx/access.log 
fd52:d62e:8011:fffe::2 - - [09/Jul/2023:09:54:23 -0500] "POST /configure-section HTTP/1.1" 200 80 "-" "python-requests/2.28.1"
fd52:d62e:8011:fffe::2 - - [09/Jul/2023:09:55:25 -0500] "POST /configure-section HTTP/1.1" 499 0 "-" "python-requests/2.28.1"

Also, If it's any easier / you'd prefer I can set up a Webex or something.

@Viacheslav I think that fixed it...sorta. It looks like now it does sync successfully, though it appears to time out after awhile for some reason:

trae@cr01a-vyos:~$ sudo nano -c +140 /run/scripts/commit/post-hooks.d/vyos_config_sync
trae@cr01a-vyos:~$ sudo systemctl restart vyos-configd
trae@cr01a-vyos:~$ configure
[edit]
trae@cr01a-vyos# set firewall name INT_TO_LOCAL rule 80 destination address 192.168.253.2-192.168.253.3                                                                                                                                                                                                                    
[edit]
trae@cr01a-vyos# commit
INFO:vyos_config_sync:Config synchronization: Mode=load, Secondary=cr01b-vyos.int.rtr.trae32566.org

@trae32566 Thanks, could you change one file and comment on one check?

sudo nano -c +140 /run/scripts/commit/post-hooks.d/vyos_config_sync

Set comment

# Config sync only if sections changed
#if not any(map(is_section_revised, sections)):
#    return

Same version on both, 1.4-rolling-202307070317. Also, if you can disable 2 factor on my Slack account (tsantiago@us.ibm.com) we can talk in Slack about this (lost my 2 factor app / backup codes).
@Viacheslav

@trae32566 Which version on the remote site?

In T775#151889, @Viacheslav wrote:

@trae32566 Try the same with ip address, I tested with IPv4 addresses

@trae32566 Try the same with ip address, I tested with IPv4 addresses

@Viacheslav Thanks for all the work on this, I'm glad to see it moving along! This doesn't appear to work for me on 1.4-rolling-202307070317; I've configured it for both firewall and NAT and it appears to not be getting triggered (though I've only tried firewall changes so far). Here's the primary side (cr01a-vyos.int) config:

trae@cr01a-vyos# show service config-sync
 mode load
 secondary {
     address cr01b-vyos.int.rtr.trae32566.org
     key <MyKey>
 }
 section nat
 section firewall

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

I tested this feature with the following firewall config:

set firewall group domain-group DG_TEST address 'nu.nl'
set firewall group domain-group DG_TEST address 'www.nu.nl'
set firewall interface eth1 out name 'ETH1_OUT'
set firewall name ETH1_OUT default-action 'accept'
set firewall name ETH1_OUT rule 10 action 'drop'
set firewall name ETH1_OUT rule 10 destination group domain-group 'DG_TEST'

A developer I work with reports this:

After nearly 30 reinstalls the upgrade finally blew up. The issue is in the initial copying of the config file, between lines 182 and 219 in the install script. That's where it happens... what's causing it / how it happens is still unclear...

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

I'm encountering similar issues on upgrade as well: the configuration fails to apply because of a broken config.boot file (incomplete; stops partway through, perhaps a migration issue?)

https://github.com/vyos/vyatta-cfg-quagga/pull/100 I have tried to fixed it. Works on my local system.
But need migration script.

Can we close this task?

Check if it exists in the kernel.

zcat /proc/config.gz | grep PARPORT

@Apachez Thanks!

set system option keyboard-layout se-latin1

Verified in vyos-1.4-rolling-202307060317-amd64.iso but Im biased :-)

Just tried to upgrade from April image and its failed with this error :(

Right, i found in modules ArchLinux support it.

Implementation here:
https://github.com/vyos/vyos-1x/compare/current...jestabro:from-defaults

@cuongdt1994
I installed Arch linux, there is already a parport_pc in the kernel, the device is perfectly defined.
Why it doesn’t work here, I don’t understand, despite the fact that there is no parport module in lsmod

@aztec102 https://github.com/torvalds/linux/blob/master/drivers/parport/Kconfig

Hi @marekm - Hope you are well.

In talking with the vendor, this appears to be an incompatibility with the WiFi card and the coreboot BIOS installed on the device. Tested with a second device that had a different card installed, and no such errors are present now.

basic configuration :

Merged with current: https://github.com/vyos/vyos-1x/commit/8afdb5ad5515a0a1ae716204f397f3d974cec714

In preparing/testing a revised pull-request to fix a merge conflict, with version 1.4-rolling-202307050317, the testing commands need to be slightly modified.

Pull request created: https://github.com/vyos/vyos-1x/pull/2075

Actual file to modify for commit: https://github.com/vyos/vyos-1x/blob/current/interface-definitions/system-option.xml.in

@cuongdt1994 Thanks a lot, I'll definitely check it out.

Verified this particular request by modifying node.def and be able to select se-latin1.

Selectable keymaps are available in /usr/share/keymaps/i386/