Tag Archives: software

Imaging a Lab with DeployStudio

by

Imaging is a great thing..it really is.  When you have more than 2 computers, imaging becomes your best friend…and if you buy new machines or one of your older machines dies or gets messed up, it saves so much time.  I have a complete backup ready to deploy at all times for both Mac and Windows.

I image my lab once a year. This ensures that I have the latest updates for every machine for all programs, but it also cleans out the old stuff from the previous year that builds up over time.  Apple makes imaging very simple by installing a NetBoot feature on all of their machines and including a NetBoot server installed with MacOS X Server.  In the past I used Bombich NetRestore, a free AppleScript based program that helped make NetBoot image sets and helped with deploying them.  Mike Bombich stopped making NetRestore and suggested everyone to try DeployStudio for imaging..so I did.  I must say that DeployStudio is an amazing program especially for a free program.  It’s also very simple to get running and fairly robust. In this post I’m going to go over image creation, setup, and deployment with DeployStudio (DS) and also go over some issues I encountered and how I fixed them.

Creating the NetBoot Set

The first step to any Mac NetBoot is the NetBoot set.  What the set is is a basic image file that includes all the tools your computer will need to read the image, copy the image, and even run checks on your computer even if you’re not imaging.  It’s a very basic MacOS install that resides on the server.  DS creates these images for both PPC and Intel machines in the same set, so any Mac can boot from the same set.  After installing DS on your server you can open the DS control panel and begin setting up your system AND create your  NetBoot set.  I will not be going over server setup in this post, I may save that for a later time.

The DeployStudio Control Panel

When you open the control panel you should launch the assistant (you can also find it in /Applications/Utilities).  When the assistant opens you select “Create a DeployStudio NetBoot set and continue.  If you’re running the assistant on a computer other than a server you will see this:

DeployStudio DHCP Setup

If you plan on using a server to do the deploying, you can skip this, if not, you’ll have to setup a DHCP server.  This depends on your setup, for my case I can skip this.  The next step allows you to name your set; set the name and unique identifier to whatever you wish, (unless you have multiple NetBoot sets). When you click continue you will tell the set where the computer should log in and look for the images and workflows.

My settings...

more settings...

The settings above are MY settings, yours will be different.  The login and password for mine are supplied by the LDAP server.  The final step is the actual save location and creation of the image.  Pretty self explanatory. It takes about 5-10 minutes.

Completed NetBoot .nbi file

After image creating is successful you’ll have a nice .nbi file in your save location.  This file is basically an image file that contains the bootable images for PPC and Intel as well as the basic MacOS system with some basic utilities like Disk Utility, Terminal and Startup Disk.  It’s roughly 2.5 GB and it should be placed on your server in the NetBootSP0 folder (It’s located in [Volume]/Library/NetBoot/).  Inside the NetBootSP0 folder will be other folders which DS created during install, these contain various other things for DS and also house your images.  I will go over image creation next.  This is where we will be able to test to see if your NetBoot Server and set are both working.

Creating Images with DeployStudio

Creating the images is an extremely simple task once you know what settings you need.  I will explain the setup with my current settings but attempt to go over most of the other ones.

To start the process, boot your mac and hold the ‘N’ key down during power on, this will perform a network boot (REMEMBER: Your computers must all be on the same subnet, this is the only way to do this without messing with a lot of things!)  If your computer boots to the DS screen you will see the DS Runtime Window.

This window shows all of your available jobs in DS.  There are a few default jobs that come with DS, we’ll make our own later for deploying.  For now we’re gong to select “Create a master from a volume.”  Click the Play button at the top and you will come to the heart of the Image creation.

My Image Settings from a PowerPC computer

This window is probably the hardest window we’ve seen so far.  First thing is to choose which drive you will make an image of from the dropdown menu.  I’ll start with my MacOS partition.  After selecting the correct partition I name the image something like 2011_09_02_Intel_lab and leave other settings alone.  The keywords are not very important unless you have a lot of images. I usually select Compressed for the type because it saves space and it gives a much faster restoration.    Access group is what you would have set in your initial DS setup that I did not cover.

