8d910d10f8
tgtd returns execution control and backgrounds itself almost immediately and before it has made it's listening socket available. This can cause a race condition as the tgtd socket is not available when tgtadm is run, resulting in an error: failed to send request hdr to tgt daemon Add a function to check if the socket is available before moving on to calling tgtadm, and a wait_for helper function we can use. We'll check for the socket every 0.5 seconds, for up to 5 seconds. I'm seeing this issue on almost every deploy using a ramdisk built from Fedora 20. I'm not sure if something has changed in tgtd, but this behavior is documented since Fedora 18 at least. In the systemd script for tgtd, there is actually "sleep 5" to work around the problem. See Also: https://bugzilla.redhat.com/show_bug.cgi?id=848942 Change-Id: Iffa9fc63393309ca653d592dff17316ecbea3e09 |
||
|---|---|---|
| .. | ||
| cleanup.d | ||
| extra-data.d | ||
| init.d | ||
| post-install.d | ||
| README.md | ||
This is the ramdisk element.
Almost any user building a ramdisk will want to include this in their build, as it triggers many of the vital functionality from the basic diskimage-builder libraries (such as init script aggregation, busybox population, etc).
An example of when one might want to use this toolchain to build a ramdisk would be the initial deployment of baremetal nodes in a TripleO setup. Various tools and scripts need to be injected into a ramdisk that will fetch and apply a machine image to local disks. That tooling/scripting customisation can be easily applied in a repeatable and automatable way, using this element.
See the top-level README.md of the project, for more information about the mechanisms available to a ramdisk element.