Surprisingly frequently, the firmware stacks split right after the \x1b byte in
sending data down. Defer a dangling partial sequence until more data
comes in that should make it complete.
In the interest of interfering with terminal behavior as little as possible,
only apply the forced intensity if the background and foreground color are
identical and would make it otherwise literally impossible to read
when working as designed.
Terminals seem to expect 'bold or intensity' to imply intense color.
There are certain terminals that steadfastly refuse to do bold and intense. So implement the logic on behalf of
the remote terminal.
Commonly, UEFI setup menus request bold white text on white background. This fixes such menus to be readable by explicitly requesting intense white foreground rather than normal background. For example, the kitty terminal has no 'intense on bold feature.
For nodemedia, nodelicense, and nodefirmware, support
for expressions in filenames was
fouled when pass by
filehandle was added.
Restore this by adding all the files matching an expression.
The stock Ubuntu approach was inadequate. It would DHCP out every nic and take the fastest result, and no going back.
Now the CDC nic can frequently win that race.
First, rmmod cdc_ether, as a scenario that is completely right out.
But beyond that, let Ubuntu have one shot at multi-nic bringup. Beyond that, maintain a list of all link-up devices.
If the check should fail, then start doing one nic at a time, cycling through them.
Also, the openssl s_client timeout is painfully slow, use subshell and kill to speed up things.
When network configuration is applied, wait until we
can reach the deployment server again before exiting.
This should make us more robust against various potential delays after
changing the nature of network interfaces.
Some OS deployment mechanism may wish to convey the identity information more loosely. For those, it's convenient if the files are loose instead
of needing extraction from a VFAT image.
Provide a totally 'clortho' and 'copernicus' free behavior.
This allows some flows to skip the cpio addons to go straight to python.
Some scenarios demand the utilities (initramfs) and others are more awkward with the utilities,
so we enable both.
Recognize BFB embedded OS as a potential osdeploy target.
This is toward the end of identifying the appropriate 'addons.cpio' for setting up for a bf.cfg driven bfb install.
For now, it is disabled until companion os category exists.
Apart frem the gc_thresh indirect check, perform other checks.
For now, just highlight that tcp_sack being disabled can really
mess with BMC connections. Since the management node may have high speed and the BMC may be behind a 100MBit link, SACK
is needed to overcome the massive loss and
induce TCP to rate limit appropriately.
Some platforms can have a very slow category,
like disks. Give CLI a way to ask for the desired
categories and a chance to optimize away the uninteresting.