Format is what kind of image you are making.  Since I’m doing a MacOS install the Format will be HFS+.  I normally select “Auto Detect” but if you want to have HFS+ Journaled, Case-sensitive or both you may want to change it because it will always auto-detect HFS+ without journalising.

Once my settings are correct I click the Play button at the top and the image making process begins.  This will take a lot of time depending on the size of the image being created,  a 100+GB image will take roughly 2 hours (sometimes more, sometimes less, depends on the machine and network) and it will then compress the image (my images get compressed to about 75GB from 128GB…compression rocks!).

Masters in the NetBootSP0 Folder

After image creation you will see the .dmg file in your NetBootSP0/Masters/HFS folder.  (Note: I just found out that new versions of DeployStudio won’t show your images in DS Admin unless you have .hfs in filename before the .dmg, it will automatically add them during image creation, but if you have old images, just add the .hfs right before the .dmg extension).

You can use this same process to create NTFS, FAT, and EXT4 images.  Follow the same steps but make sure you leave the Format as “Auto-Detect.”  After creating a NTFS image it might take some time to show up in DS admin, this is because some server-side tasks may need to be done, it will show up when that is complete.  NTFS imaging requires a little more setup in DS admin beforehand…again, I will not be covering that in this post.

 

Making Workflows to Deploy Images

DeployStudio comes with an administration program where you can manage images, workflows, packages, scripts, and see progress of NetBooted computers.  You can also set up all of your computers in it before hand (names, network settings, licenses, etc) and set up automation for all of your systems so if you want a computer to automatically format and re-image when you NetBoot it, you can do that (please don’t think that’s a great idea…just saying).  To start setting up workflows you’ll need to open DS Admin, it’s located in /Applications/Utilities.  Enter your server credentials and you’re presented with the DS server information.

The window that opens first is the current (or previous) activities.  In this window you can watch and control the computers that are currently working in DS.  ou can also see what jobs they were doing, and how far along they are.  This screen is very helpful when you have DS running on many machines.

I am going to explain how to setup a dual-boot Mac workflow.  The default jobs are very helpful at getting you started, I’m going to start from scratch.  To create and edit workflows we’re going to select “Workflows” from the left sidebar and begin setting up our job.  Click the “+” button at the bottom and you will be presented with a new blank job.  Then click on the little “+” button next to “Drop tasks here.”

Creating a new workflow

The first thing to do is to drop the “Partition a disk” task from the left side to the drop space.  Then you should select  “Mac OS X + Windows” from the Apply layout template dropdown menu.  Resize the partitions to suit your needs, make sure your images will be able to fit on the partitions you make for your drive.  I normally do 75% Mac OS/25% Windows, I also normally Automate this process, your mileage my vary.

The next step is to drag the “Restore a disk image” job from the left and drop it after the partitioning job.  Your MacOS image should ALWAYS be first of else it will not work.  Select “Enter value…” from the Target volume section, then select the “MacOSX” option from the menu.  Set your Image to HFS and select the appropriate image from the menu (the one you created earlier).  Now, for the options you can read from the image below how to set those.  If you’re imaging Mac OS 10.7 Lion you should check “Restore system recovery partitions” but I don’t need this.

My HFS Settings

You may also notice Multicast settings, you can set this up if you’re brave, I don’t need it so it’s ignored.  Your HFS partition is complete, now on to Windows.

Drag the “Restore a disk image” job from the left and drop it after the first restoring task.  Select “Enter value…” from the Target volume section, then select the “WINDOWS” option from the menu.  Set your Image to NTFS and select an appropriate image from the menu again.  Settings for Windows is relatively the same as HFS with some exceptions;  you should check “Expand restored NTFS partition” and uncheck “Set as default startup volume” unless you want to have Windows as your default.  You’ll also notice that all of these tasks are automated, this is so you can boot the computer, select the job, and walk away without intervention.

DS NTFS Settings

Now, you can add more jobs to the workflow such as AD binding, or software updates, but this setup is the basic setup for a dual-boot deploy.  Now just rename the job by clicking the name in the top with the other jobs and rename it, you can also add a short description of the job.  Your workflow is now complete! Now it’s on to the easiest task…deployment!

Deployment

