This change allows Liminix to be used as a non-flake input to a flake
by making <nixpkgs> into a default argument.
An example flake that makes use of this is here:
https://github.com/pcc/liminix-flake-demo
We use ifwait to monitor a bridged interface so we can add or remove it
to the bridge by bringing the associated service up or down. However,
bridge related netlink events can cause ifwait to incorrectly consider
the interface to have gone down. For example, nlmsg_type=RTM_DELLINK
with ifi_family=AF_BRIDGE, which is triggered by removing an interface
from a bridge, and does not indicate that the interface itself was
removed. Because a later RTM_NEWLINK will indicate that the link is still
up, ifwait will bring the service down and then up again, triggering
more netlink messages that keep ifwait in an infinite loop.
Fix it by checking specifically for RTM_NEWLINK and RTM_DELLINK messages
with ifi_family=AF_UNSPEC, which indicates an event related to the
interface itself.
This allows a system to be configured to dynamically bring up services
associated with an interface. For example, attaching a USB ethernet
adapter could trigger starting a DHCP client and an additional default
route for failover to an additional upstream.
modprobe will print "builtin" lines for modules that are statically
linked into the kernel, which confuses this shell pipeline. Fix it by
adding a grep for "^insmod".
The specific rollover value is unspecified, but we assume that the other
side is U-Boot which rolls over to 0.
https://github.com/u-boot/u-boot/blob/bb0f3eebb3c196d9b6efbbd1e5aa9b16abbb9ad6/net/tftp.c#L275
This allows for very large images to be transferred, which is sometimes
necessary for running debugging or profiling tools designed for normal
Linux distributions such as perf.
* we need new enough for cmake 3
* but not so new it depends on libubox
This is a "get it working again" patch, not a long-term solution.
Either we should add libubox to liminix or we should find another
dhcp6 client
* it's now a command not a service
* shipper is expected to open() the fifo passed as $LOG_FIFO instead of
getting logs on stdin
logtap determines that remote logs are getting sent when there's a
reader on the fifo it's writing, but opening the fifo as stdin of
s6-tcpclient is too early as it hasn't even connected to the remote
log server at that time
fifo(7) says
Under Linux, opening a FIFO for read and write will succeed both
in blocking and nonblocking mode. POSIX leaves this behavior
undefined. This can be used to open a FIFO for writing while
there are no readers available.
When a process tries to write to a FIFO that is not opened for
read on the other side, the process is sent a SIGPIPE signal.
but ... that doesn't match what I saw, which was that it carried on
writing until the buffer filled and then it blocked or returned -1
(depending on O_NONBLOCK)
Switch to opening O_WRONLY | O_NONBLOCK and retrying periodically
if it fails
dan
Peter Collingbourne
kurogeek