|
|
@@ -105,3 +105,51 @@ it's not supposed to do that. Dunno why. Ancient code. Whatever.
|
|
|
|
|
|
In practice, this is so nasty that I'm seriously tempted just to wait
|
|
|
half an hour then blindly click on where the finish button should be.
|
|
|
+
|
|
|
+Possible future direction
|
|
|
+-------------------------
|
|
|
+
|
|
|
+This whole thing is of course a kludge tower. Furthermore, due to the
|
|
|
+size of the installation files, normal Docker image layering would
|
|
|
+mean images at least 6GB larger than they need to be, so we're
|
|
|
+probably going to want to clean all that up then do a save | load
|
|
|
+cycle to squeeze out the garbage.
|
|
|
+
|
|
|
+The whole Xvfb thing is pretty much impossible to debug under `docker
|
|
|
+build`, which is starting to look like a moot point in any case since
|
|
|
+Xvfb is refusing to start in that environment even when everything
|
|
|
+else claims to be right. So, an alternative plan: don't use a
|
|
|
+Dockerfile at all, just use `docker import`, `docker run`, and `docker
|
|
|
+commit`. Overall plan if we were to go this way:
|
|
|
+
|
|
|
+1. Construct initial filessytem content using `debootstrap -foreign`
|
|
|
+ (as we do now) and also untarring the XiLinx source tarball
|
|
|
+ directly. Might as well drop in the handful of small scripts we'd
|
|
|
+ otherwise have to `COPY` from a Dockerfile while we're at this.
|
|
|
+
|
|
|
+2. `docker import` (as we do now, but with all the extra initial
|
|
|
+ content too to create the stage1 image.
|
|
|
+
|
|
|
+3. `docker run` the stage1 image with a bind mount for the Xvfb frame
|
|
|
+ buffer directory, running an `install.sh` script we stuffed into
|
|
|
+ the tree in step 1. This does `apt-get` to fetch packages we need,
|
|
|
+ then does `python install.py` to run our Xvfb driver voodoo.
|
|
|
+ `install.sh` probably needs to set `-e` so we can tell when
|
|
|
+ something failed. Ideally, `install.sh` does everything including
|
|
|
+ throwing away all the stuff we no longer need like the 6GB unpacked
|
|
|
+ XiLinx installation tree.
|
|
|
+
|
|
|
+4. Assuming that `install.sh` et al ran to happy completion, run
|
|
|
+ `docker commit` to generat a new image from the result.
|
|
|
+
|
|
|
+5. [Optional] `docker save | docker load` cycle to garbage collect,
|
|
|
+ assuming that hack still works, whatever other hack (if any) to
|
|
|
+ achieve same goal (gc).
|
|
|
+
|
|
|
+One nice thing about this approach is that it lets us save screen
|
|
|
+images from the installation process, making this a lot easier to
|
|
|
+debug. Unless the internal scripts need it for some reason, we don't
|
|
|
+even need to convert from `xwd` format to something more common, we
|
|
|
+can just `shutil.copyfile()` the frame buffer file and leave the
|
|
|
+results for somebody else to deal with. If anything is going to keep
|
|
|
+those they should probably be converted to png but not critical.
|
