https://github.com/vyos/vyos-1x/pull/2773

Well, the webserver is for an API - if you wan't to server files you can either use the default document root, or spawn a container. We should focus on packet pushing and administration.

https://github.com/vyos/vyos-1x/pull/2773

The errors here were fixed in:
https://vyos.dev/T4052
https://vyos.dev/T4053
in equuleus and subsequent.

The new firewall implementation by Nicholas et al. supports bridge firewalls.

I suppose with the new firewall implementation, this is no longer relevant.

With the migration to nftables, I suppose this is not relevant anymore.

With the current smoke test infrastructure, I'm inclined to call the original task resolved.

Neither 1.1.8 nor Crux are supported anymore.

I presume the issue is no longer relevant since people do successfully use QAT now, but feel free to reopen if anything.

If the issue is still relevant, feel free to reopen.

I suppose the current PKI CLI does fulfill the requirements of this task.

Just to clarify the issue: note that one can specify the choice of serial console during the 'install image' process; are you not seeing the boot messages with this setting ? or are you unable to set it during installation ? Thanks.

I don't think anyone saw this issue lately, but if it resurfaces, feel free to reopen the task.

Now that 1.4 is about to be released and 1.3 going into maintenance mode, we definitely will not include it in 1.3.6.

User creation works fine now.

Yes.

Yes I tested again upgrading with today's latest rolling release no ip address is served to clients so issue persists no changes

The dynamic DNS system has been revamped since then, so I assume this is no longer an issue, but feel free to reopen if it manifests again.

I'm closing this since no new details surfaced. If it's still relevant, feel free to reopen.

1.2 is now EOL, so no new changes will be made there.

Multiple people report both working UDP offload and firewall configurations, so I presume this issue is no longer relevant. Feel free to reopen if new details surface.

The same problem (container config does not get loaded) occurs, when DNS is not available for whatever reason.
This must not prevent the current container settings to be online.

I think I found the problem.

The first thing could be that the container cannot connect to the registry as it happens before static routing (not sure).

vyos@r4# /opt/vyatta/sbin/priority.pl | match "container|static"
450 container
480 protocols/static
481 vrf/name/node.tag/protocols/static
[edit]
vyos@r4#

Thanks Viacheslav

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

Hi, this bug is introduced again in VyOS 1.4 (tested VyOS-1.4.0-rc1). Due to the following commit: https://github.com/vyos/vyos-1x/commit/64c9fdef02323309e97b2bb682604ada52d651e8

Ok the file does not have the Release version in config and migration do anyway
https://github.com/vyos/vyos-vm-images/blob/current/roles/install-config/templates/config.boot.j2

vyos@ci-router1# cat /config/config.boot.2024-01-08-083418.pre-migration 
nat {
    source {
        rule 100 {
            translation {
                address "masquerade"
            }
            outbound-interface {
                name "eth0"
            }
        }
    }
}
interfaces {
    ethernet eth0 {
        address "dhcp"
        hw-id "52:54:00:ff:97:48"
        mtu "1500"
    }
    loopback lo {
    }
}
service {
    ssh {
        client-keepalive-interval "180"
        port "22"
    }
}
system {
    config-management {
        commit-revisions "100"
    }
    host-name "ci-router1"
    login {
        user vyos {
            authentication {
                encrypted-password "*"
                plaintext-password "vyos"
            }
        }
    }
    ntp {
        server "time1.vyos.net"
        server "time2.vyos.net"
        server "time3.vyos.net"
    }
    syslog {
        global {
            facility all {
                level "notice"
            }
            facility protocols {
                level "debug"
            }
        }
    }
}

The issue with the missing domain name in /etc/hosts with hostfile-update, as mentioned above, seems to trigger another problem. The hostname requested by the client seems to be added to /etc/hosts verbatim and some clients (eg. some Windows machines and printers) request a fully qualified name with a trailing dot. Since pdns-recursor unconditionally appends a dot, there are now two trailing dots, causing pdns-recursor to crash if it restarts.

I said it in the PR, but I'll say it here too -- I really don't have an idea, nor do I have enough knowledge of the codebase to get debugging data. I suspect that partprobe is either getting an error back from the kernel or is throwing its own error, and partx isn't. if I could step through the process and look at a couple things (like, is some partition actually mounted when partprobe runs, which could trigger this?) I would, assuming I've got the spare cycles. I don't at the immediate moment, and especially not to run through the code to try and figure out debugging on my own. Even being told "set debug here, here, and here, then retry the install" would help.

Is this still an issue on newer rolling images? This PR addresses ownership issues in /config on system update: https://github.com/vyos/vyos-1x/pull/2731

How come partprobe fails but not partx?