I say this is the easiest part because it really is.  If you have everything set up properly, you should have no issues.

To deploy the image to the computers, boot the machines again pressing the ‘N’ key, when the machine boots to DS you can select the newly created Workflow and press the play button.  If you automated everything, that’s it..it will partition your drive and load the images to those partitions.  After the job is complete your computers will either tell you it was successful (or failed…more on that below) or they will reboot.  If the task was successful, GREAT!  Reboot the machines, they will run the final scripts in MacOS then reboot again…MacOS is done.  You only have one more thing to do and that’s configure Windows.  I won’t go into this because it’s going to be different for everyone, but you will have to activate windows and any other programs that require it because Windows will not keep the activation after imaging.

Issues?

Now, not everyone will be so luck to have a successful run…if you run into any issues visit the DS forums, they are very helpful and pretty speedy.  I had one issue that just drove me nuts.  When I ran my deployment script the MacOS partition would go fine but once Windows hit it would fail…everytime.  DeployStudio keeps logs for every computer on the server, so I took a look and noticed the following errors:

[Thu Sep  1 14:41:15] dyld: unknown required load command 0×80000022
[Thu Sep  1 14:41:16] -> invalid starting block value () defined in MBR for partition /dev/disk0s3.
[Thu Sep  1 14:41:16]    Check your partition map. You need to define at least one DOS/FAT partition in order to get the MBR automatically in sync with GPT.
[Thu Sep  1 14:41:20] -> Restore action completed.
[Thu Sep  1 14:41:20] Restoration failure (elapsed time: 0.24 minutes)

I posted in the DS forums (topic link) and in a matter of hours the admin of the forums posted a solution:

Sounds like the custom fdisk command fails on 10.7 DSS netboot sets. You may try to remove the one located in your netboot folder at /Applications/Utilities/DeployStudio\ Admin.app/Contents/Frameworks/DSCore.framework/Resources/Tools/fdisk.

So I tried this and BOOM, successful.  It’s great when a developer helps with products so quickly…and I’ve only usually seen this with free or open source projects.  So if you’re having issues, the forums are key.

I hope this post helps people out with Mac imaging and deployment.  If you have any other questions or issues feel free to ask in the comments.  If this post helped you or think it will help others please feel free to repost and share away!

Getting more from my Original DROID (Part 2: Restoring and Troubleshooting)

by

In part 1 I described (in little detail) how I rooted my phone and installed CyanogenMod 7 on it to get some more mileage out of it until I upgrade to a newer device this year.  But of course every upgrade and every hack isn’t without it’s issues and every hack isn’t perfect at all.  Cyanogen never claims to be 100% trouble-free, and every users’ experience will vary depending on device and applications installed; after all, it is technically a hack made by third-party developers…and no developer is perfect. The methods for flashing are also different for each user.

I installed CM7 when it was at RC1 for the DROID (still buggy, but still good for everyday use) and I originally flashed my phone by doing a factory reset of the device (removes everything) and then installing the ROM. This gave me an endless boot screen.  What I had to do to fix this was not only do a factory reset, but wipe the cache partition AND the Dalvik cache partition.  This was easy with the ClockworkMod and it was also nearly 100% risk free since I had a complete Nandroid backup.  After wiping the two it booted successfully!

I noticed that in Android 2.3 Google will restore all of your previously purchased and downloaded apps if you want it to automatically on a new device (only the app itself, not the data..like game save data).  This is great, but I already decided to use MyBackup Root for this, mainly because I wanted to have my stuff there with all of the data.  So i just told the phone not to download everything and I’ll just restore everything from my backup.  What this left me with was broken installed apps with no way to update them because the Market links were all hosed.  This sucked, now what was I supposed to do?  I decided to flash again and allow Google to push the apps to my phone.  This process took some time but everything was downloaded for the most part; unfortunately, I didn’t have my app data, so all of my game data and all of my settings were gone…I check MyBackup and sure enough I was able to restore data only!  I did that and bingo, everything worked again with all of my old data!  A few apps needed to be reinstalled or needed their data wiped (Google maps and Facebook I think) but for the most part everything worked just as it was supposed to.

Choose which to restore? Yay!

