The problem I was faced with is quite common for the remote system administrator.. installing bare metal in a remote location. In this case some new Dell servers we got for the Fedora kernel people to test their kernels on. Usually we can do this with a combination of internal hardware management system, pxe boot, kickstart and vnc.. however in our case we are working with brand new hardware which may only have kernel support in the latest kernels. The second problem is that due to some initial miscommunication, the internal iDrac management system wasn't bought with any management ability so I have to use an APC KeyboardVideoMouse (KVM).
This unit is on loan for evaluation so I ended up testing various parts as I was going through this. The first problem in the evaluation is that the tool only wants to work with 32 bit Official Java. I spent a day and half first trying to get OpenJDK 64 bit to work and then in trying to get 32bit Java to work on my 64 bit environment. After a lot of weird browser bugs with different browsers.. I decided it was time to look at plan B, install an OS (RHEL-6) which came with a known working java for the toolkit. Since I didn't want to reinstall my laptop, I opted to put the RHEL-6 as a virtual machine using my laptops kernel virtual machine (kvm) system. [I have decided to uppercase some KVM and lowercase other kvm because I am confused after the second or third mention while writing this piece]
The RHEL-6 install was pretty fast and quick, and I installed Oracle JDK via the alternatives channel. Fired up firefox, and low and behold when I logged into the APC KVM I was able to get the remote console to work and was able to get into the system. This is where I ran into our second problem. Most of our hardware is installed with Red Hat Enterprise Linux 6, so I was going to do an install with that. However, it quickly became obvious that the Dell R520's came with a newer network card than what the RHEL-6.4 images I had knew about. I started to look for vendor drivers and such but it turned out that the Fedora kernel developers wanted to play with Fedora 19.
After setting up a Fedora 19 in our PXE boot environment (I will detail that in a different post), I was able to get the system working before running into the next issue with the APC KVM. That is that its video codes as interpreted by Linux makes the screen miss the top and left side of the screen. Trying all the different controls to resize the screen didn't help and while I could "move" the screen in some of the controls to the left, after 30 seconds it would resync back to its original lossy stage.
I was going to look for modeset controls and such, but knew that would cause the ghost of Ajax to visit my tent with the "Modeset on the kernel line is WRONG.", so instead I went to how one should install remotely.. the anaconda vnc installer. Adding "vnc vncpassword=myeleetpassword" to the "/tftpboot/pxelinux.cfg/default" file allows the installer to start up vnc and allows for to get to the system on the 5901 port using tigervnc.
Finally I was able to get some of the installer working, but it would fail at looking up the http ports for packages and such. This turned out to because the boot line syntax for ip addresses has changed since Fedora 17 due to some dracut handling. I spent another half hour trying to get the system to come up like the dracut webpages at https://fedoraproject.org/wiki/Dracut/Options#Network show but found only a lot of errors. Instead I ended up mixing and matching between new and old to get it to work. The new was to change out "dns=
The Fedora 19 Beta TC3 install went well from there (I had one crash but it was not reproducible and not fileable so I am calling it a fluke until I get it again). The Dell R520 is a lot faster to reboot than the IBM xseries boxes we have.. and its management tool to upgrade BIOS etc is much much nicer. All the tools work well without a mouse which is good because the KVM and its mouse syncing is not as good as I hoped.
No comments:
Post a Comment