PR https://github.com/vyos/vyos-build/pull/484

See also forum thread @ https://forum.vyos.io/t/grub-menu-fails-to-load-on-serial-only-devices-with-no-kvm/

In T5814#171114, @Apachez wrote:

On the other hand I would expect someone aka the admin who will configure an enterprise firewall such as VyOS could be called to have at least SOME basic knowledge and also some interest to read the documentation on how to configure the firewall.

I tried manually loading this config in a VM and I'm still not sure what's causing the issue, maybe something isn't waiting properly for bonded interfaces to be created?:

vyos@vyos# load config.boot-cr01a-vyos.20240109_232428
Loading configuration from 'config.boot-cr01a-vyos.20240109_232428'
Load complete. Use 'commit' to make changes effective.
[edit]
vyos@vyos# commit

In T3871#160827, @jestabro wrote:

@stingalleman As mentioned above (and confirmed in discussions earlier this week), we've had few if any reports of issues with the udev approach, so we would be very interested to hear details of your case.

@himurae, Permission and ownership of config directory and files and fine. If you are still seeing the DHCP leases not being created, something else is probably going on.

Put in the PR for this at https://github.com/vyos/vyos-1x/pull/2780

Could for example be that set system options logtoram enables the feature while set system options logtoram size 32M sets the desired size where the default is 32M or whatever would be needed as a sane minimum.

Maybe making the size of the ramdisk configurable via CLI would be wise? I feel that there's enough variation in hardware configurations out there that hard-coding a value would cause problems.

On the other hand I would expect someone aka the admin who will configure an enterprise firewall such as VyOS could be called to have at least SOME basic knowledge and also some interest to read the documentation on how to configure the firewall.

As a side comment, the new firewall system allows more granular control and sometimes may simplify configuration. It follows better the lower level logic of nftables.

Yes, I agree with that, readability will be better if everything is in order.

I suggest changing order just as a cosmetic fix: feels more reasonable/readable to parse first "incoming", and then "outgoing"

@n.fort
Looks like 1) and 2) is correct, as well as 'Action=accept in vyos command shall remain as accept in nftables'.
However, the 3) is not obvious to me. As long as all rules with Action=Accept in both IN and OUT chains will migrate to Action=return, looks like there should be no difference in order, other than probably for performance reason.

I stopped using conntrack-sync before I moved to 1.3 (which I am currently running) so I can't confirm either way.
I expect it's no longer an issue though and this task can be closed.

Should be a non-issue with the new firewall implementation.

Changes that seems to be needed only in migration script https://github.com/vyos/vyos-1x/blob/current/src/migration-scripts/firewall/10-to-11:

• Use accept action for base-chains (it's done, no change needed here).
• Migrate action=accept to action=return on every rule.
• fix order and ensure all "in" rules are applied first.

vyos-vm-images will soon be phased out completely.

This issue is on and off, but mostly solved now.

This needs to be properly worded as a feature request, if it's still relevant with the new firewall implementation.

No longer reproducible in 1.5

The CLI prevents that now.

Someone needs to test it on a system with a real wireless NIC.

The script was rewritten and adds all servers now.

I presume it's no longer an issue, but I'd like to confirm.

No longer reproducible, the underscore is displayed as expected.

If any new information turns up, feel free to reopen.