So now that I had my apps on my phone, I was nearing happiness with my hacked DROID.  I say nearing because I was still having many issues with other things.  I won’t go into every little one but I will talk about the two that almost made me decide to go back to stock.

LED Notifications

The one thing I love about Android phones is the LED notifications.  A simple little LED in the corner of my phone blinks different colors for certain things (texts, emails, etc) so I don’t need to turn the screen on, or unlock my phone to see what I missed or see what that beep was from…I can just look at the color of the LED.  Funny thing happened after installing, it stopped working.  I would look down and nothing would be blinking but when I unlocked my phone I’d notice an e-mail that I missed!  What was going on here?  I looked in the settings and found that CM has basically rewritten the notification system and you can customize colors and blink rate from it if you so desired, but instead it broke the damn thing.  This wouldn’t fly with me, I was about to go back to stock because one of my favorite features was broken…then I found the forums.  I searched the issue on the forums and found a lot of people with the same issue, on different phones even!  Reading through many of the posts they all usually came around to the same solution, un-check everything in the LED settings then check them again then hit “Reset all LED notifications” and reboot. And it worked!  I had my LED back and working and now it was even better because I can change the settings for every program and even change the colors and blink rate for them, pretty neat.

Change color and rate for LED notifications

Missing Messages

Now that my LED notifications worked I was happy that I could look down and see if I missed any emails or (more importantly) text messages…but strangely I felt that I was receiving less messages.  I went an entire day without a text message, which is very odd for me actually.  I looked at my phone, no blinking LED, I unlocked the phone, no notification in the menu, I opened the messaging app and boom, new texts, some as old as a day!  What the hell was going on with this?  I’m missing text messages now?  This used to happen with my EnV Touch, never my DROID!  I tried resetting my notifications for the app, and it would work for a while after I opened the app.  I figured, okay, it’s fixed, but then it would stop later on in the day.  I was getting very frustrated with this now and was again thinking about going back to stock.  I hit the forums again and found one post about the issue with one simple solution:

The solution! Check that box!

Once I checked that, never missed another message.  It locks the message app in the memory so it’s always running.  Sure it uses up memory, but my messages are more important to me than the amount of apps I can run at one time.

Side note: But why does the DROID do this with CM7?  The DROID has 256MB RAM, this was a lot when the phone came out and with 2.1 it was fine.  Once 2.2 was released memory was becoming a problem for the phone.  The phone had trouble even keeping the Home app in memory; if you ran a program that was memory hungry and went back to the home screen you’d have to wait for it to redraw because Android’s memory management would kill it.  So in CM7 you can see the two check boxes for home and messaging, this stoped the redrawing(relaunching) and the missing messages…but it took some memory away of course which means you can only do so much multitasking before apps start getting killed.  Android 2.3.3 uses more memory, and the DROID just doesn’t have that much…so CM7 also allows asset purging to free up RAM as well as compucache (memory compression).  These use a little CPU but allow you to multitask fairly well;  it’s nowhere near as good as other newer phones, but it works.

There were some other small odds and ends that I had fixed by tweaking settings and installing updates but I thought that these two were really the most damming for me.  I managed to fix them with help from other nerds at the CyanogenMod Forums who were running into similar issues and there are some I managed to fix by trial and error.  Now, he ROM still has it’s occasional reboots and hiccups (not very often) and they usually happen with two programs; Google Maps and the Camera app, but these crashes happen less and less with each update.

CM7 is now out of RC and was released as Gold…but not for the DROID yet.  It still is very much a work in progress, but the progress is going very quickly, and I really like the direction it’s heading.  They’ve managed to give DROID users Android 2.3 even after Motorola decided it “wouldn’t work” on the phone.  Well, it is working (for the most part) and I’m fairly happy with it.  It has really allowed me to use my phone a bit longer than I was expecting.  I’m probably going to wait until August to upgrade my phone instead of going for the Thunderbolt, but time may change that.  What I do know is that my phone still works well and I will get more time out of it because of the ROMS.

Getting more from my Original DROID (Part 1:Rooting and CM7)

by

