Showing posts with label Apple. Show all posts
Showing posts with label Apple. Show all posts

Sunday, October 14, 2012

FreeNAS Experiment - Part 1

One of the potential projects that I have wanted to experiment with is building a SAN (storage area network) box. After hearing about some positive experiences from friends like Retr0Rob (Twitter) and Bob Martens with FreeNAS over the past year, I found myself with the means to build a nice looking FrankenSAN box without any cash expenditures. Going forward, I think putting some money into the second project box will be helpful. But for this first experiment, I am in learning mode, so using existing hardware is fine.

The first decision to make for my experimental SAN box is to determine the purpose for which it shall be used in my home environment. Looking at how I currently use technology at home, there were immediately two processes that I knew I could move to a FreeNAS box. The Macbook Air I use was being backed up via a USB hard drive which meant a cable (ball and chain) attachment. The backup solutions I have in place are CrashPlan (off site backup) and Time Machine (local backup). CrashPlan works over the Internet wirelessly. FreeNAS would give me the opportunity to backup wirelessly inside my home. Secondly, I wanted to put CDs / DVDs I owned on a digital storage device that could play back through my PS/3. FreeNAS promised this functionality via its plugin architecture.

The hardware available was an HP xw4600 workstation with 4GB of DDR2 RAM, (2) 1 TB Hitachi SATA hard drives, and internal USB port connector and gigabit Ethernet. The software released this past Friday was FreeNAS 8.3 RC1. I guess timing is everything. I downloaded a FreeNAS guide and read some of the initial setup instructions. With a copy of FreeNAS downloaded, I initiated the terminal commands necessary to prepare a 4GB USB thumb drive with a bootable copy of FreeNAS. I plugged the 4GB stick into the internal USB port inside the HP xw4600, put the side cover back in place and pressed the power button.

Within 60 seconds, a text menu was showing on the monitor that allowed for refinements to the network interface settings (if needed) and the ability to reboot, reset and shutdown the FreeNAS box. Most importantly was the WebUI IP address needed for the administration of the FreeNAS box.



My first priority was to setup account passwords and add myself as a user / group for use later in assigning permissions to the shared dataset (volume) that I would create for storing Time Machine data. One of the cool features of FreeNAS is that you can use ZFS as a filing system. I used the volume management tools to create a ZFS mirrored volume of 931.5 GB out of the two 1 TB Hitachi hard drives.

Let me take some time to explain that when using ZFS to create mirrored RAID sets, there are some issues to be aware of in management. ZFS is a serious file system with safety protocols in place that make you consider how hard drive management should be done. For instance, if you create a ZFS mirror of two hard drives, then mess up your FreeNAS experiment and start from scratch, those hard drives are locked into a mirror that is not immediately usable. You must become comfortable with some command line work to fix or destroy old mirrors.

I became familiar with the gmirror and gpart commands in order to destroy the existing mirror from a previous failed FreeNAS experiment. ZFS is really pretty straightforward to learn, is logical in its command structure, and worth learning its commands to make it perform well. Here is a gmirror wiki page to learn about the command structure.


After created the ZFS mirrored volume, I created a ZFS dataset to be used as a Time Machine backup volume. For my experiment with just my Macbook Air doing backups, I carved out 250 GB of space. I then assigned permissions for this ZFS dataset to my user / group. As my friend Bob Martens pointed out, multiple Macs could use the same login credentials to use the Time Machine backup. Each Mac would identify itself by machine name.

Once the permissions were set and verified on the ZFS dataset for the backup, I next moved over to setup the Apple (APF) Share so that my Macbook Air could see the network store. I look at this process as connecting a volume with the ZFS file system to the Macintosh world which uses the Apple Filing Protocol. For those living in the Windows world, ZFS would need to be connected using the SMB (Simple Message Block) protocol.

Using the Apple Share settings of FreeNAS, I connected the ZFS dataset on the path shown in the image to the left here. /mnt/LundNAS/LundBackup

The Allow List and Read-write Access boxes are the places in which you specify the users / groups that will have Apple Share access to the ZFS dataset. To make things simple, the user / group permissions and these users for Apple Share should be aligned. I did try to use a group called Family with two users - my wife Julie and myself Perry. However, I found that it did not work well initially because of my bad ZFS dataset permissions. More future testing is required for multiple users with different login credentials.

Lastly, FreeNAS requires that the Disk Discovery checkbox should be enabled and the mode should be set to Time Machine in order for clients to backup.

My observations when configuring and using Time Machine on my Macbook Air showed me a few interesting tidbits. The Time Machine volume visible to select as my backup destination. Once selected, my Macbook Air showed it was "Looking for Backup Disk" and after finding it, mounted the Time Machine backup volume on the desktop and did the backup. Once the backup was done, the mounted desktop volume is unmounted. This is important since the Macbook is mobile and a mounted volume would cause problems for mobility.

So far the Time Machine backup server and service is working well.


Tuesday, October 9, 2012

MacBook Troubleshooting - Beep Codes

North Mahaska is almost 6 weeks into the first year of its 1:1 laptop program and the hardware has been remarkably resilient and the students seem to be using reasonable care with the MacBook Pros. There have been some carrying case problems with straps and zippers, but that is another story. We have learned a few new troubleshooting processes and we enjoy learning new techniques to solve problems.

On a recent occasion, one student's MacBook Pro started up with three beeps and showed abnormal behavior. Using Apple support guidelines, we now know the meaning of the startup beep codes. On a MacBook Pro, the startup POST (power on startup test) checks hardware functionality. The following beep codes indicate a variety of issues. Here is the listing provided by Apple technical documentation.


On MBPro Startup: 
1 beep = no RAM installed
2 beeps = incompatible RAM types
3 beeps = no good banks
4 beeps = no good boot images in the boot ROM (and/or bad sys config block)
5 beeps = processor is not usable


One beep seems self explanatory in that there are no RAM SO-DIMMs installed in the machine. While this is not likely to happen in many cases, you will quickly know the issue.

Two beeps on a MacBook Pro indicate that the RAM SO-DIMMs are not compatible. For instance, if the memory specification requires PC3-10600S DDR3 1333 MHz RAM, that is what should be procured and installed in the MacBook Pro. Not all RAM modules are up to Apple's specification and it is wise to purchase RAM from vendors who explicitly state MacBook Pro compatibility.

Three beeps indicates a tricker predicament. The problem is most likely not RAM compatibility despite the results of Google searches. The possible problems are more likely to be a problem with the RAM seating in the module banks. It is also possible that the circuitry of the RAM banks in conjunction with badly seated RAM modules has cause a memory management issue. Reseat the RAM modules and also reset the PRAM (parameter memory) on the MacBook Pro.

A POST with four beeps is a bit more serious. The ROM instructions for booting your computer will not function to startup the computer. Perhaps the ROM was corrupted by some electrical damage involving the ROM chip and circuitry. Generally, this problem will require a motherboard replacement.

Finally, five beeps also indicates a fatal problem. This failure is found in the central processing unit of the laptop. Again, damage of some type has occurred with the CPU of the MacBook Pro, and will require a motherboard replacement in most cases.

In the case of student laptops at North Mahaska, the problems seen so far have been minor. One laptop did come in with the 3 beep POST and a RAM reseat and PRAM reset seems to have fixed the problem. Otherwise, one hard drive and one trackpad in 300 laptops has failed in six weeks. We continue to monitor the laptops with JAMF Casper and ARD software products. If the hardware continues to be solid, then we can turn ourselves to software issues, which consume more time due to complexity relationships in installation and usage.