Bootstrapping a system with D-Bus using Finit will create the machine-id
file /var/lib/dbus/machine-id, this can be used as the unique machine-id
for services like RAUC, so let's set that as /etc/machine-id to reduce
the log spam we get otherwise:
Nov 7 06:18:08 test-05-25-f8 rauc[5512]: Failed to get machine-id: Failed to open file <E2>M-^@M-^\/etc/machine-id<E2>M-^@M-^]: No such file or directory
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
After the initial probe, set up all port leds:
- Disable all LEDs
- Enable netdev trigger for all green LEDs (tp + sfp)
- Enable link statux and rx/tx activity
- Skip all aux LEDs
Also in script, a neat little flash function that can be used both for a
production test, to verify all LEDs work, and at runtime to locate the
device in a rack of devicess.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
On Rev. B, the second LED on the copper ports is green instead of yellow.
This patch renames them from yellow -> aux => <device>:aux:tp
Also on Rev. B, the second LED for SFP ports do not work at all. This
patch drops them from the device tree to avoid confusion.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Some services launched at bootstrap must be possible to override per
product. One such service is iitod, which manages the LEDs in Infix.
This change makes allows a product specific init script to clear the
led condtion, preventing Finit from lauching iitod. Also, rename the
ixinit-done condition to match the nomenclature used already.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This patch use the new compatible array in /run/system.json, installing
in order, least to most significant product overrides.
We also introduce a new way to run product specific scripts at init, to
override default behavior in Infix, e.g., LED control.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This is to workaround #807. To test automatic router id selection
a new test is required, which sets interfaces and activate ospf in
separete NETCONF/RESTCONF query.
Initially done as a workaround for the MACVLAN create/remove race. But
even though the old version of this test now works, this refactor
provides better test step descriptions, making it easier to follow for
anyone looking to manually verify the functionality.
This is a specialized namespace, containing two ports,
which (hopefully) acts as completely transparent "bump-on-the-wire"
bridge.
Useful in scenarios where you want to test what happens when the flow
of packets between two nodes is disrupted. E.g., for testing fail-over
behavior in dynamic routing protocols, L2 redundancy, VRRP etc.
Now that we're using the `passthru` mode of MACVLANs, it seems we can
rely on the parent interface's promiscuity going down to 0 as an
indication that the kernel has completed the removal of the interface,
and will accept the creation of a new one.
When used as a context manager, __exit__ will be called even though
__enter__ might throw an exception half way through. So there is no
guarantee that the instance is on the cleanup list when we get to
stop().
This mode let's us receive all packets from the parent device, which
is automatically set in promiscuous mode, and let's the MACVLAN
transmit packets with any SA, which we need to implement a TPMR (or a
bridge or anything else we might dream up)
This is needed to create namespaces with MACVLANs from different
parent interfaces. The first consumer will be a Two-Port Mac
Relay (TPMR), so that we can control the flow of packets between two
nodes.
Story time:
In the days of yore, we generated PCAPs using tcpdump, which will
flush any buffered packets to its output file on reception of
SIGUSR2. Therefore we sent a USR2 before terminating the capture.
At some point, we switched over to use tshark to capture packets for
us, but the SIGUSR2 sayed in place.
It turns out, tshark will just die on USR2, abandoning the dumpcap
child it has created, which means the enclosing network namespace
can't be properly torn down.
Therefore:
Remove skip sending USR2 and just send TERM directly.
Backport support for saving and restoring system time from a file on
systems with broken RTC that reset to the future.
With this support a system can be sure time only ever moves forward.
Fix#794
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
The string variable handling in configuring Finit did not follow the
Buildroot best practises. This patch adds stripping quotes from all
string variables before adding them as configure arguments.
This fixes issue with, e.g., this sneaky bastard:
configure --with-rtc-date=""2024-10-12 12:34:56""
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Joachim Wiberg