I love my DROID, I have since I got it over a year ago.  But in a year, a lot can happen with technology of course.  My phone was originally equipped with Android 2.1 (the first phone to have it actually) and had an ARM 600MHz processor (underclocked to 550 for battery life), and 256MB RAM.  It was fast, really fast…and it took a while for phones to be that fast…but it didn’t last long.  Soon after the DROID came out every new phone that came out just got faster and faster very quickly..I mean, that’s what technology does, right?  But the DROID looked slow very quickly.

So when Froyo (Android 2.2) came out the DROID got it down the line and that’s when the DROID started to show it’s age; extremely slow…a big drop in performance.  So I decided to root it to get a little more millage out of it before my upgrade.  Mind you, I was waiting for the Thunderbolt to come out to replace it…but decided against upgrading for the time…another story I suppose.  I decided to use SuperOneClick to root my phone, and damn it was simple.  Literally one click and it was done…but what can I do with this root?  Well, first thing was overclocking to see if I can get some more speed.  I overclocked it to 800MHz and really didn’t notice much of a difference besides the fact that I could now have a wireless hot-spot…oh and I could take screen shots now (why doesn’t Android have this functionality built in? Seriously!).

Android Screen shot

Hey look, I need to ROOT to take a screen shot!

So I decided to take it a step further.  My buddy was telling me about CyanogenMod and how he loved it on his MyTouch and basically brought life back into it.  So I said “Why the hell not?”  Not only does it add a lot of functionality, it will give me Android 2.3.3 (Gingerbread)…something the original DROIDs won’t ever see normally.  I backed-up my apps and text messages phone using MyBackup Root then flashed my recovery ROM to ClockworkMod which allows me to install firmware from the SD card and allows me to backup my entire phone to an image just in case anything goes wrong.  After the backup with MyBackup Root I rebooted into recovery mode and backed-up the entire phone using the Nandroid backup (in the recovery) then started to flash CyanogenMod 7 on my phone..this meant I had to do a complete wipe of the phone which is always scary but with the backup I should be cool!

Wiped the phone, flashed the ROM, and booted the phone. It worked! I had the Release Candidate (at the time it was RC1) of CyanogenMod 7 on my phone!

I had some issues with CM7 at first and some issues with getting my apps back (which I’ll talk about in Part 2) but after some initial bumps I was up running as smooth as I could be on a release candidate.  I had some reboots and some programs would crash but reinstalling them from scratch helped for the most part.

After a few updates it became more and more stable.  I am now running RC4 with a new ultra-low voltage kernel (which allows me to overclock to 1GHz and uses less battery power than the stock kernel). which gives me good battery life, pretty good performance, and all around a pretty good experience.

Android 2.3.3 and 1.1GHz!

So if you’re looking to get some more time from your old DROID this seems like a great way to do it.  It’s not up there with the new phones, but it does give your device a nice little jolt until you decide to retire it.

In Part 2 I’ll talk about installing all of the apps from backup and troubleshooting the many issues I had with memory issues and how they were resolved.

An Update from Motorola on the eFuse

by

Holy cow, a third update in two days?!?  Yep!

Today Motorola responded to all of the eFuse nonsense with something that makes the situation a bit better.

Motorola’s primary focus is the security of our end users and protection of their data, while also meeting carrier, partner and legal requirements. The Droid X and a majority of Android consumer devices on the market today have a secured bootloader. In reference specifically to eFuse, the technology is not loaded with the purpose of preventing a consumer device from functioning, but rather ensuring for the user that the device only runs on updated and tested versions of software. If a device attempts to boot with unapproved software, it will go into recovery mode, and can re-boot once approved software is re-installed. Checking for a valid software configuration is a common practice within the industry to protect the user against potential malicious software threats. Motorola has been a long time advocate of open platforms and provides a number of resources to developers to foster the ecosystem including tools and access to devices via MOTODEV at http://developer.motorola.com.

This is very good compared to bricking the phone.  At least the phone can be recovered by the user instead of having to ship it to Motorola for a repair(not sure of the complete details and how warranty would work).  I’m also happy to see that Moto responded so quickly to the public.  However, this still does not sit well with me as Android was developed with developers and tinkering in mind.  If I want to mess around with my device, why can’t I?

(Thanks to Tom for pointing this out for me)

