I’m running into an issues revolving around my configuration taking and working during configuration and subsequent running, but not when the system is rebooted. This error is found on the 1.5 rolling as well as an iso I built of 1.4 on 12/1/2023.
I’ve tried to do the vyos-config-debug and vyos-debug commands in the grub command line and I’ll paste the files here to hopefully help y’all solve the issue or at least understand what is going on. Let me know if you’d like the cfg-stdout.log file. It’s way to long to paste here and the last time I rebooted it to get this output the cfg-stdout.log file was empty.
If this post isn’t finished initially it’s because I want to get to the full editor before I start pasting things in, and I need to do some santization of keys before fully posting.
I had to create a pastebin due to the content being too long: Pastebin.com - Locked Paste
password: MenY18Wams
I found that the issue was related to using the pseudo-ethernet interface on the ddns configuration allowed the config to work like it should after a reboot.
It may be a good idea to relax the error on commits when an interface doesn’t exist on the system but does exist in a ddns configuration. The firewall comes up just fine before interfaces are brought up and that must be due to a less strict checking of interfaces.
@greenman1969, As I stated in the previous conversation with @marc_s, going with address web is almost always a more stable solution instead of depending on dynamic/lazily initialized interfaces.
Besides avoiding the usual pitfalls of inadvertent user error, this also safeguards against the fragility of the underlying ddclient library.
Having said that, I’ll explore possibilities to see how we can have a middle ground – either a warning (won’t be super helpful in a headless router in prod environment) or some way to not start the service at all (as implemented in container).
A middle ground would be good. It worked in previous versions of VyOS (I had a version running from June / July that it worked fine on). The only thing I have as an issue with using web is that in my case it needs to rely on a third party service that I don’t control or own, when I set it based on the interface IP address it’s something I can control and I don’t have to worry about the third party service going down and my DDNS entries failing to update due to that. You could operate under the assumption that the interface ddns was defined on had to have existed during commit otherwise the initial commit before the save would have failed, thus a warning on boot up to just say that the interface hasn’t been set up yet but it should exist by the time the service is started.
The simplest solution would just be to ensure that interfaces are always instantiated before the ddns cofiguration is read to prevent the non-existing interfaces error when they’re interfaces that don’t exist on the host by default (bonds, pseudo-ethernet, pppoe, etc).
From reading the PR it doesn’t address Pseudo Ethernet interfaces so it wouldn’t be helpful in my specific case. I wonder if it could just be an option in the ddns configuration to do a skip_boot_check: true and a note in the documentation about interfaces that don’t exist at boot time.
As for me it is a bad idea. Until we don’t understand the cause of the issue.
As other interfaces could be also affected. And this way you just hide the problem.
@Viacheslav agreed 100%. The PR has been adjusted based on your recommendation, As I said, I don’t have a way to verify the order of peth creation or whether peth is a persistent interface.
The obvious cause is that subsystems which relies on that the pseudo interface is up is runned before the pseudo interface has been configured and exists.
Which is why the config works perfectly fine once the VyOS box has finished its booting but not when the same config is saved and runned during boot.
So some config segment dependency have to be reordered (if possible - could also be some hen vs egg situation if we are unlucky).
The followup question for that might then be what happens when the interface gets updated later on for whatever reason (like considered down if the opposite part disconnected as with tunnel interfaces for ipsec/wireguard etc)?
On the other hand that situation exists already today since configuring this subsystem (DHCP, DNS etc) after the VyOS box finished booting works perfectly fine.