A friend of mine has been a huge fan of PC hardware used to build inexpensive Mac OSX systems, and suggested I should as well, by handing me an Intel motherboard installed in a heavily modified Sun IPX case. It looks odd, but is geekily satisfying.
In any case, for a while, I have run OSX Mavericks (10.9) with varying (and diminishing) degrees of success. Every time I applied updates to 10.9, something would either stop working (like sound), or would work less well.(like video performance or any use of Flash). Months after the release of Yosemite, I decided it was time to start with a clean slate, so I bought a 240GB Crucial SSD mSATA drive and went through the steps here.
Of course, not everything went to plan - otherwise, this would not be a very interesting article!
Motherboard: Intel DH61AG, 8GB RAM
Disk: Crucial M500 240GB mSATA internal SSD
External USB Bluetooth adapter: IOGear GBU521
External USB Audio adapter: Sabrent AU-MMSA
Apple TrackPad
In MultiBeast, I started with a minimal group of items:
EasyBeast
ALC892 audio (on-board audio chipset)
TRIM patch (because I am not using an Apple SSD)
AppleIntelE1000e v3.1.0 (Network driver)
1080p Display Mode (because I have a 1080p monitor - might not be needed)
Verbose Boot (to see any issues that pop up as the system boots)
There were a few challenges that came up - most I could fix (kernel panics, due to my own error), and another I simply punted and worked around (no audio).
This board is small, and is pretty simple. It has Realtek ALC892 audio and Intel's HD3000 video, and is mostly compatible with the general installation steps. There are a few items that will be necessary if you are doing the same thing.
USB Boot issues: The USB3.0 ports don't work properly with OSX when booting the USB stick, so use the USB 2.0 ports.
Boot failure after install (Boot0 issue): The instructions here were exactly what I needed. I chose a Crucial M500 240GB mSATA SSD drive, and it has the "problem" configuration. I ran into kernel panics when I did this the first time, but it was because I didn't run the "dd" command properly - I wrote to disk0s1, when the instructions say to write to disk0s2.
Audio: The on-board audio was problematic with the original Mavericks install, and before the installation of Yosemite was not working at all - I had retreated to the less-elegant Sabrent AU-MMSA, a simple but reliable solution to the issue. Following the instructions did not yield working audio, so I tried an alternate solution in this thread that had helped others - to no avail. I went back to the Sabrent USB audio adapter, and audio is working fine with that.
The system seems reliable - power save is working fine (this is a desktop, and it comes in and out of standby just fine). I'm happy with the result thus far!
31 December 2014
16 January 2014
CentOS 6 under VMware ESXi 3.5...
CentOS, a "genericized" version of Red Hat Enterprise Linux, has been my server OS of choice for several years now. It has all the acceptance and compatibility of Red Hat Enterprise, without the heavy cost for updates. It has a long support lifespan, and follows the policy of backporting patches, so updates should not affect the configuration of running services.
My employer is releasing a brand new version of their core software offering, and I have been working to put together a new template image from which we can deploy new systems. With the relatively recent release of Red Hat Enterprise Linux 6 (and thus CentOS 6) and the major updates to the software that came with that, it seemed the obvious choice from which to assemble this new template.
In our hosting environment, we are running VMware Infrastructure 3i, using ESXi 3.5. I have plans to upgrade the hosts to a much more current version of vSphere, but the window for that has not yet presented itself! All of our production VM guests are using the vmxnet ethernet adpater.
Building the template in this environment proved easier said than done - The OS would install just fine in the template VM (I went with a "minimal" install, so as to keep the template as lightweight as possible), but once I tried to deploy a second system from the template, I could not get the network to come up. The VMware Tools and associated drivers (when downloaded from a 3.5 update 6a host) would build with no trouble.
After several false starts and ample searching, I found that there had been a few changes made to the behavior of device detection in the switch from RHEL 5 to RHEL 6, and the impact that was having was being felt in the changes that happen to a VMware network interface when one deploys a new cloned VM from a template.
Whenever you deploy a clone from a template, you have a VM that is identical in *most* regards to the template - except for a few minor identifiers, as well as a new MAC address on the cloned system's network adapters. This change leads udev to behave as though the adapter is new (and that the adapter with the template's MAC address is simply not present - but the configuration remains). As such, you have a eth0 that will not start, and an eth1 that is not configured.
Simple solution, based on findings at Aaron Walrath's blog:
On any template from which you will be deploying CentOS 6 machines:
Step 1: Remove /etc/udev/rules.d/70-persistent-net.rules
Step 2: Remove the HWADDR entry from /etc/sysconfig/network-scripts/ifcfg-eth0 (left in default DHCP configuration)
Step 3: Shutdown the system, convert it to a template
You should now be able to deploy CentOS 6 (or presumably RHEL 6) without network issues.
My employer is releasing a brand new version of their core software offering, and I have been working to put together a new template image from which we can deploy new systems. With the relatively recent release of Red Hat Enterprise Linux 6 (and thus CentOS 6) and the major updates to the software that came with that, it seemed the obvious choice from which to assemble this new template.
In our hosting environment, we are running VMware Infrastructure 3i, using ESXi 3.5. I have plans to upgrade the hosts to a much more current version of vSphere, but the window for that has not yet presented itself! All of our production VM guests are using the vmxnet ethernet adpater.
Building the template in this environment proved easier said than done - The OS would install just fine in the template VM (I went with a "minimal" install, so as to keep the template as lightweight as possible), but once I tried to deploy a second system from the template, I could not get the network to come up. The VMware Tools and associated drivers (when downloaded from a 3.5 update 6a host) would build with no trouble.
After several false starts and ample searching, I found that there had been a few changes made to the behavior of device detection in the switch from RHEL 5 to RHEL 6, and the impact that was having was being felt in the changes that happen to a VMware network interface when one deploys a new cloned VM from a template.
Whenever you deploy a clone from a template, you have a VM that is identical in *most* regards to the template - except for a few minor identifiers, as well as a new MAC address on the cloned system's network adapters. This change leads udev to behave as though the adapter is new (and that the adapter with the template's MAC address is simply not present - but the configuration remains). As such, you have a eth0 that will not start, and an eth1 that is not configured.
Simple solution, based on findings at Aaron Walrath's blog:
On any template from which you will be deploying CentOS 6 machines:
Step 1: Remove /etc/udev/rules.d/70-persistent-net.rules
Step 2: Remove the HWADDR entry from /etc/sysconfig/network-scripts/ifcfg-eth0 (left in default DHCP configuration)
Step 3: Shutdown the system, convert it to a template
You should now be able to deploy CentOS 6 (or presumably RHEL 6) without network issues.
Display driver frustration
I use an older (4.5 years old) Dell Precision M4400 laptop running Windows 7 64-bit at work, and while it is certainly getting a bit long in the tooth, it has worked well for me. My demands are relatively light - I use most of the 8GB of RAM it has for web applications and browsing, and a few other applications. I don't put the graphics processor to the test much, aside from having a second Dell display connected via DisplayPort. Both displays were operating just fine at 1920X1200.
As time has gone on, however, the newer drivers for my graphics chipset have started causing a very annoying issue. Power saving behavior incorporated into the driver (called "Powermizer") is not compatible with the firmware Dell has made available for my laptop. As a result, if a fairly current version of the nVidia Quadro FX 770M graphics driver is installed, the laptop will blue screen (with a STOP 0x00000116 error). Safe mode worked to prevent this from happening, but prevents use of a number of system items. Simply removing the driver was insufficient - Windows 7 would install the "current" driver from Windows Update, and the blue screen would happen on the next normal reboot.
Solution: I uninstalled all nVidia driver components (in Control Panel) and installed only the following parts of the driver package:
nVidia Graphics Driver 275.33
nVidia nView 135.85
I also downloaded a piece of freeware called Powermizer Switch which (via registry settings) disables the Powermizer feature that causes the blue screen. I downloaded it from here.
Where before, the system would blue screen on login or would simply say "Unable to save Display Settings" when I would attempt to enable the external display - now it works just fine, as it has for 4.5 years.
Conclusion: If you are happy with how something works, resist making changes, applying updates, etc. You never know what might break, and further, you don't know if your "update" will be reversible!
As time has gone on, however, the newer drivers for my graphics chipset have started causing a very annoying issue. Power saving behavior incorporated into the driver (called "Powermizer") is not compatible with the firmware Dell has made available for my laptop. As a result, if a fairly current version of the nVidia Quadro FX 770M graphics driver is installed, the laptop will blue screen (with a STOP 0x00000116 error). Safe mode worked to prevent this from happening, but prevents use of a number of system items. Simply removing the driver was insufficient - Windows 7 would install the "current" driver from Windows Update, and the blue screen would happen on the next normal reboot.
Solution: I uninstalled all nVidia driver components (in Control Panel) and installed only the following parts of the driver package:
nVidia Graphics Driver 275.33
nVidia nView 135.85
I also downloaded a piece of freeware called Powermizer Switch which (via registry settings) disables the Powermizer feature that causes the blue screen. I downloaded it from here.
Where before, the system would blue screen on login or would simply say "Unable to save Display Settings" when I would attempt to enable the external display - now it works just fine, as it has for 4.5 years.
Conclusion: If you are happy with how something works, resist making changes, applying updates, etc. You never know what might break, and further, you don't know if your "update" will be reversible!
Subscribe to:
Posts (Atom)