The Droid X and the eFuse: Moto shooting themselves in the foot

by

Last year I bought my first smartphone, a Motorola DROID from Verizon. This is my first Moto phone since I got a RAZR many moons ago and swore off Moto forever because of their shitty product. Now, I love my DROID, it does everything I need it to do and more, and I really think Moto got it right with the DROID (I also applaud Big Red for finally making their phones more open). Since the DROID came out Moto has yet to release another kick-ass Android-based phone; the CLIQ is a piece of junk so don’t say that. Verizon has released the DROID Incredible (an HTC device) which is also making the rounds as being an amazing phone, but people were waiting for Moto’s next DROID. The Droid X was to be the next amazing Verizon/Android/Moto Android phone but with its release something has popped up on the tech radar; the eFuse.

According to a source at My Droid World (and Motorola themselves), the Droid X has an eFuse chip installed in the device. The long and short of it is that Motorola has installed this eFuse in the new Droid X which checks the phone for the proper kernel, boot-loader, and ROM and if the proper software is not found it will automatically “trip a fuse” to corrupt the phone’s boot-loader forcing you to get it repaired and will most likely void your warranty. Oh and did I mention that the phone can ONLY be repaired by Motorola, so the Verizon Store won’t help you (well, they’ll ship it to them for you) and you’ll most likely end up pay for a new phone.

Why is Motorola doing this to their phones? According to the Motorola blog:

We understand there is a community of developers interested in going beyond Android application development and experimenting with Android system development and re-flashing phones. For these developers, we highly recommend obtaining either a Google ADP1 developer phone or a Nexus One, both of which are intended for these purposes. At this time, Motorola Android-based handsets are intended for use by consumers and Android application developers, and we have currently chosen not to go into the business of providing fully unlocked developer phones.

Now if I read that correctly, Motorola just told people to buy an HTC device (the Nexus One or a Google ADP1 dev phone) and not their product because their “Android-based handsets are intended for use by consumers and Android application developers.” So, the DROID was a fluke? Well…

When we do deviate from our normal practice, such as we did with the DROID, there is a specific business reason for doing so. We understand this can result in some confusion, and apologize for any frustration.

You’re joking, right? You deviated on the DROID for a “business reason” and now that everyone loves your Android-based phones, you’re going to change it? How stupid does that sound?

First, if you’re going to say you have a reason you could at least tell the people what that reason was even if it’s most likely about money. Secondly, why would you want to change something that has worked already? You know the whole “no fix if no broke” thing? The DROID was probably the best smartphone released last year because of it’s features and it’s openness. Taking one of those key selling points away is really going to piss people off. Also, not only is it frustrating, it’s just a punch right in the face of all the people who praised your phone for it’s openness.

What happens when (like the MyTouch 3g and G1, etc) the developers stop caring about a phone so much that they don’t release a new version of Android for it, when their phones are still capable of running them? Or if Motorola decides not to update the SenseUI on the phone and you’re stuck with whatever they stop with? Well, of course you’re supposed to buy another phone from them, but it probably won’t be a Moto phone if the eFuse is still there. But there are a lot of people want to get all they can from their device (I mean, you did pay $200+ for it!). So they’ll end up going the route of rooting a phone and installing a modded Android install and continue to be happy with your device. Does it change that fact that it’s still a Motorola brand phone? No, it just shows that your hardware still kicks ass 2 years after it was released instead of going to the bottom of the old electronics drawer or whatever.

I realize not everyone cares about modding their phones, hell it’s most likely a larger portion than the people who do care, but the issue is that Motorola is making it okay for a company to brick YOUR phone if they don’t like what you do to it. You know, the phone YOU paid for with YOUR money (which Motorola took of course!). A lot of people buy devices based on how much the company lets you tinker with the device after you buy it.

I’m almost positive that the phone will still be hacked, but this is going to cause a big backlash in the Android community against Motorola (and probably Verizon even though they most likely have nothing to do with it). A lot of Android folk are very pro-open-source and while the software is still “open” the hardware will strike you down if you try to change it.

While I won’t tell people not to buy a Moto phone again I will say that the Droid X will probably be a bad choice if you’re going to alter the base software or if you want the phone to last a long time.