Disabling all validators for both vyatta-cfg and vyatta-op bring the boot time down to approx 73 seconds.

Modifying node.def (comment out "syntax:expression:") recursively in the paths of:

Moving along in the blamegame I will after a tip try to disable the various validators being runned.

Any updates to this?

Can be related: https://vyos.dev/T2431

Continued debugging by also modifying /usr/libexec/vyos/services/vyos-configd by adding:

Attempted some debugging on this issue.

According to https://man7.org/linux/man-pages/man7/capabilities.7.html this capability can load, unload AND delete kernel modules.

Still occurs for:

PR created: https://github.com/vyos/vyos-build/pull/392

Verified working with VyOS 1.4-rolling-202309030023.

Was missing quotes around the variable within lb_config_tmpl like so:

Some further testing:

Reference to https://jonathancarter.org/2015/04/06/squashfs-performance-testing/ using 1M blocksize will give approx the same readspeed as with default 128k blocksize but result in an even smaller file.

Regarding filesystem.squashfs the changes through changed mksquashfs syntax are:

Was missing quotes around the variable within lb_config_tmpl like so:

The firewall refactoring released 4th aug 2023 only (so far) took care about the documentation in the configuration section:

PR created: https://github.com/vyos/vyos-build/pull/391

PR created: https://github.com/vyos/vyos-build/pull/390

PR389 build failed:

PR created: https://github.com/vyos/vyos-build/pull/389

There was a similar case where it turned out that INPUT/OUTPUT chains for the firewall must be updated to include the stuff VRRP is doing.

Reported in: https://forum.vyos.io/t/error-show-dhcp-lease/12030

See this task instead: https://vyos.dev/T5536

1. Error in show firewall group:

I can confirm that I experienced the same thing with update to VyOS 1.4-rolling-202308310021.

I assume backports will be used once VyOS 1.3.4 gets compiled?

PR1 didnt seem to have any affect on this night build:

PR created: https://github.com/vyos/vyos-live-build/pull/1

Can be resolved by route-map acting on community (for example <ASN>:888) and setting nexthop to 192.0.2.1 (optional tag 666) or for IPv6 set nexthop 0100:: along with a static route where 192.0.2.1/32 and 0100::/64 have null0 as nexthop.

Some tests on filesystem.squashfs from VyOS 1.4-rolling-202308280021.

A note from https://forum.vyos.io/t/clear-logs-on-vyos/6878/10?u=viacheslav that there might be issues if removing directories from within / var/log/* doesnt occur to PR381 since that PR was specific about which files and directories to remove when it comes to / var/log. That is only files NOT directories were removed from / var/log.

A baseline could be to look at the linux kernel config used by Alpine Linux for their RPI-builds:

Just a comment:

So how are all the other helpers added to the ruleset if not dynamically?

Then how come these helpers are always enabled as pointed out at https://vyos.dev/T5080#149232 ?

How come these helpers (pointed out by @saintclairpcarvalho but also )https://vyos.dev/T5479) are always enabled?

Found some anomalies regarding show firewall command (I assume related to the refactoring) which I have reported in https://vyos.dev/T5513

The refactored firewall frontend uses rule numbers as described in: https://docs.vyos.io/en/latest/configuration/firewall/general.html#firewall-rules

PR created: https://github.com/vyos/vyos-build/pull/381

Using VyOS 1.4-rolling-202308250021.

The file list_ntp_servers.sh is nowhere to be found in VyOS 1.4-rolling-202308250021:

I assume this will fix by itself if you build your own 1.3.3 LTS from sources today since 1.3.3 LTS was released in june 2023:

I guess this can be closed by reason "Not a bug" or similar?

Isnt this resolved now by the commit of @c-po at 2 aug?

Using VyOS 1.4-rolling-202308250021 the option "config-trap" is no longer to be found and the remains of config-trap causing commit to crash with a traceback have also been fixed:

Confirmed fixed in VyOS 1.4-rolling-202308250021:

@rherold Well thats how it is today with default-action:accept where ALL ports are open to ALL services on ALL interfaces.

Related: https://vyos.dev/T5471

Yes but if you have more than a few rules its shitty to have to do this manually.

Then perhaps add it as an global-option or similar to make life easier for the admin to not having to dig into how each service should have the firewall configured in order to make it work properly?

@giga1699 Again, if I as an administrator enable BGP and configure it with "neighbor x.x.x.x" I expect this to work without having to setting up multiple additional firewall rules on my own. Same goes with if I enable DHCP-server on the VyOS - I expect it to work.

PR created (which replaces previous PR 378): https://github.com/vyos/vyos-build/pull/379

PR created: https://github.com/vyos/vyos-build/pull/378

Include VyOS functions

source /opt/vyatta/etc/functions/script-template

Verified being fixed in VyOS 1.4-rolling-202308230020.

So where should this be filed instead?

Related: https://vyos.dev/T5388 (Something is fishy with commit and boot times when more than a few hundred static routes are being used).

The following is for example made up by migration:

So the bug is that "boot=live" is being used when installing VyOS to a harddrive?

@giga1699 There are already plenty of hidden stuff going on if you take a look at the output of nft -s list ruleset.

Yes, that output seems to have the snmp module (which exists in /usr/lib/x86_64-linux-gnu/frr/modules/) loaded.

Comparing with other vendors thats what you use the ACL for.

A dirty workaround would be to include a "hidden" (as in it exists in nft but not displayed in the vyos-config itself) CoPP table which includes the port(s) needed for:

As seen on slack and I think on the forum.

Perhaps same workaround as firewalld is implementing through option "IPv6_rpfilter=yes" could be implemented in VyOS (both uses nft)?

Possibly the fib statement can be used through nft:

Looks like you would need some more extensive checking of that partition.

I have created this task regarding the fsck issues (fsck does not run during boot): https://vyos.dev/T5498

In PR 2152:

Works for me without errors but I currently only have an empty ruleset: