When invoked from a context like this...
my-infix-spin$ make O=x-my-build x86_64_defconfig
...where the spin's Makefile would trigger the generation of the
defconfig based on some fragments, the value of O passed via the
environment would be ignored since the spin's Makefile typically
overrides it.
Therefore, pass it as a make variable instead, which takes precedence.
On platforms based on CN913{0,1,2}, collect all ECC related counters
so that we know if any correctable errors have been encountered since
the most recent boot.
Allow particular boards or platforms install hardware specific scripts
in /etc/support.d, via the usual /usr/share/product logic, which are
then run by /sbin/support and included in the resulting bundle.
This lets us collect hardware specific information, e.g., SoC-specific
error counters, without /sbin/support needing to know about all the
nitty gritty details.
Verify that if the system encounters a hard lockup, i.e., interrupts
are no longer being serviced, then the system's watchdog will
correctly reboot it.
Rev. A has a FLASH that Linux reconfigures to 4B-addressing, but must
be in 3B-addressing when accessed by the BootROM. Since it has no
reset input, this would not work on warm resets. Linux has a
workaround for this issue for the common case of a controlled reboot,
which this change enables on those boards (which are admittedly few
and far between, but still useful as testing vehicles).
(This won't take effect until Finit is updated to at least 4.15, which
switches over from watchdog- to reboot(2)- based reboot, by default)
By default, ensure that the target device accepts TCP connections on
the specified port before returning the device object. This aligns the
SSH implementation with {NET,REST}CONF.
This solves the issue where tests that use SSH commands early in their
execution would sometimes fail as the remote server had not started up
yet.
After merging post-post-image, TRUSTED_KEYS must be set in order for
the keys to be injected into the U-Boot DTB, so we need to explicitly
enable it for all boards that use the generic secure boot scripts.
This was a stray config fragment used during development that was
accedentally included in the referenced commit.
Fixes: 0fe5964909 ("aarch64_qemu_boot: Restore build after removing post-image.sh")
Previously, post-image.sh was able to create QEMU images from an
existing release tarball. This was useful when you wanted to test a
new bootloader build without having to wait for a full Infix build.
Restore this capability by adding a separate image target for it, and
then allow image-itb-qcow to source its input images from that instead
of a locally build squash+aux.
Limit support to x86, like we do on the "official" appliances on the
marketplace. Aarch64 has never really been used AFAIK.
Avoid the os-release import, since all that info is not important now
that these appliance files are only for development scenarios. In all
other cases, the official one, based on a proper release, should be
used.
We have not installed .dtb:s to $O/images/ for quite some time, and
nobody cared. That goes to show that this is not really used.
The image is still useful at times, so if it needed in the future,
then we can resurrect it from the logs and refactor it to an image
package.
Add a generic image target to build aux.ext4, which can be used both
when creating target-specific SD-card images, and when creating
regular disk images.
While we're here, make sure that we don't need a RAUC bundle in order
to generate aux.ext4 (which mkrauc-status.sh did). This saves us time
on _every_ incremental build.
Rather than using the creation of a signed image as a proxy for
whether the trusted keys should be installed RAUC/U-Boot's trust
stores, use the dedicated option.
The board/*/*/*.mk is very broad, intended to hit all board specific
definitions, but may also cause duplicate inclusions, e.g., in
board/common.
Let each architecture do the inclusion instead.
A bunch of different artifacts should follow the same naming scheme,
depending on a bunch of config settings + whether we're building a
release or not.
Therefore, provide a single definition of this that we can reuse to
name disk images, upgrade packages, etc.
This will make sure to apply NACM rules for all the data. It also
makes it possible for a luser access a subset of the data, even if
they to do not have read access to /cfg/startup-config.cfg.
In setups like this...
CPU
eth0
|
.----0----.
| dst0sw0 |
'-1-2-3-4-'
|
.----0----.
| dst1sw0 |
'-1-2-3-4-'
...both eth0 and dst0sw0p4 are DSA ports. But the latter is _also_ a
physical port as far as devlink is concerned. As a result, it would
first be marked as "internal" and is then instantly reclassified as a
"port".
Catch this condition and stick with the initial "internal"
classification.
In addition to matching on interface names, add support for matching
on ethtool information.
Example:
{
"@ethtool:driver=st_gmac": {
"broken-mqprio": true
}
}
This would mark any interface using the "st_gmac" driver as having a
broken mqprio implementation. Whereas this:
{
"@ethtool:driver=st_gmac;bus-info:30bf0000.ethernet": {
"broken-mqprio": true
}
}
Only matches an st_gmac-backed interface at the specified location.
As matching becomes more complicated, use the shell implementation
from confd as well, to make sure that they are always in agreement.
The defconfigs for all architectures other than x86_64 has this
enabled, so align it with the rest.
This has no on-target impact, but it enables us to attach to a live VM
instance and debug it, or do offline debugging like resolving stack
trace lines from oops messages to source locations.
Some netdev drivers, e.g. the FEC found on many i.MX SoCs from NXP,
will detach from their PHYs when configured down.
This means that when confd tries to configure L1 settings for the link
before bringing it up, ethtool fails - since there is no PHY to talk
to.
For interfaces that behave this way, delay the configuration until
after NETDAG_INIT, when the interface is brought up. This is not
optimal, since we are generating needless noise for the link partner,
which is why we only fall back to it as a last resort.
Fix#951
Ideally, all drivers should behave the same. Alas, that is not the
world we live in. For quirks that we can not reliably probe for in any
other way, let products supply a JSON file that declares them.
CID 507415 from coverity was the origin for this change. As it turns
out, the unreachable MAC address generation for VXLANs was hidden by
the generic setup (netdag_gen_link_addr()) saving the day. That is
likely something we want to phase out though, so the VXLAN code should
stand on its own.
Align the GRE code while we're here, because why not? :)
Do not allow the topology matcher to setup a LAG where one link is
running at 10G while the other one runs at 1G, since the bond will
never use the 1G port as long as there the 10G link is up.
To run LAG tests on hardware, we have to make sure that the chosen
links are running at the same speed. We do not want to require a
specific link speed from the logical topology, as the real requirement
is merely that the two (or however many) links are of the _same_
speed, not any _particular_ speed.
Rather than having to complicate the topology matcher, let it take
care of the common pattern of matching requirements to provided
features, then let tests pass custom node/edge matchers for the
complicated cases.
The management of custom-phys-address was made more complicated by the
fact that physical interfaces require restoring the permanent address
when a custom setting is removed.
Simplify this by moving the restoration to the delete path, so we only
have to worry about if there is a custom mac or not during interface
setup.
Also:
- Fix some legacy naming on *_gen() functions
- Fix custom-phys-address on dummy interfaces
Fix#938
Before this change, interface dependencies were only setup when
interfaces were created. This led to problems in flows like this:
1.
configure
set interface br0
set interface br0.10
leave
2.
configure
set interface dummy0
leave
2.
configure
no interface br0
no interface br0.10
leave
Since neither br0 nor br0.10 was created in (2), no dependencies were
setup. Because of that, when the deletion scripts from generation (2)
are generated when entering (3), dagger is free to execute them in any
order. This means that it may choose to remove br0 before br0.10,
which will mean that br0.10 is already gone when we try to remove it.
Therefore, make sure that we generate the full dependency graph on
every iteration.
Also, get rid of the need to keep on-disk state for VETH pairs, and
use the name as a descriminator for which side to create/delete.
With the new iftype enum, we see that configuring an existing dummy or
gre interface types was wrongly classified as an error rather than as
a NOP.
Example, before this change, this was OK:
configure
set interface foo
set interface foo ipv4 address 10.0.0.1 prefix-length 24
leave
However, this was not:
configure
set interface foo
+leave
+configure
set interface foo ipv4 address 10.0.0.1 prefix-length 24
leave
+<KABOOM>
This has multiple advantages:
- Less chances of typos is repeated "infix-if-type:foo" strings
scattered throughout the code
- We can lean on GCC's `-Werror=switch` to make sure that iface
specific logic always handles all types (which was not always the
case - see follow-up commits)
- We can potentially create a `struct afspec_ops` in the future, which
could then be indexed by this enum
The only interfaces that would be in difs, but not in cifs, are
deleted interfaces. But these will be removed from the exit action of
the previous generation, and will never be referenced in the new
generation.
Tobias Waldekranz