So far, we have had two classes of HPC Fundamentals, and both have been equally interesting and engaging. I must admit that I was surprised in the beginning when we were tasked with setting up our own desktops and “customizing” them (to a degree at least) to our own preferences. I definitely feel more of a free setting in this class compared to Unix Fundamentals. Not that Unix wasn't free, but this class seems to have a little more leeway when it comes to structure, which is nice.
Our first class dealt with opening up our machines, and taking a tour of the inside. I am not unfamiliar with computer hardware, but I still learned a good deal. We talked about graphics cards, ram, HDD, the motherboard, and the like. I have always wanted to custom build a machine of my own, and this only reinforces that goal.
Our second class dealt with the operating system that we would be running on our setups. Most of us went with Debian, either for preferred reasons or simply lack of another system to use due to inexperience. ie me. I have toyed with Ubutu before, but not very much in depth. From what I have seen, the two OS's are very similar to each other in respect to how the perform graphically. Other than that, I have no clue. I guess I'll find out. At the end of the class, all of us ended up with the operating systems installed and ready to go. The only real problem that we had was with our dual head setups. Instead of extending the displays like we wanted and anticipated, the screens were only mirrored. When we attempted to change this, we received an error every time. After about 20 minutes of screwing around with the machines, we found a linux forum that helped us with the issue. The internet is amazing. I'll try and find the article and post it later just for reference.
This week, we went through the introductory phase of LFS, or Linux from scratch. The idea behind this is to create a pure, unadulterated build of linux. In doing so, we would be able to really get a conceptual understanding of how linux works and operates in its natural form.
This was the link we are using to guide us through the process: http://www.linuxfromscratch.org/lfs/view/stable/
From here we began the process of creating a linux build on our respective machines. We first had to partition a 10GB section of our hard drives for the build. The partition was located in the directory /dev/sda3. the file type was ext4, which is the latest and most up to date. The /dev/sda3 was important for later, when we had to mount the file system for use.
This week we worked on adding files/programs to our lfs build. These programs were done in sequence, and are still being installed. The extraction/install process is a very long one that takes around 15-20mins on average for the whole process. This is also just for the first passes. The second ones have yet to come. The process kind of reminds me of the whole “hurry up and wait” saying.
Friday the thirteenth. What's so special about this day again? Anyways, this week we continued to work on the lfs build, continuing to compile the various programs. The test suites are generally ignored, because they are optional the first time around, and therefore skipped in order to save time. I'm still getting used to the ins and outs of installing and compiling. I tend to make the simple mistake of not being in or creating a dedicated build directory for the source files to compile them. Hence many of the errors I received in the beginning could be attributed to this. However, I faced a different error when attempting to install glibc-2.20. The error code is listed below:
/usr/bin/install -c -m 644 include/limits.h /tools/include/limits.h /usr/bin/install: cannot create regular file `/tools/include/limits.h': Permission denied make[1]: *** [/tools/include/limits.h] Error 1 make[1]: Leaving directory `/mnt/lfs/sources/glibc-2.20' make: *** [install] Error 2
I have since moved on from glibc-2.20 and have been installing other necessary programs such as bash, xz and texinfo. I also learned about the idea of “stripping”. This is a very simple concept, but it can be useful for saving space. Essentially, there are extra files that are left over from the builds that are not needed and can be done away with. Excess building materials, if you will. The command used below removed the unnecessary files:
strip --strip-debug /tools/lib/*
/usr/bin/strip --strip-unneeded /tools/{,s}bin/*
The thing I find kind of interesting about this is that a good 70 MB of space is taken up by the debugging symbols. To me, this seemed surprisingly significant for what it is worth.
This week I reached a somewhat significant milestone in the lfs journey. The ownership was changed from the lfs user to root. This was done to prevent a duplicate ID later on down the line. The command to be used was:
chown -R root:root $LFS/tools
from now on, everything is to be done in the root environment. got into part 3
On Tuesday of last week, I had made it to the point of glibc, pass 1 on the lfs build. This was giving me different types of errors, but mainly that crt.1 and crt.0 files were not found. This was extremely important because these files were significant to the linux library. Meaning that somewhere down the line something hadn't been installed properly, and would (did) cause problems for me later on. I found out that I was not the only one to have problems such as this either. roughly half of our class was experiencing problems with the first pass phase of things. In short, the problems were deemed to lie with the old hardware that we were using.
In order to remedy this situation, we took another's (Tyler's) build that was much further along as a catching up point in order to bring everyone up to speed. This help brought everyone up to the point of the grep installation in chapter 5. In order to transfer his build to our machines, we created an ssh connection between the computers and transferred the entire chunk of files on the partition to mine. Before the file was sent though, it was compressed into a .tar file for transfer purposes. Once I had received the file, I deleted my current build, (gone.. all gone… ) and proceeded to extract everything to the now empty space in my mnt directory.
From here, I began to install the other programs from that point on. All of the following files had much faster install times that took a fraction of the time compared to the previous files in the beginning.
As of now, everything is going well, with no unexpected errors to hinder performance/progress. Everything is back on schedule. I'm about halfway through chapter six.
Continuing the lfs build: it turns out that on my system, /dev/shm is a symbolic link to /run/shm. The following code created a directory “shm”:
if [ -h $LFS/dev/shm ]; then mkdir -pv $LFS/$(readlink $LFS/dev/shm) fi
Aside from the lfs build, we launched a couple of other “side adventures”, one being updating the bios for our computers. We had to go out to the Dell website for the updated bios versions for the Dell Optiplex 745 and 755 machines. This was a fairly simple process to complete, and took no more than 15 minutes. I used a flash drive that I had that was bootable. I had originally created it for this purpose earlier when I was working on an old laptop, but never was able to change the boot sequence on the computer. I installed both the 745 & 755 bios versions onto the flash drive so that other people would be able to use it.
When entering into start-up, you enter into the post system settings, and simply change the boot sequence to usb drive. From here, you simply boot off the file bios file that is installed on the flash.
The past week I got some more information on the different types of package management techniques, and what is the best to use. The one I have decided to use primarily is the program known as aptitude. For my purposes, it will be the most effective in taking care of my needs. I will have to install it once I break my build away from the host system and start to make it independent of external programs. I may take on a different style of package management as well, simply to gain the experience too. It sure couldn't hurt.
As of now, my lfs build is coming along nicely, and it is starting to finally look like a true unix system, with all the typical folders and such. (even if they're just symbolic at the moment) I have changed over lfs to the root. It's rather exciting, to be quite honest. Finally being able to see the frame of the system start to take shape after all the work that has been done is cool. I have quite the appreciation for programmers that is much higher than it previously was. We're learning all of this along the way, and just following instructions. I can't even begin to imagine how much work and understanding it would have taken to build a program like gcc or even vi. It would be fascinating to see the process someday.
As of now, I have hit a block in the road with my LFS build. During binutils pass 2, I keep receiving errors when I attempt to run the test suite. The test suite was ignored through the first pass, since it wasn't necessary and would just take up time. However, this time around LFS requires it. When the test install is run, the following error is displayed:
patch: **** Can't open patch file ../binutils-2.24-lto_testsuite-1.patch : No such file or directory
Spring Break, no classes.
This week, we delved into the virtual world. The task at hand was to create a virtual machine with Debian installed so that we could create nodes for a cluster. The program that we used was called VirtualBox. It is basically a management system that controls and organizes the virtual machines that you choose to run on your computer. The possibilities for virtual machines are rather limitless, and you can install almost anything from any time period. Tyler tried his had at installing the very first iteration of windows. It was rather fascinating, if not a little comical as well. For the serious nodes, we used a raw version of Debian. We set them up with our usernames and named them ws0, ws1, ws2, etc. My node was ws3.
Virtual machines are quite an interesting concept, seeing as they allow you to have complete control over how the virtual machine runs. You can tell it what resources it has access to, so you can see how it would perform on machines that would have that kind of hardware. You can also run a virtual machine within a virtual machine, since they run exactly as they would if they were standalone.
This week we are kind of at a stand still for work in HPC. It's kind of a catch up period in case you haven't created a virtual machine yet, or if you still want to work on LFS. It's useful to catch up on other classwork too. Most likely will pick back up with virtual machines next week. We're going to need to set up new IP addresses for our virtual machines so that they can be interacted with just like a regular standalone machine.
This week we all set up NIS, (I also installed vim) autofs and autofs5 on our machines. These programs are intended to help us set up our own interconnected network for the cluster. NIS is a “Network Information System” and allows our nodes to share a common set of files. It is a RPC based client/server system. Autofs is a program that automatically mounts the necessary file system so that it does not have to be done manually every time we boot up and log on. Autofs uses the automount command. Autofs5 is an updated version. In order to get NIS up and running, we use the command “service nis start”. This starts the system if it has not been started yet.
This week we set up our ssh keys for the cluster nodes. This allows us to simply use ssh to connect to any system that we want without needing to input our own passwords and the passwords of the nodes we are sshing into. This is an extremely non-secure way of doing things, as it makes it extremely easy to get into any machine that you want. However, easy is what we were going for, seeing as we want convenience for our networked node. bypassing the keys makes it much easier to get things done. It's a pretty useful tool if you know what you're doing. Rather fascinating concept.
Today we went through the last adventure with our cluster nodes. We exemplified how a cluster node would work, and what makes them useful in certain situations. The task was rather simple: calculate a very large amount of numbers, look at the time it took to create that sum, and then break it up among the nodes in order to significantly decrease the overhead time. Using the time function, we were able to measure the amount of time it took to complete the calculation.
When run on a single machine, the process took roughly 7-10 seconds. Then we split it up between the nodes. They were given a rank and a range. The rank was the number of the machine doing said process, and the range was the part of the whole calculation that the machine was doing. The tasks would be given out, the nodes would complete their portions, and it would all come back together to get the complete answer. This significantly reduced the overhead time of the calculation; it moved down to around 2-3 seconds.
It was also interesting to see how the machines finished in rank. They didn't always follow the order they were supposed to. Some machines simply had slower processors than others, and other machines were preoccupied with other tasks, so the finished later.
This is the last journal for the semester. It was a fun class, and even though it was a little slow paced in places, it was still very informative and fun. Can't wait till next semester!