@dmbaturin @syncer @jestabro @thomas-mangin @UnicronNL

It will be in the next rolling (any rolling newer then vyos-1.3-rolling-202006070117-amd64.iso)

Ah, nice! I will update to the rolling release and give it is go soon.

@njh you have been right that command can be quiet handy, but instead of using a logfile we query "journalctl" for the appropriate logs.

Idea: do not generate empty node.def file if there is no <properties> statement.

@mrozentsvayg look at https://community.openvpn.net/openvpn/ticket/360 (this is documented in the code comment right above your change as well). OpenVPN on Linux in server mode with standard protocols doesn't listen on IPv6, just IPv4. We need to force it to bind to a IPv6 socket using these undocumented *6 protocols, then it'll listen on both IPv4 and IPv6. This wouldn't be necessary if OpenVPN listened on IPv6 with the default protocols or autodetected whether the local or remote IPs are v4 or v6 and chose the correct socket type, but it doesn't. Complain to the above ticket 360. We're just working within the limitations imposed by OpenVPN.

In T2550#66208, @jjakob wrote:

What happens when one remote-host is IPv4 and one is IPv6? The proposed fix would leave the protocol as udp6 in that case and the error would still be there.

I agree with the downside of vyos-config-debug; it was provided to allow some analysis when other was not available. What was done before was a straight call to the vyatta backend; what is done now is a essentially what you're suggesting, but in a case where the context of config/configtree is not successfully initialized, hence the failure. This is a good point for analysis, however, and I will restore the behaviour, likely by (a) using a straight call to the backend, and meanwhile (b) investigating if we can have partial context for config/configtree in this case.

Can you ask the user if you want to start the migration failure fallback mechanism on the first boot of the new image when upgrading, and if the user chooses to enable this mechanism, you should let the user select an old secure image (execute the mechanism only on the first boot)?

Therefore when modifying the default boot image (either via 'add system image' or 'set system image default-boot') the script that modifies grub.cfg needs to add its own name to it (easiest to do by adding a comment line to grub.cfg with its menu entry number), so that the failsafe reboot knows into which image to reboot into (it parses out the entry number from the grub comment and sets the default entry to it).

Can you ask the user if you want to start the migration failure fallback mechanism on the first boot of the new image when upgrading, and if the user chooses to enable this mechanism, you should let the user select an old secure image (execute the mechanism only on the first boot)?

I think 'configure; load; commit' is important to make debugging easier and faster. There are issues with the vyos-config-debug method: it needs a full reboot to test every change, which can take minutes (and one may not fix the bug in the first 10 tries even, depending on how sleep deprived one is) and it lacks a easy way to see the scripts stdout/stderr (it is discarded unless we enable airbag's debug log, which is yet another thing to have in mind) as the standard traceback that's logged to /tmp may not be enough to catch the exact error and we need to print some variables to look at them or something like that. But mainly the issue is rebooting is much slower than just doing load/commit.
Can't we just read config.boot into the session config of configtree or config? Wasn't that exactly what was done before? I'm 100% there was a function that read the config.boot file in config.py in case the config system wasn't initialised.

Right, that's obvious. The issue is that we need to know to *which* image to switch to, but it's easy to solve, as I'll describe.

In fact, you may be able to switch the default startup item by simply trying to call the following command, and this corresponds to the following command:

I look forward to your success.

Ah right, then all the things about replacing config.boot aren't necessary. I was thinking that /config was permanent between images, I don't know how I forgot that it lives inside each image separately.

The now standard method of debugging was clarified in T2409, with reference to this ticket (vyos-config-debug); the question here is whether there is any way to use 'configure; load; commit' on failed boot config load --- in the worst cases, no, as the CLI has not succssfully initialized, but will investigate. Changing to bug for evaluation.

You can ask the user before the upgrade operation if you want to perform the fallback on failure function on the first boot after the upgrade, and select an old image that is safe when the migration fails.

The way the current bootup commit works, (I'm not 100% certain, I may be wrong in some parts) is that it first looks if any components of the config require syntax migration, if yes, it backs up config.boot to config.boot.pre-migration-$(date) and goes through the migrator scripts, each one modifying the configuration to bring the syntax up to date, then it saves the new component version string and new config into config.boot, and then commits it. Therefore the config.boot is already migrated to the new syntax even if the commit then fails, meaning you can't simply reboot into the old image and expect things to work, as the old image expects the old config syntax, but the config was already migrated to the new one. We need to replace config.boot with its .pre-migration version before rebooting into the old image.

Yes, let me confirm a few details here ....

Sorry, I don't know if I understand it wrong, but please allow me to express my opinion, but when you install and add a new image from the old image for upgrading, it may occur that it can't be used normally at startup config.boot Configuration (especially rolling update),

@jjakob Thanks for a good summary of one of the issues, namely, not replacing config until 'success' (at least of boot, if not other criteria). Migration does save a backup, but we had recently discussed not doing in place change by default. I would like to assess this in relation to other recent discussions of failsafe and rollback, and then proceed with that compatible change first ...

Please test with the latest 1.3 rolling image if the bug is now fixed.

Perhaps a good way is still for the user to choose whether to reconfigure or restart with the old image.

Sorry, I don't know if I understand it wrong, but please allow me to express my opinion, but when you install and add a new image from the old image for upgrading, it may occur that it can't be used normally at startup config.boot Configuration (especially rolling update), in which case, whether or not the old config.boot There is no intention to make any migration or modification Justice. Either the configuration syntax has been changed and errors still occur after migration, or some settings of the system image have problems. A better solution is to modify grub's default boot so that it can boot from the old normal system image, if it exists, but this requires user authorization.

In T2551#66297, @dsummers wrote:

@c-po Woops, as of vyos-1.3-rolling-202006052325 now the problem has switched.

Now the "prefix ::/56 infinity" stanza is in the configuration file, but now the other parameters are not being put in.

@dsummers Do you have a section in your config for router-advert? I'm still struggling to get my Comcast business connection to delegate me an ipv6 prefix and then to have that be routable (my local interface gets a /63... wtf?!)

@c-po Woops, as of vyos-1.3-rolling-202006052325 now the problem has switched.

@richardpowellus Yes, your work around fixed my problem and I'm now for the first time able to receive a /56 from my ISP and divvy it up between my interfaces.

@richardpowellus Yes, your work around fixed my problem and I'm now for the first time able to receive a /56 from my ISP and divvy it up between my interfaces.

Fixed in the rolling release from 20200606xx

In T421 @richardpowellus mentioned:

@richardpowellus I've noted the exact same issue in T2551.

Richardpowellus: I may be running into the same issue. What does your
id-assoc pd 2 { } section look like?

I seem to have figured out my problem. It seems like setting "set interfaces ethernet eth1 dhcpv6-options prefix-delegation length 60" is not working (eth1 is my WAN interface that's connected directly to my cable modem in bridge mode).