Dockstar box

This is the box that the Dockstar came in.  Having not bought a non-OEM seagate drive in ages, I was pleasantly surprised that they used normal cardboard instead of some plastic case for this device.  Seagate is really pushing their “Go Green” incentive by changing the entire box (even the box inside) with easy to recycle cardboard instead of that translucent plastic “tray” that normally accompanies electronics.  While not necessarily an indication of product performance, it does show that they care about the environment.

Dockstar contents

Inside the box, aside from the little “Getting Started Manual” is the following items:  A Universal power brick pre-fitted with the US style prongs, a shielded ethernet cable and of course, the dockstar itself.

universal plug sticker

Here’s a closeup of the universal plug and all it’s various warnings and certifications.  I have seen a shift towards these universal plugs and away from the more proprietary plugs that manufacturers would normally use as a cost saving process. Since there is no one world-wide standard on power for every country that Seagate does business with, why spend that money building 20+ different power adapters when all you need is one with different prongs to fit whatever country’s plugs you’re going to be selling to.

Universal Plug details

And, just because I’m a sucker for details (and I keep losing the power bricks), here’s the voltage and amperage rating of the power brick.  Output is 12vDC 2Amps with a positive tip.

Dockstar front

Finally, we get to the dockstar to find what secrets it holds.  The front panel has one LED for device status and the USB mini-B port for the Freeagent drive to sit in.  Unlike most older-style USB devices, the Seagate Freeagent is powered entirely through the USB port, eliminating the need for two cables to power one device.  Overall it’s a simple presentation of what looks to be a fairly complex device.

Dockstar Back

The back of the dockstar has two USB ports, the Gigabit Ethernet port and the power port on it.  I would like for there to have been a link and an activity LED for the Ethernet port, but unfortunately this was not implemented.  I guess I’m a sucker for LEDs.

Right side of dockstar

The right side of the dockstar features another USB port and the reset switch for the device.  The left side of the dockstar (not pictured) only has cooling vents on the side.

Dockstar Bottom

This is the bottom of the dockstar which has a large sticker that shows the serial numbers and MAC address of the device.  Of note, there was one number on this sticker which is formatted like some kind of product activation key and is formatted as follows:  six alphanumeric characters,  hyphen, six alphanumeric characters, hyphen, two alphanumeric characters, hyphen, six alphanumeric characters, hyphen, six alphanumeric characters.   At first glance, I thought these were hexadecimal numbers however the letters used were not between A-F and so it’s currently unclear what this number is for.  There is no mention of what this number is for in the documentation.

Gaining access to the insides

Typically on a device like this and most small consumer devices, there are four screws on the bottom (usually under the black slip-resistant dots) however the Dockstar doesn’t have any.  In order to gain access, I used a metal spudger to work the bottom away from the top half of the body.  There are two notches on each side of the square base, so you may need to use something flat like a spudger, small flathead screwdriver or a expansion slot blank to pry it open.

Cracked the case

Once you cracked the case open (hopefully without breaking it), you should see the small cable that connects the top USB port to the dockstar’s mainboard.  Carefully disconnect this cable and the two halves should now be seperated.

Mainboard top view

This is the dockstar in all it’s nude glory. The front of the device is to the right in this photograph. The small black square is Nanya 1Gb (comes out to ~128 megabytes)  DDR-2 RAM in a BGA package. Datasheet available here and the large square is the device’s main processor.  From research I have performed, this appears to be a Marvell 1.2GHZ processor (just like the sheevaplug devices that Marvell is also selling. I tried to pull some more datasheets from plugcomputer.org, but their datasheet listing is quite lacking.  For now, just know that it’s an arm compliant processor and when I post an update article, I will have more juicy details on the capabilities of the processor.  Also of note, just below and to the right of the processor is a small ten pin header.  Presumably this can be used for a serial port however I do not have the cable for that.  Once I get it in and test it, I will update this article with a pinout diagram for you. Since this device is so low-level I would not recommend trying to connect a regular serial port to it directly as it more than likely requires a level shifter like a MAX232 to bring the -12/+12VDC down into something that won’t blast the components.

Mainboard bottom

This is the bottom of the dockstar’s mainboard.  Unfortunately, the board is now oriented that the front of the dockstar is now at the bottom of the picture. (Bad cameraman, no cookie.)  There’s not really much to note here as the board layout is jam packed with passive components.  The large black square on the lower right is the NAND storage for the device and while I couldn’t pull up the datasheet for it, the guys over at PlugPBX already had a forum post that showed the Dockstar’s hardware specs for us.  According to their chart, the dockstar’s storage is 256MB. which should be more than adequate for general Linux fun.  The small chip just under the black tape in the upper right hand corner of the board is presumably the ethernet NIC however googling the chip numbers came up with nothing.

Just looking at the hardware overall, it would appear that the Seagate Dockstar is a very capable device that just needs to be altered to run whatever we choose to run with it.  While the software on the device (stock) comes with a filesharing service called Pogoplug, I do not intend on using that software and will be looking to get this device as far away from stock as possible.  Here is a list of some things I’ve been thinking of doing with it so far:

• Home NAS (without Internet file sharing)
• multihomed router (I have a stack of pegasus USB modules)
• semiportable network notification device (USB to parallel port, HD44780 LCD display)
• realtime data acquisition device (USB logger and serial ports?)
• Apple MT-DAAPd server for streaming music to iTunes installations on your local network

Some sites I’ve seen while doing research have mentioned things from a in-home webserver with databases, to even a PBX server (take a look at www.plugpbx.org)

The big question is:  What would you do with it? Feel free to leave a comment as to what you’d do with this device, suggestions, information, etc.

FIRESTORM_v1

BIG FAT OBNOXIOUS WARNING!:

Because of the Dockstar’s affinity to want to “phone home” thanks to the Pogoplug software,  I would not recommend plugging this into your live network just yet.  In all of the research I have done for this device, just about every site I have seen has posted some kind of warning about this.  The dockstar was originally designed to run with pogoplug which is an internet filesharing service that allows you to access your files from anywhere with Internet connectivity.  I don’t exactly trust an outside third party to have access to my files on a device that is only going to be used on a local network so I have not connected mine up to even test it.  If you are going to do any work with this device, I recommend that you use a dedicated mini-hub or switch and that it not be allowed to connect to the Internet until you have a complete understanding of what all it wants to do.

You can download the update from Sprint at http://shop.sprint.com/en/software_downloads/pda_smartphone/samsung_moment.shtml

Please note: According to the instructions available at the link above, you will need to use a Windows PC to apply the update to your phone.  I will be posting a mirror shortly and it will show up in the “Download Files” page at the top of this page.

I have recently gotten my hands on a new Samsung Moment on the Sprint network. Within the next few days, I will post all the gory details from this Android n00b and will be offering a comparison against the other smartphone I have, the Palm Pre.

(Ok, innuendo aside…)

Well, the Christmas/Yule break is over with and it’s time to get cracking.   If you were like me this holiday season, you were either placed in the position if needing to do a hard drive upgrade for someone else or you received a new hard drive of your own that warrants upgrading.  The CloneZilla site didn’t contain very clear instructions for what to do so I decided to write this howto documenting the process. In this howto, I will cover using the free application “CloneZilla” to perform a hard drive upgrade on a test installation of Windows XP from 4GB to a 10GB drive.

Foreword:

Of course, it’s Christmastime/Yule and I took pity on my girlfriend’s laptop which had two things going against it.  Firstly, it had vista and secondly it had a 80GB hard drive.  I’m not sure why Toshiba in their infinite wisdom only gave it a 80GB HD, but they did. Thankfully I had just completed an upgrade to another machine and had a 250GB hard drive to spare.  So I set out to upgrade her hard drive and fix at least one of the two reasons that her laptop was evil.

A lot of research turned up various solutions however none of them were very viable or were free.  Most of them required two hard drives in one computer and although her laptop did have the solder traces for the second SATA hard drive connector I’m not about to take a soldering iron to her laptop, she’d kill me.  So with that said and with my head still attached to my body, I kept searching.  I found a Live CD application called CloneZilla which had Cloning abilities much like a certain Symantic product but was free and didn’t require extensive configuration to get to work.  Unfortunately the instructions were not very clear at all and after spending a nailbiting hour trying to start the copy, I finally got it done and decided to document the process in case someone else got stuck in the same need that I did.

In this HOWTO, I will be upgrading a 4GB Virtual Disk in VMware with that of a 10GB Virtual disk.  Aside from the fact that it’s all virtualized, this is indeed a true upgrade and is exactly how you would do an upgrade for a real “physical” computer.

Prerequisites

You will need the following items for a successful transfer:

1. The CloneZilla CD available from http://clonezilla.org/ I’m using Clonezilla Live version 1.2.2-31.
2. A Windows computer that has a hard drive with free space greater than the size of the original disk you are upgrading.  (If you’re upgrading a 40GB HD, then this machine must have at least 40GB free on it.) This will be the WIndows Image Server.
3. The hard drive to upgrade
4. A working network where your machine to upgrade can browse the other windows machine’s file shares. (This is CRITICAL, as the other machine will store your disk image for the upgrade.)
5. A case of beer, rum, vodka, etc…

The “other machine” in #2 will be the image server.  This is where CloneCD will copy the files to that make up the disk image.  I will review how to set up a fileshare in Windows for this however any machine that does SMB filesharing can work.  There are other options available however SMB sharing works the easiest.

Process Overview

In this HOWTO, we will be upgrading a Windows XP Virtual Machine with a 4GB HD to a 10 GB HD.  Although I’m using VMware Server to capture the screenshots, this same method can be used to upgrade almost any home Windows computer.  I’m not sure if Windows 7 or if Windows Server 200* will work but in all theory they should too.  The process for upgrading will go something like this:

1. Examine the existing system to upgrade and get existing disk size
2. Configure Windows Image Server to accomodate images
3. Boot system to upgrade with Clonezilla, configure and start copy process
4. Swap out hard drives, reboot with Clonezilla and configure to start the restore process
5. Take whatever OS steps are needed to take advantage of new space. (OS Dependent)

Step 1:  Examine the existing system

This one’s easy.  Just fire up the existing machine and take a look at the hard drive.  In my example system, there’s only one hard drive.  All I did in this screenshot was open My Computer and Right Click on Local Disk C: then go to “Properties”:

Test system to upgrade

If a machine has more than one partition, you might need to go to Local Disk Managment (Start -> Run -> diskmgmt.msc ) Here’s a screenshot of what our test system looks like through Disk managment:

System To Upgrade (Disk managment view)

Based on this information and according to disk managment, the minimum free space we need on our windows image server will be 4GB.  I would recommend an extra GB just in case. Now that we know how big the disk is and how much space we need, let’s get the image server configured.

Step 2:  Configuration of the Windows image server

This section covers how to set up the Windows Image server for the new image.  We will need to create a new directory for the image files, create a new user on the server and then assign that user with full permissions to that directory over the network.

Step 2a: Add the user

Right click on the My Computer Icon and go to Manage

"Manage" option in Rt Click menu, Easy way to get to users and Groups

This will bring up the Computer Managment Console.  Click on the “+” next to “Users and Groups”, then click on Users.  This will show you all of the currently installed users on the system and should resemble something like below:

Users view in Computer Managment

Right click on the right side of the window and click on “New User…”

Users and Groups Right Click Menu

In the “New User” dialog box that pops up, you want to set the following options:  Username = clone Description = CloneZilla user”, Password = clone  “User Cannot Change Password” and “Password Never Expires” should both be checked. “Account Is Disabled” and “User Must Change password at next login” should be cleared (unchecked).  See below for the reference screenshot:

New User Settings

Click “Create” and then click “Close”.  You can see the new user in the screenshot below highlighted in a red box.

Our new Clone user

Step 2B: Configure the file share and add the user to the share.

Now that we have the user in the system, we need to create the file share. In this case, I’m using a directory inside my “D:” drive to store the images.  MAKE SURE THAT WHERE YOU STORE YOUR IMAGES EXCEEDS THE CAPACITY OF THE DRIVE TO BE COPIED! In our case, we found that the system to upgrade is 4GB, so we need at least a 5GB disk to copy to.

Go ahead and locate a suitable place for your clone files.  In this case “D:” is completely blank except for the system files that Windows generates for partitions.  Right click and create a new folder called “clone”

My clone directory

Right click on the clone folder and go to “Sharing and Security”.  Fill out the form and name the share “Clone” however don’t click OK just yet.

clone directory sharing properties

We need to make sure that the “clone” user we created earlier has full access permissions to this directory.  Click on “Permissions” and add the “clone” user to the directory with full permissions.To do this, click “Add” on the Permissions screen, type in “clone”, type in “Check Names”, then hit OK.  In my case, it added “ZEUS\clone” which is still correct.  ZEUS is the name of the image server.

Adding clone to sharing permissions

Now, I have “clone” added to the permissions window and set the proper access permissions for that username as shown below.  Go ahead and click OK to the Permissions window and to the sharing properties window.

Permissions are set

If all works well, you should see a “waiter’s hand” appear below the directory icon.  This hand icon shows that this directory is shared across the network and is available for access be it read-only or read/write.  At this point, we are done with configuring the server.  We’ve added the “clone” user to the server, added a suitable “clone” directory for Clonezilla to store and retrieve the disk image’s files from and we have added proper permissions to the directory for the clone user.

Step 2c:  Test it out!

Go back to our initial machine to upgrade.  You should be able to find your image server by browsing “My Network Places”.  In my case, the image server was named “zeus” and showed up only after I clicked on “View Workgroup Computers” as shown in this screenshot.  You should get a similar password prompt when you try to access your image server:

Clone share testing

Login with the user credentials we created in 2A, (username and password of “clone”) and you should be presented with a directory listing like the one shown below:

directory listing

We have proven that our clone user works, but let’s test to make sure that we can write to it.  Double click on the clone share and try to create a text file.  (Right Click -> New -> Text File)  If it creates a “New Text File.txt” like shown below, this means that your permissions are correct and you’re good to go.  If you get any kind of read/write error, check your permissions on the image server.

Write test for clone user

If you’ve gotten this far, then congratulations, you’re ready to do the copy.  Go ahead and shut down the system you’re upgrading and get ready for the next step:

Step 3:  Boot system to upgrade with Clonezilla, configure and start copy process

Go ahead and boot the upgrade system with the CloneZilla CD. You will be presented with a boot menu like the one below. Go ahead and select the first menu option “Clonezilla live (Default Settings, VGA 1024×768)”:

Clonezilla Boot Menu

It will then take a bit and flash a lot of linux based stuff at you.  Finally you should be directed to choose a language.  The prompt should look like this now:

Choose a language menu

You will then get a prompt about keymaps.  When in doubt, just leave it alone.

Keymap prompt

More console stuff will flash past and then you’ll get the prompt you’ve been waiting for.  Unless you’re very very advanced, you will only use the “Start Clonezilla” menu option:

Start Clonezilla

Now we’re at a screen that is really confusing.  We want to work with the disks but we also want to work with images to create partitions.  In this instance, we’re going from the disk to an image file on our windows image server then back to disk again.  In our instance, we will need to use option 1, Device-Image.

Image/Disk option menu

In this screen, it’s asking where are we storing the image.  The answer is “samba/Network Neighborhood server” however if we needed to, we could use a local SSH server as well.

Image Server Type dialog

Now it’s asking how we connect to our network.  99% of the time this will be “dhcp” as you will know if you’re using static for anything.  If you have a Linksys router or similar router/firewall device, select DHCP.

network type dialog

After you get a successful IP address, CloneZilla needs to know what IP address your windows image server is.  In my example, the windows image server (zeus) is 192.168.0.5.

IP address dialog

Next, Clonezilla needs to ask for the Domain.  If you are not using a domain, then tab to “Cancel” and hit Enter.  I’m not using a domain here, so I just hit Cancel.  This is reserved for corporate networks that use a special server called a Domain Controller.

Domain prompt

Now Clonezilla needs to know the username of the account to connect to the server.  This will be the username and password you created in Step 2 above.  For our test, we put clone as the username

user prompt

Clonezilla prompts us for the location (the share name) of where to put the images.  In the steps above, we used “clone” as the share name.  This is the location we give to Clonezilla so it can store its images. Be sure to leave the leading / at the beginning of the directory name.

directory name for images

Next, it’s time for the password.  When prompted, type in the password.  Although this prompt looks different than the others, this is not a sign that something has gone wrong so relax.

password dialog

If all of the information you entered was correct, you will get a filesystem mount listing similar to what is shown here.  If something went wrong, you’ll get an error message outlining the possible error and a chance to re-enter the information.  If it doesn’t give you the option to reenter or something isn’t right, just hit the power switch..  In this screenshot, you can see that the last line starting with //192.168.0.5……  is our image server and that it is mounted correctly!

mount listing

Since we have successfully mounted our image storage as part of the liveCD’s filesystem, it’s time to start the copy.  You will be prompted for which mode to run Clonezilla in.  I recommend the “Beginner” method as it makes the entire copy easy.

Mode select dialog

Now we are prompted on what to do.  We will start off by selecting the first option “savedisk” as we want to save the existing disk to the image server.  We will use “restoredisk”  later.

Function Select

If you are wanting to manage multiple images, you have the option to name them with something more descriptive .  For now, I selected the default name which is in YYYY-MM-DD-HH format.

Image Name Select prompt

Now we tell CloneCD which hard drive to copy.  In most systems, there will only be one hard drive, however make sure you have the right one if not.  You can select and deselect by using the space bar to toggle the asterisk.  An asterisk in the brackets “[*]” means that the item is selected however the brackets alone “[ ]” means the item is deselected.

Drive Select prompt

One last word from Clonezilla before it starts copying.  If we wanted to run in console mode (which I will never do. ) we could do it all with one command.  Just hit enter to get past this prompt and start the copying.   This also tells us that it has successfully found and identified the drive we selected to copy and shut down Linux’s logical volume manager to allow direct access to the disk to copy.

Pre-copy ready

One last final confirmation that the information we have entered is correct.  Remember that making this image does NOT make any filesystem changes to the original hard drive and in fact, no changes to the original hard drive are ever made.  This is especially good in case you need to revert your upgrade, you can just swap out hard drives and you’re back where you started from.  If everything is correct in the yellow text, go ahead and type “Y” and hit enter.  This will start the copy process.

confirmation prompt

Finally, the copy begins.  Go ahead and grab a soda, watch a movie or something as this will take a considerable amount of time depending on the size of your hard drive.  In my test example transferring a 4GB hard drive, it took roughly 16 minutes to complete.  My girlfriend’s 80GB hard drive took several hours to copy.

Copy Started

At last, the file copy is complete and we are ready to exit Clonezilla:

Copy complete.

Hit “Enter” then hit 0 for power off.  After a few seconds, you will get the message “Please remove the disc, close the tray (if any) and press Enter to continue. Hit enter and your computer should now turn off.  Go ahead and perform the drive swap now. We’re halfway there!

Step 4:  Swap out hard drives, reboot with Clonezilla and configure to start the restore process

Before continuing, you want to make sure that your hard drive is recognized by the BIOS.  In my test setup, I have swapped out the original 4GB VMware disk with a 10GB Vmware disk and it is displayed in the BIOS here:

BIOS showing new hard drive

Just like before, we will use the same options to create the disk image to restore the disk image.    Use all of the instructions in step 2 all the way until you get to the Mode screen shown below.  Instead of selecting “savedisk” like we did at the last screen, we want to use “restoredisk” instead.

Select Mode dialog, revisited

Now we select the image to restore to disk. Since we only have one image listed, this is the one we use.

Select Image dialog

Once we have selected a viable image, now we are prompted to select the target device.  Again, it’s the only hard drive, so it’s the device we want:

Select Target dialog

Just like before, it will tell us that we can rerun this restore using a single command from command mode:

clone command line

This time, the warning needs to be read.  This is just prior to performing any filesystem changes to the new hard drive.   If you are absolutely sure, go ahead and answer “y” to start the restore process:

restore confirmation text

One last time, it asks to make sure you are sure about your restore decision.  If everything is correct, answer “Y”.

Final restore prompt

A good bit of text will go across the screen and you will ultimately end up at a partclone screen like the one below.  The text that you saw earlier is the partition application creating the destination partition for the image.  Once created, partclone takes over and starts restoring the data from the image. Again, grab another drink, (I’ve got a margarita) and wait a few hours for the image to restore.

Partition restore in progress

Once the restore process completes, you will be prompted to power off.  Hit Enter, select option 1 and remove the CD from the CDROM tray when prompted.

restore completed

Once the system reboots, it should automatically start Windows.  If it does, you’re ready to go to the last step!

Step 5: Take whatever OS steps are needed to take advantage of new space. (OS Dependent)

Now these steps depend on which OS you’re using. At this point, we have made an image of the old drive, saved that image to another server and restored it to a new blank drive that is larger than the original image.  As shown earlier, we have a 10GB disk in our machine to upgrade and we have just restored our 4GB image to it. We have successfully booted windows however our disk properties show that the disk image is still 4GB.  (Ignore the disk space used, as I was shutting down the disk image it decided to install 50 windows updates…)

Disk space still the same?

Here is the same shot of the disk managment window after the upgrade/restore.  You can see that it is a 10GB drive, but is still a 4GB partition.

disk managment

Attention Vista Users!!: If you are running Windows Vista, you can use Disk Managment to expand the disk size.  All you have to do is right click on the C: partition shown above then go to “Expand Disk”.  This will walk you through the process for expanding the disk to take up the entire space of your new drive.  I’ll add new instructions to this as soon as my girlfriend lets me use her laptop again.

For those of you not running Vista, keep reading. At this point, we have validated that our restored image works properly.  Now all we need to do is resize the partition to take up the entire disk.  Thankfully clonezilla has a solution for that.  Reboot using the CloneZilla CD. Answer the same questions regarding keymap like you did before except instead of starting clonezilla, we want to enter the Clonezilla shell.

Go to Clonezilla shell

You will get dropped to a text prompt that presents you with several options.  You will want to select option 2, “Enter Command Line Prompt”.  Once done, you will be at a user@debian prompt as shown here:

command prompt

We are going to use the utility “ntfsresize” in order to increase the size of the partition that we restored to the new disk but first we need more information.  Before we get started, run the command “su -” to get to the “root” user. This will allow us to modify the drive’s layout.    At the above menu prompt, hit the digit 2 for “Enter command line prompt” and then type “su -” at the “user@debian ~$” prompt.  The screen should then look like the screen below.

SU to root

Then we will use “fdisk” to get the disk’s full size.  I ran the command “fdisk -l /dev/hda” to get the drive size:

fdisk disk size

This is important as we are going to delete the partition, then recreate the partition.  First off let’s run “fdisk /dev/hda” and use “p” to get the partition size.  In this screen, we see that the partition starts at 1 and ends at 521.  We want it to extend to the rest of the disk.  We’ll start off by using “d” to delete the partition, (FDISK will assume partition 1) and then create a New partition using the defaults as shown below (Use the commands “N” for New partition, “P” for primary partition, and give it partition number 1).  Once we have created the new partition, we will need to set the “System” back to HPFS/NTFS otherwise NTFSresize won’t work properly.  Below is the FDISK responses to these commands we’ve used so far.

FDISK resizing

Now that we’ve create the new partition, we have to reset it’s type.  Use the “t” command and set it to ID of 7 (HPFS/NTFS) and then use “a” to toggle it’s bootable state.  We want to be able to boot into Windows after all.  Use the “w” command to write the partition data to the hard drive and exit.  Now that we have reset the partition size, we can use NTFSResize to expand the NTFS data.  Cross your fingers and run “ntfsresize /dev/hda” and it should produce output like what is shown here.  When run with no additional parameters, NTFSResize should automatically find the beginning and the end of the partition and expand the existing NTFS data to take the entire drive as shown:

NTFSResize

With our newly resized partition we should be able to reboot and get into our Windows environment.  To do that, just type “reboot” and remove the CD when prompted.  Note: The above screenshot missed me using the “a” and “w” commands to toggle bootable status.  Here’s what it looks like:

Bootable flag now set, sorry guys.

Ok, so now that I have fixed my grievous error, it’s time to reboot.  With any luck, your computer will boot Windows and go staight into a chkdsk environment.  THIS IS OK!, this means that Windows sees the new partition size and that it needs to run a consistency check.  DO NOT PANIC!!!  Let the consistency check run, then it will reboot your computer again.  After it boots for the second time, it might prompt to restart because it found new hardware (the new HD).  This is OK as well.  Let the windows installation reboot.  Once it has completed rebooting for the third time,  get your disk properties by right clicking on C: drive and going to Properties.  As shown below, we have successfully resized our partition to take up the entire drive and are now sitting at 10GB (well 9.99GB according to windows.):

Windows XP's new filesize

Here is a screenshot from Windows XP’s Disk managment to show that we used the entire drive:

Disk managment with new partition sizes

At this point, we have successfully finished the migration!  Here’s a rundown of what all we did in this step:

1. We restored the partition to the new drive
2. We verified that the restore worked properly when booted into, e.g windows booted properly and without errors.
3. We then deleted the existing partition, recreated a new partition and then set the partition type and bootable flag using Linux’s FDISK on the Clonezilla CD.
4. We used NTFSResize to expand the NTFS data to take up the entire new resized partition.
5. We then booted into Windows and let it do a filesystem check
6. When Windows was restarted again, we validated through Properties and “Disk Management” that the new disk was used fully.

This was the most complex part of the migration as CloneZilla only goes about 90% of the way to migrating to a new, larger hard drive.  I hope that this howto provides the last 10% that you are looking for.  With this howto and a copy of CloneZilla, you can then upgrade almost ANY hard drive that Linux supports and can even go from IDE to SATA or SATA to IDE if need be.

Afterword:

I sincerely hope that this helps someone out there trying to make sense of a hard drive upgrade.  I know that I learned a lot about partitions and filesystem structures by attempting an upgrade of my girlfriend’s laptop and this Windows XP installation.  I know that working with partitions is a scary thing as you could potentially lose data but keep in mind that your “original” hard drive still has all the original data on it, as does the image that was stored on the windows image server.

The items in this howto can potentially be a life saver especially if you have a family member that keeps messing their computer up.  You could create an image after you have performed all needed windows updates and software installations and then retain it for if something goes wrong.  Rather than having to manually do an OS reload, you can run though this HOWTO in an hour and have their system up and running again, fully patched and ready to go.

I hope that you had a great Christmas/Yule  with your family and look forward to keep going strong in 2010.  As always, thank you for your continued patronage, you are always welcome here at YourWarrantyIsVoid.com!

FIRESTORM_v1

One of the advantages to using alternative firmware on “stock” devices is that it allows you to unlock the full potential of your hardware.  Using the latest version of DD-WRT, you can now enable esternal storage on your WRT54G to add to the default image.  With additional storage for your router, the possibilities are endless.

PLEASE NOTE: The pictures and information for adding the SD cardslot is only applicable to the Version 2 of the Linksys router.  Attempting to do this on newer routers using this guide may result in damage to the router, the SD card or both.  You can not hold me liable for any damage, so please read first and do some research before you crack the case open. The 15 minutes you may spend now may save you some blue smoke later.

Items Required:

• SD card slot – I stole one out of a 4 in one card reader from a failed hacking attempt from another project.
• SD card – Use a cheap one to verify it’s working first, then use whatever size you want.
• A piece of PCB – I used a piece of board that I had left over from another project, but this one from Radio Shack works well too.
• Jumper Wire – If you have multiple colors, this would be beneficial in keeping the lines straight for wiring.
• Small nuts and bolts
• Fine Tip soldering iron
• Dremel cutting tool
• (Optional) Razor Knife or X-acto Knife set

First thing’s first.  This howto only covers the process of adding the card slot to the router and configuring DD-WRT.  It does not cover installing DD-WRT on the router or which router is best for the process.  The process of installing DD-WRT is very very well documented as well as the router’s specs for supported devices over at the DD-WRT Wiki.

Getting to know the SD card

The SD card pinout shown above indicates that although the card has 9 pins, we will only be using 7 of them.  Unlike most devices, the indented pin is not pin 1, but is pin 9, with pin 1 next to it.  Here’s a quick reference showing what each pin is and what it does:

• Pin 1 – Chip Select – When this is brought high, the SD card is “turned on” and allows it to receive data or send data in sync with the CLK pin (pin 5)
• Pin 2 – Data In – This pin is used to receive data from the WRT54G for writing or for commands
• Pin 3 – Vss (GND) – This is a ground pin and is tied to Pin 6 for one less wire to deal with.  It is important that both pins be brought together.
• Pin 4 – VCC (or +5VDC) – This pin supplies power to the SD card.
• Pin 5 – CLK – This is the clock line that the WRT sends to the SD card.  This pin synchronizes the data coming in or going out of the WRT54G so that the SD card has the proper timing to read and write data.
• Pin 6 – Vss (GND) – This pin is also ground.
• Pin 7 – DO – This pin is data out to the WRT54G
• Pin 8 – Not Connected for this project.
• Pin 9 – Also not connected for this project.

We will be using some connections in the WRT54G called GPIOs to connect the various pins of the SD card to the WRT54G’s hardware.  These GPIO pins are already used for other functions, but with the driver built into DD-WRT, we can use them to also control the SD card.

Step 1: Prepare the SD Card slot:

This is a picture of the SD card slot that I will be using.

In this picture, I felt it necessary to scrape off the PCB solder pads under the SD card itself.  This is where the X-acto knife kit comes in handy.  The two solder “dots” in between the screw holes is for anchoring the tabs of the SD card slot and is recommended for making the card slot resistant to damage from repeated inserts and extracts.

In this shot, I have lucked out.  Each of the pins from the card slot match one of the solder pads on the PCB with no difficulty.  This will greatly help soldering the wires to the cardslot.

I recommend starting off with the ground wires, pin3 and pin 6.  The little loop is the bridge between the two.

Wire the rest of the wires to their respective pins on the SD card slot. When all is said and done, you should have 6 wires.   At this point, we’re done with the card slot and we’re ready to start soldering to the WRT54G.

Step 2: Making connections

If you haven’t done so already, go ahead and take the WRT54G apart.

• Start by unplugging the WRT54G’s power and network cables.
• Unscrew both of the antennas and set aside
• Grab the grey part of the WRT54G in one hand and the blue part in your other hand.
• Pull the two halves apart and set the blue part aside.
• Slide the top cover away from the bottom half of the WRT54G.

Now for the hard part.  There are six locations that need to be wired up in order for this to work properly.  We’ll start off with the easy one. Pin 1 (CS) goes to the + side of the DMZ LED.  In this orientation, the component side of the PCB faces away from you, essentially you’re looking up from the bottom.

Attach the pin 1 lead to the right pin of the  DMZ LED.

In this picture, we will be using the In Circuit Programmer port for pin 4 and pins 3,6.  The Pin 4 (+5V) goes to the pin 1 on the ICP port, while the pins 3,6 (GND) goes to pin 10 of the ICP port. Orient the router so that the two antennas point up and away from you and that the component side faces you. The ICP port is an unpopulated 10 pin header located in the lower right hand quadrant of the router’s circuit board.

The next three leads are the most important AND the most difficult.  You can click on the image to get a larger view if you need it.

With the same orientation discussed as before, just south of the ADMtek chip is where the last three pins go.  This is the hardest part of the build as you must attach to a resistor network that itself is very tiny.  It took me several attempts and I had to superglue the wires down so that they wouldn’t move (not shown in this shot).

Here is an EXTREME close up of the resistor network (still same orientation).  This is a 4 resistor chip, with 2 rows of 4 pins each.  Pin 1 is the upper left hand corner and is wired to DI (pin 2) of the SD card. Pin 6 (second from the left on the lower side of the resistor network) goes to the CLK (pin 5) of the SD card, while pin 7 of the resistor network is wired to DO (pin 7) of the SD card.

Step 3: Box it up!

Now that you’ve gotten the card set up, it’s time to put it together.  Now, there are many a howto that have a million and one locations to mount the card slot.  I wanted something that didn’t look kludged together or didn’t have the cardslot sticking out of some random location. I instead chose the back of the WRT, just above the ethernet ports.

Thankfully for me, the SD card was slightly larger than the diameter of the cutting wheel of my Dremel.  Making a single cut was quite easy.

I made my cut just above the Ethernet ports and secured the PCB to the top cover.  The bolts holding the PCB in place were just short enough to clear the RJ45 connection block so no additional work was necessary.

Here’s a view after the WRT54G completely assembled (and also where my Dremel nicked the plastic cover)

One more shot of the completed mod, the only thing I would like to have done is found countersunk bolts.  Unfortunately, I was limited to what I had on hand at the time.  All in all, it’s a very clean modification.

Step 4: Configure DD-WRT

Now all that’s left to do is to configure DD-WRT.  Before we begin, make sure that you have cleared out the SD card of any data you want prior to working with it.  Once we get the card working, the router will format the card with an EXT3 filesystem, erasing anything already on the card.

Go ahead and hook up the router to power and network.  Don’t stick the SD card in just yet, first we have to configure DD-WRT for the card.  Click on “Managment” and scroll down to the “MMC/SD card support”.  Enable it if it’s not already enabled and set the GPIO pins detect to “Manual”.

When you select “Manual”, you will need to put in some numbers for the four signal leads.  I used the following settings:

• DI (Data In) – GPIO 5
• DO (Data Out) – GPIO 3
• CLK (Clock) – GPIO 4
• CS (Chip Select) – GPIO 7

Scroll down, and hit “Save Settings”.  The screen will fade out then fade back in.  Once the screen fades back in, disconnect the power from the WRT and insert your SD card. Power on the router and you should notice that the DMZ LED starts flashing intermittently.  This is good news.

Log back into the DD-WRT admin panel and hopefully, if everything is correct, you will see values filled in for Total/Free Size.  If you do, then congratulations. you’re done!  You can login via Telnet to the router and see that it’s mounted and ready to roll.

From here, you can now compile things on a Linux box, save them to your SD card and then use your SD card to launch your programs on the WRT itself.  Just remember to mount and umount the card and you won’t have to worry about corrupting the filesystem on the card.

Afterword:

Thanks goes out to the DD-WRT user community for making this possible and thanks goes to the original person that hacked out GPIO SD-card support into the kernel running on DD-WRT.

Well, the world is abuzz with all things twitter so I figured that I’d join the fray.  But rather than tweeting about farts being blasted into an office chair or a toilet that twitters or even a tweeting toaster, I decided to do something useful with this thing called Twitter.  I have APCUPSd running on a Linux box that tweets when the server detects a change in power.  Read more to find out how you can incorporate this into your linux server.

After thinking about my network monitor application that “tweets” when a server goes down or comes up unexpectedly, I thought I’d take a look at seeing what it would take to get notified when my server lost power.  I already installed and configured APCUPSd and it was confirmed as working so now I wanted to be notified on power changes.

The whole “twitter” thing had caught on right when I was looking for a solution to a problem I had.  The issue was that I had a server that was randomly dropping offline and freezing and I needed a way to be notified realtime of when the machine went down.  Well I spent a few days developing a network monitor application that has since then grew into quite a nice suite.

I did some research and found out that the Twitter application had an API that could be called to post updates.  I did some further searching and found how to post to Twitter using PHP-CURL, and later on found that CURL was a standalone application that could be called from the commandline. With that, I found out what I needed to do and set it up.

Prerequisites

In order to make this work, you will need the following:

• Root access on a linux box running APCUPSd with a known working good configuration.
• Two twitter accounts, one for your phone and one for your monitor application.
• the CURL application installed on your linux box. (Ubuntu users can apt-get install curl to install it automatically)

I’m not going to cover how to set up a new Twitter account. I’m sure everyone has been beaten over the head with it already.

1:  You must follow your newly created friend

Twitter for SMS will work if these conditions are met:

1. You have a twitter account that you receive twitter messages on.
2. Your twitter account must “follow” your monitor application’s twitter account.

In this case, I have set up “trs_netstat” as my monitor application’s twitter account and I follow it with my own twitter account.

Notes: A cellphone plan with unlimited SMS is a REQUIREMENT, I used almost 2200 SMS messages last month.  I also recommend enabling privacy mode on your accounts so that way you’re not broadcasting to the world that your UPS is running on battery.

In order to make sure that your computer can successfully communicate with Twitter, use the syntax below:


root@linux ~ # curl -u {twitter username}:{twitter password} -d status="This is a test message." http://twitter.com/statuses/update.xml


If everything works the way it should, you should in turn get a lot of XML data back.  This is a good thing.  If you got a lot of XML data but no post on the Twitter site, look for the following line in your XML


<error>Not found</error>


This means that the URL you specified is incorrect, and other errors will show up in the XML, typically with the <error></error> tags.

2: Create the scripts… or not?

I read up on the APCUPSD website on how to customize how apcupsd behaves when certain events are triggered.

To write your own routine for the powerout action, you create shell script named powerout and put it in the lib directory (normally /etc/apcupsd). When the powerout action is invoked by apcupsd, apccontrol will first give control to your script. If you want apccontrol to continue with the default action, simply exit your script with an exit status of zero. If you do not want apccontrol to continue with the default action, your script should exit with the special exit code of 99. However, in this case, please be aware that you must ensure proper shutdown of your machine if necessary.

So waitasec… APCUPSd supports 21 different configuration options.  So if I want to get notification of all 21 events, I gotta write 21 scripts or create 21 symlinks?  How about, “Heck no!”

By adding a call to my script within apccontrol, I can ensure that I get all the notifications that apcupsd would send and there would be no need to set up 21 symlinks.

In my /etc/apcupsd/apccontrol on line 58, I added the call to my twitapc script shown below:

     if [ $? = 99 ] ; then
         exit 0
    fi
 fi
 ${SCRIPTDIR}/twitapc ${1} ${2} ${3} {$4}
 case "$1" in
     killpower)
         echo "Apccontrol doing: ${APCUPSD} --killpower on UPS ${2}"

The line that starts off with ${SCRIPTDIR} is the one you want to add.  The ${1} ${2} ${3} {$4} is important as this hands off variables that apccontrol was invoked with to twitapc for action.  Some of the variables passed are actions like “killpower” shown above, and one of them includes the UPS name.  You want to keep this information with twitapc so that you get these notifications.

3: Add my script to your configuration (or ….)

This is the twitapc script.  If it looks identical to the apccontrol script, that’s because it is.  I copied apccontrol and changed some of the variables to perform the calls I needed. Theapccontrol script already covered the events with good coverage so there wasn’t a need to rewrite an entire script.

#!/bin/sh
#
# Copyright (C) 1999-2002 Riccardo Facchetti
#
#  for apcupsd release 3.14.2 (15 September 2007) - debian
#
# platforms/apccontrol.  Generated from apccontrol.in by configure.
#
#  Note, this is a generic file that can be used by most
#   systems. If a particular system needs to have something
#   special, start with this file, and put a copy in the
#   platform subdirectory.
#
#
# These variables are needed for set up the autoconf other variables.
#
#----------------------------------------------------------------------
#
# Script modified for twitapc by FIRESTORM_v1.
#
#
#
#
#
#

prefix=/usr
exec_prefix=${prefix}

APCPID=/var/run/apcupsd.pid
APCUPSD=/sbin/apcupsd
SHUTDOWN=/sbin/shutdown
SCRIPTSHELL=/bin/sh
SCRIPTDIR=/etc/apcupsd
WALL=wall

#
#Leave the lines above alone, these are the lines you want to edit:
#
#
#
tw_user='Twitter Username'
tw_pass='Twitter Password'
tw_url='http://twitter.com/statuses/update.xml'
timestamp=$(date +%m%d%Y-%H%M)

case "$1" in
 killpower)
 msg="Apccontrol doing: ${APCUPSD} --killpower on UPS ${2}"
 sleep 10
 msg="Apccontrol has done: ${APCUPSD} --killpower on UPS ${2}"
 ;;
 commfailure)
 msg="Warning communications lost with UPS ${2}"
 ;;
 commok)
 msg="Communications restored with UPS ${2}"
 ;;
#
# powerout, onbattery, offbattery, mainsback events occur
#   in that order.
#
 powerout)
 ;;
 onbattery)
 msg="Power failure on UPS ${2}. Running on batteries."
 ;;
 offbattery)
 msg="Power has returned on UPS ${2}..."
 ;;
 mainsback)
 msg="Mains power restored on UPS ${2}..."
 ;;
 failing)
 msg="Battery power exhaused on UPS ${2}. Doing shutdown."
 ;;
 timeout)
 msg="Battery time limit exceeded on UPS ${2}. Doing shutdown."
 ;;
 loadlimit)
 msg="Remaining battery charge below limit on UPS ${2}. Doing shutdown."
 ;;
 runlimit)
 msg="Remaining battery runtime below limit on UPS ${2}. Doing shutdown."
 ;;
 doreboot)
 msg="UPS ${2} initiating Reboot Sequence"
 ;;
 doshutdown)
 msg="UPS ${2} initiated Shutdown Sequence"
 ;;
 annoyme)
 msg="Power problems with UPS ${2}. Please logoff."
 ;;
 emergency)
 msg="Emergency Shutdown. Possible battery failure on UPS ${2}."
 ;;
 changeme)
 msg="Emergency! Batteries have failed on UPS ${2}. Change them NOW"
 ;;
 remotedown)
 msg="Remote Shutdown. Beginning Shutdown Sequence."
 ;;
 startselftest)
 ;;
 endselftest)
 ;;
 battdetach)
 ;;
 twittest)
 msg="TwitAPC Test Message"
 echo "Test message sent. Please check your phone."
 ;;
 battattach)
 ;;
 *)  echo "Usage: ${0##*/} command"
 echo "       warning: this script is intended to be launched by"
 echo "       apcupsd and should never be launched by users."
 echo " To test your twitter connection, run the below command:"
 echo " # twitapc twittest"
 exit 1
 ;;
esac

if [ -n "$msg" ]

 then
 curl -o /dev/null -s -u $tw_user:$tw_pass -d status="$msg ::$timestamp" $tw_url
fi

( I apologize that this code is not properly indented. The HTML editor application stripped out the whitespace. )

All that is needed is to adjust the $tw_username and the tw_password to match your account settings. If you want to test it, just run it from command line with the parameter twittest

root@littleblackbox:/etc/apcupsd# ./twitapc twittest
Test message sent. Please check your phone.

This will send the test message.  If it isn’t working for you, remove the “-o /dev/null -s ” from the curl statement at the bottom of the script.

4:  Profit!!!

If the twitter test message worked, then you’re in it for real.  Test it out by, you guessed it, pulling out the UPS power cord from the wall socket.  Of course the UPS will switch to battery and will start beeping, but within a few seconds, you should get a text message from Twitter with the user ID of the account specified in twitapc.

After a few seconds, plug it back in and you should get two more after power is restored and the system is back to normal.

Here is a screenshot of my network monitor twitter page with some sample notifications on it.

I added a timestamp to the script as my phone doesn’t always display timestamps on it’s text messages. It’s formatted MMDDYYYY-HHMM and can be easily changed in the script

I am always interested to hear your comments and your suggestions.  If you have a success story, by all means tell me.
Have fun and happy twitter-ups-ing..

FIRESTORM_v1

This howto will cover performing the necessary steps for configuring Ubuntu Server 9.04 to distribute pxelinux images over the network for you to use to install Ubuntu or your favorite Linux distribution over the network. No more fumbling for installation CDs or boot floppies!

I have done countless Linux installations where a Boot CD or a boot floppy was required to install with. Typically I’d find that media was scratched or otherwise inoperable. Fed up with it, I sought out a solution to make it work to where I didn’t need a CD or a floppy disk. This HOWTO will take you from a Ubuntu server to an Ubuntu Server that now allows for TFTP booting! It’s not as hard as it sounds and I completed my installation in little over an hour. The longest part was to mount the CDROM images and perform the copy.

While not all network adapters support PXE booting, most onboard NICs do. If unsure, there’s nothing wrong with keeping a network bootable NIC in your parts drawer for use later.

Prerequisites:

Required:

• Root access on a computer already set up with Ubuntu Server that has a valid IP address and is connected to the network.
• A computer with a bootable network card (I recommend the Intel Pro 100 series) or an installation of VMware for testing the TFTP boot environment.
• A Hub, Switch or router that can act like a hub or switch.
• Linux installation CDs of the distribution you want to use. (For this installation, I will be using CentOS 5 as the install to make available on the network)
• Access to edit the DHCP configuration of the server handing out IP addresses.
• A copy of the Ultimate Boot CD, or the ISO image to the UBCD. The UBCD can be downloaded from http://www.ultimatebootcd.com/
• A copy of the pxelinux.0 file from http://syslinux.zytor.com/

This document assumes that you have basic knowledge of Linux as far as navigating the filesystem and filesystem structure. Since this is considered “administration level” work, this will require that you work as the “root” user and understand the ramifications of using this level of access. If you have questions about a specific command, either continue reading without performing the step or perform some Google searches to find out what the command does. This document will not require you to compile anything or know any significant amount of code and examples are provided so that you can cut and paste as much as possible.

Overview

This howto is broken up into several sections to make reading a bit easier. Feel free to leave comments on what works and what doesn’t and ask for help if you desire.

• Installation and configuration of tftpd-hpa for Ubuntu
• File placement in the /tftpboot directory
• Configuration of pxelinux.0 and the DHCP server
• Installation of VSFTPd for Ubuntu
• MD5sum, Mounting, Copying and Unmounting the disk images
• Configuring boot menus using the menu.c32 from the UBCD
• Troubleshooting
• Tips and Tricks

Commands that you can use are highlighted in bold with examples being shown in a code box.

WARNING: This signifies a critical message that needs to be read and understood prior to command execution otherwise system damage may result

NOTE: This is an informational note that you might want to consider for better understanding od a command used.

Options in italics are parameters to a command that need to be supplied. If an option is surrounded by curly brackets {like this} it is indicating an additional option that may vary on your system. If an option shows up in bold and italics , then it is meant to be used together as a command referenced.

“Files in quotes” are either representative of screen output or a file that will be worked with. This will be context sensitive.

Installation and Configuration of TFTPD-HPA for Ubuntu

With all that prep talk out of the way, let’s get started. Go ahead and log into the server that you will be performing the install on.

First off, let’s make sure that you’re root, by typing whoami in the login window:

root@littleblackbox:~# whoami
root

If whoami returns something other than “root”, then either su – and become root or ask for assistance.

Now that you’re root, we will tell the server to get the tftpd-hpa package from the Ubuntu repository. We’ll use the command apt-get install tftpd-hpa This will tell apt-get to fetch the application and install it to your machine so you can use it.

root@littleblackbox:~# apt-get install tftpd-hpa
 

You will see a lot of fetch text scroll back but as long as it shows up that “tftpd-hpa installed successfully” then you are good to go on to the next step. First off, we need to decide where the “tftpboot” directory will live that is used by tftpd-hpa to distribute.

NOTE: Ubuntu by default will create a “/var/lib/tftpboot” directory as part of the tftpd-hpa installation. You can keep this path if you want, however in my installation I chose to go with “/tftpboot” instead. If you wish to use “/var/lib/tftpboot” then be sure to substitute that path in place of “/tftpboot”.

I went ahead and created the “/tftpboot” directory by using the following command:

 root@littleblackbox:~# mkdir /tftpboot

Now that we have the directory, we need to edit the “/etc/defaut/tftpd-hpa” file so that the application has the correct information to start:

#Defaults for tftpd-hpa
RUN_DAEMON="no"
OPTIONS="-l -s /var/lib/tftpboot"

Change the “RUN_DAEMON” from no to yes, and change the “OPTIONS” to reflect where you want the tftpboot files to go. My file looks like the one below:

#Defaults for tftpd-hpa
RUN_DAEMON="yes"
OPTIONS="-l -s /tftpboot"
 

This tells the tftpd-hpa application to always run and that we want to use the “/tftpboot” directory to serve our image. Now we need to start the service:

root@littleblackbox:~# /etc/init.d/tftpd-hpa start
Starting HPA's tftpd: in.tftpd.

If the display shows “in.tftpd.” then you’re successful, Pretty easy so far, but now we get into the harder stuff.

File Placement in the /tftpboot directory

Now that we have our tftp server running, let’s put some files in place.

• Copy the pxelinux.0 to /tftpboot
• Copy the menu.c32, chain.c32 from the UBCD to /tftpboot
• Copy the memtest image from the UBCD to /tftpboot/images
• Copy the defaults.cfg from the UBCD to /tftpboot/menus/

While you’re at it, let’s make two directories as well:

root@littleblackbox:/tftpboot#mkdir menus
root@littleblackbox:/tftpboot#mkdir images
root@littleblackbox:/tftpboot#mkdir pxelinux.cfg

The “menus” directory will be where we will place the menu files, the “images” directory is for the boot disk images that we’ll link to in the menus that we’ll create, and the “pxelinux.cfg” directory will be where we place the configuration file for the PXE loader. The PXE loader is capable of so much more than just what we’re doing here, but that is way outside the scope of this howto.

NOTE: Keeping this directory organized is important. Duplicate filenames and mis-coded directory paths are the most common foul-ups when working with tftp or when working with files in general. Cleanliness may be next to Godliness, but in a linux server, it’s vital to prevent “oops”es.

Configuration of pxelinux.0 and the DHCP server

Some of you that did some prior research may be screaming “What about the DHCP server?” Well that’s coming up, but first we gotta finish building the TFTP configuration so we can test it first.

First off, let’s create a file in “/tftpboot/pxelinux.cfg” called “default”. This is important because as soon as PXElinux bootstraps the machine, it’s going to want to find a configuration file. If no file is specified, the machine will scout about looking for a configuration in the “pxelinux.cfg” directory until it either finds one at which point it will boot the image specified or it will give up and sit there with some error on the screen.

For the “default” configuration file, copy and paste this in.

default main
 prompt 1
 timeout 15
 label main
 kernel menu.c32
 append menus/main.mnu
 

The first line default tells pxelinux to show the item with the same label as the default selected boot option. If the timeout value is reached (15 seconds), then that boot image is started if it is available.

The second line prompt 1 forces pxelinux to show the “boot:” prompt after it has loaded.

The third line timeout 15 sets the boot delay to give you the option of entering a boot image. It’s not really used in this configuration as we will be “booting” the menu system, but it’s there to keep the configuration standards compliant, which is always a good thing.

The fourth, fifth and sixth lines make up the default boot image that we want to load and is a format you’ll want to remember for later. It will come back to you again.

1. LABEL main – This is how the item is presented at boot time (or menu generation time).
2. KERNEL menu.c32 – This is the kernel image to boot if the option is selected.
3. APPEND menus/main.mnu – This line specifies any additional kernel level options that the kernel needs to operate. Typically there may be a call to an initrd (initial ramdisk) or some other commands. This specific line tells the “menu.c32″ menu kernel to load the “menus/main.mnu” menu as a boot parameter to get the menu to render.

Save the file as “default” within the “/tftpboot/pxelinux.cfg” directory. Now that we have the default configuration created, it’s time to create the first menu. Don’t worry too much about the parameters right now as we’ll go over them in the next section. Copy and past this into a text editor and save it as “main.mnu”

MENU INCLUDE /menus/defaults.cfg
LABEL memtest
 MENU LABEL Memtest86 V3.3
 KERNEL /images/memtest

This will be the first menu in your menu system. Since we’ve finished with the tftpboot directory, let’s compare. I use the command tree to print out this list, you can apt-get install tree to compare it or just compare the list with your “/tftpboot” directory contents:

root@littleblackbox:/# tree /tftpboot
/tftpboot
|-- images
| `-- memtest
|-- menu.c32
|-- menus
| |-- defaults.cfg
| `-- main.mnu
|-- pxelinux.0
`-- pxelinux.cfg
     `-- default

Now, there is one critical bad thing that we’ve been missing. It’s also the only thing preventing us from testing the installation at this point. We need to configure the DHCP server!

NOTE: The following instructions are for Linux and are tailored for a situation where the DHCP server is on the same computer as the TFTP server. This is important as the directives we add to your configuration tell the TFTP client where to go to get the image needed to boot the machine. If you have another server that serves IP addresses via DHCP, then you will need to adjust the IP address to point to the IP of the tftp server. If you cannot adjust your DHCP server’s parameters, consider starting a DHCP server on this machine instead of using the unadjustable DHCP server.

When the PXE (or Preboot eXecution Environment) starts a machine, it has just enough software to initialize the NIC and pull for an IP address. When the DHCP server responds to the PXE’s request, along with the IP address, it will provide a TFTP server address and the image name for booting. The PXE then takes this information and attempts to download and execute the image from the TFTP server.

What this means is that you don’t have to have the TFTP server on the same machine as the DHCP server but you DO have to be able to get the TFTP server’s IP and the image name into the DHCP server. Otherwise, the PXE will be attempting to talk to a server that doesn’t exist or doesn’t have a TFTP service running or worse yet doesn’t have the image you’re looking for.

WARNING: Editing the DHCP configuration file is platform dependent. On Ubuntu, the configuration file is named “dhcpd.conf” and is located in “/etc/dhcp3″ while Redhat on the other hand still calls their file name “dhcpd.conf” but stores it directly in “/etc”. Your configuration may differ, you will need to find your configuration file and edit manually.

Edit the DHCP configuration file and within your subnet declaration, add two lines:

next-server 192.168.0.2;
filename "/pxelinux.0";

Here is a sample subnet declaration from my dhcpd.conf. Don’t copy and paste the below text into your configuration as the directives may not match yours.

subnet 192.168.0.0 netmask 255.255.255.0 {
 range 192.168.0.20 192.168.0.50;
 default-lease-time 86400;
 max-lease-time 86400;
 option routers 192.168.0.1;
 option broadcast-address 192.168.0.255;
 option subnet-mask 255.255.255.0;
 next-server 192.168.0.2;
 filename "/pxelinux.0";

The next-server directive specifies the IP address of the TFTP server and the filename directive specifies the path to the image to boot.

NOTE: All paths are relative according to “/” (the root) of the TFTP server. So even though the file is “/tftpboot/pxelinux.0″ the filename specified here is just “/pxelinux.0″ because the “/” of the TFTP server is the directory “/tftpboot”. Confused? Good. :p

Restart your DHCP Server with the command below:

root@littleblackbox:/# /etc/init.d/dhcp3-server restart
* Stopping DHCP server dhcpd3 [ OK ]
* Starting DHCP server dhcpd3 [ OK ]
root@littleblackbox:/#

If your server restarted, let’s test it out! Get your test rig or VMware installation together and try it out. If everything is properly in place, you should boot to a blue screen with “Memtest 86 V3.3″ highlighted. Hit the “enter” key and see if it starts Memtest. If it does, then congratulations, you’re up and running. If it doesn’t work, scroll down to “Troubleshooting” and take a look at possible causes.

Here is a screenshot of PXElinux booting:

Here is an image of the PXEboot menu.  You will only have the first option.  I configured my server first then thought this would make a good HOWTO so the other menu entries come up later.

Hit enter and launch Memtest.  It should drop you to a screen that looks something like this:

If you’ve gotten this far and your test station launched Memtest with no errors, it’s time to go to the next section and set up VSFTPd so we can actually have stuff to install. As it is, you have a fully capable memory tester on your hands.  All you need now is a computer that boots from TFTP and you no longer need to look for those long lost Memtest floppies! Of course, this is merely scratching the surface of what you can do.  Let’s go on to the next section where we will start getting a major distribution in place for installation.

Installation of VSFTPd for Ubuntu

Well, we have made it this far and we’re actually closer to completion than you would think.  So far we have accomplished the following tasks:

1. We’ve set up tftpd-hpa on our Ubuntu server.
2. We’ve configured it to stay running in memory and given it a location and files to serve.
3. We’ve configured pxelinux so that the client can find all the files necessary to boot the menu system.
4. We’ve configured the menu system with a test image to distribute and,
5. We have successfully TFTPbooted pxelinux, the menu system and the memtest image and know it all works.

Now we need to install VSFTPd which is an FTP server for Linux.  “Why FTP?”, you ask.  The reason is simple.  FTP is easier to configure than Apache (the Linux Webserver) and is the default network installation method for most linux distributions.  While technically you could install using HTTP, you’d have to configure Apache on your server and if you’re using Apache to host files to the public internet, then you’d have to create a virtual host and all that mess.  FTP is much easier to set up and easier in this case is a good thing.

So, let’s start off by installing VSFTPd

root@littleblackbox:/# apt-get install vsftpd

You’ll see a lot of text fly by and at the end you will see that the server was started.  Unlike most FTP servers, VSFTPd has it’s own home directory in “/home” and not “/var/lib/ftp” or “/var/ftp” (as is common on some RedHat systems.  Now that we have the VSFTPd server installed, it’s time for more directory creating.  Since I use my FTP server for more than just storing images and installation media, I recommend the below hierachy to keep everything making sense.   Remember the note from the file placement section about keeping things clean?  Well now it’s going to get implemented to the extreme.  Since this is YOUR ftp server, you can do whatever you want, but take these guidelines into advisement:

• Keep your installation files away from other files by placing them in a different directory
• Keep your directory structure simple, but don’t afraid to use subdirectories.
• On the other hand, don’t use too many subdirectories.  You don’t want to have to remember a long path like “/dist/var/ftp/server/os/i386/redhat/Centos/5.2/installer” but simply copying everything into the FTP server’s “/” is strongly discouraged.

With my server, I have chosen this directory heirachy:

• /bootdisks – images for boot floppies, should I ever need one, here they are.
• /dist – This tells me that there are complete linux distributions available in this folder.
• /dist/iso – This tells me that the .iso CD images of the distributions available are here.
• /dist/installer – This tells me that the installers I’m looking for are located here.
• /dist/installer/centos5 – This tells me that the installer distribution for CentOS5 is in this directory.  This is the directory I give to the installer later.

Note: As stated previously, you don’t HAVE to use this heirachy, you could use /centos5 as your installation directory if you want.  If you are net-installing a bunch of distributions however, your FTP server root could get messy.

Ok, enough talk about orginazation, let’s get to making files:

root@littleblackbox:/# cd /home/ftp
root@littleblackbox:/home/ftp# mkdir bootdisks
root@littleblackbox:/home/ftp# mkdir dist
root@littleblackbox:/home/ftp# mkdir dist/iso
root@littleblackbox:/home/ftp# mkdir dist/installer
root@littleblackbox:/home/ftp# mkdir dist/installer/centos5

MD5sum, Mounting, Copying and Unmounting the disk images

If you haven’t already done so, go ahead and copy the CD images into your Ubuntu server.  You can use any folder, although a temporary empty folder is recommended.  I copied my files into ~/CentOS5. If available, make sure you copy the MD5sum file along with them to your temporary directory on the server.

CD into the directory and we can use MD5 to check these files using the syntax below:

root@littleblackbox:~/Centos5# md5sum -c md5sum.txt

This command ‘md5sum’ generates an MD5 hash which should be identical to what is in md5sum.txt. The MD5 hash is like a special checksum validation that you can use to validate that downloaded files match their sources on the server you downloaded them from. Using the above command, I get the below results indicating a valid match. If one of the files had been changed by even so much as a comma in a configuration file on the ISO, the test would have failed.

root@littleblackbox:~/Centos5# md5sum -c md5sum.txt
CentOS-5.3-i386-bin-1of6.iso: OK
CentOS-5.3-i386-bin-2of6.iso: OK
CentOS-5.3-i386-bin-3of6.iso: OK
CentOS-5.3-i386-bin-4of6.iso: OK
CentOS-5.3-i386-bin-5of6.iso: OK
CentOS-5.3-i386-bin-6of6.iso: OK
root@littleblackbox:~/Centos5#

If you don’t have the md5sum.txt, you can still use the md5sum application. Use the command below to generate the MD5 checksums of the ISO images:

root@littleblackbox:~/Centos5# md5sum *.iso

This command will output the MD5 checksum and the filename for each of the files. You then compare this to what is listed on the server where you got them and compare the numbers. If they do not match, you know you got a corrupted download. Here is the MD5sums of the ISO images I have:

dd93a6da1b900548825159206099603c  CentOS-5.3-i386-bin-1of6.iso
 5441ae0a3c9efd47cd8bfab873fe20c1  CentOS-5.3-i386-bin-2of6.iso
 024ca72da4e14f79522a90bf8f4fdf9f  CentOS-5.3-i386-bin-3of6.iso
 95e5e446754e76b3fa07aaf4946c0aa9  CentOS-5.3-i386-bin-4of6.iso
 0cda242797ded4b6b2ea0469984aca82  CentOS-5.3-i386-bin-5of6.iso
 889ff6389108a85780a06cd38b7375e7  CentOS-5.3-i386-bin-6of6.iso

We have our FTP server and we have our validated ISO images. Now it’s time to get messy. The next part comes in mounting these CD iso images, then copying their contents to the FTP directory we made earlier. This can be tedious and can be done incorrectly, rendering a good amount of time wasted if you aren’t careful.

NOTE: The instructions here are specific for CentOS 5.3 but are commonly applied to most CD based distribution  installers. When in doubt, check with your distribution’s web site about what you need to do to perform a network installation.  Some distribution vendors may require a different file path be created.

We’ll start off by creating a temporary directory within the temporary directory called “source” and another one called “destination” and then mount the first ISO image into the source directory by use of the loopback option. Once mounted, we’re going to copy everything from source and put it in destination, then unmount the ISO image and repeat for the other 5 images. You can see the commands I used below.

root@littleblackbox:~/Centos5# mkdir source
root@littleblackbox:~/Centos5# mkdir destination
root@littleblackbox:~/Centos5# mount -o loop CentOS-5.3-i386-bin-1of6.iso /source
root@littleblackbox:~/Centos5# cp -R ./source/* ./destination
root@littleblackbox:~/Centos5# umount ./source
root@littleblackbox:~/Centos5# mount -o loop CentOS-5.3-i386-bin-2of6.iso ./source
root@littleblackbox:~/Centos5# cp -R ./source/* ./destination
root@littleblackbox:~/Centos5# umount ./source
root@littleblackbox:~/Centos5# mount -o loop CentOS-5.3-i386-bin-3of6.iso ./source
root@littleblackbox:~/Centos5# cp -R ./source/* ./destination
root@littleblackbox:~/Centos5# umount ./source
root@littleblackbox:~/Centos5# mount -o loop CentOS-5.3-i386-bin-3of6.iso ./source
root@littleblackbox:~/Centos5# cp -R ./source/* ./destination
root@littleblackbox:~/Centos5# umount ./source
root@littleblackbox:~/Centos5# mount -o loop CentOS-5.3-i386-bin-4of6.iso ./source
root@littleblackbox:~/Centos5# cp -R ./source/* ./destination
root@littleblackbox:~/Centos5# umount ./source
root@littleblackbox:~/Centos5# mount -o loop CentOS-5.3-i386-bin-5of6.iso ./source
root@littleblackbox:~/Centos5# cp -R ./source/* ./destination
root@littleblackbox:~/Centos5# umount ./source
root@littleblackbox:~/Centos5# mount -o loop CentOS-5.3-i386-bin-6of6.iso ./source
root@littleblackbox:~/Centos5# cp -R ./source/* ./destination
root@littleblackbox:~/Centos5# umount ./source

What we’ve done now, is created a directory called “destination” and copied every CD to that directory, overlapping them. What this does is it puts all the CentOS install packages into one directory and adds the necessary additional files to the root of the directory where the installer can find them. Now that we’ve done this, we can move the ISO files to the FTP server’s ISO directory and the “destination” files to the centos5 directory. I also moved the md5sum.txt and renamed it to CentOS5-i386-MD5SUM.txt so that way I know that the md5sum.txt is related to those ISO images.

root@littleblackbox:~/Centos5# mv *.iso /home/ftp/dist/iso
root@littleblackbox:~/Centos5# mv md5sum.txt /home/ftp/dist/iso
root@littleblackbox:~/Centos5# mv /home/ftp/dist/iso/md5sum.txt /home/ftp/dist/iso/CentOS-5.3-i386-MD5.txt
root@littleblackbox:~/Centos5# mv destination/* /home/ftp/dist/installer/centos5/
root@littleblackbox:~/Centos5# cd /home/ftp
root@littleblackbox:/home/ftp# chgrp -R nogroup *

The last step is key.  This makes sure that all the files in /home/ftp have the same group as the FTP user that VSFTPd runs with. Ok, so that’s the hard part. Now we have our installation files in place, our ISOs are in place (in case we need them again) and we’re ready to get those bootdisk images. Let’s take a look and see what we’re up against:

Every distribution has a directory of boot disks that they make available in case you’re doing an installation on a machine that doesn’t support CD booting.  All they do is start the system up with enough resources to start the machine and get it to the point where it can run the installation off of a CD.  Most installations also provide a network booting image that we can place in our TFTP server to netboot the entire installation.

Thankfully, Centos5 has that available.  There is a directory called “images” and within that there is a directory called “pxeboot”.  cd into the directory and let’s take a look.

root@littleblackbox:/home/ftp# cd dist/installer/centos5/images/pxeboot
root@littleblackbox:/home/ftp/dist/installer/centos5/images/pxeboot# ls
initrd.img  README  TRANS.TBL  vmlinuz
root@littleblackbox:/home/ftp/dist/installer/centos5/images/pxeboot#

Of course, it helps to read the README file.  This may contain important information on what we need to get this image to work properly.

root@littleblackbox:/home/ftp/dist/installer/centos5/images/pxeboot# cat README
The files in this directory are useful for booting a machine via PXE.

The following files are available:
vmlinuz - the kernel used for the installer
initrd.img - an initrd with support for all install methods and
 drivers supported for installation of CentOS

It doesn’t get any simpler than that.  The “vmlinuz” file is the kernel and “initrd.img” is the initial ramdisk for the install kernel.  Pretty simple.  The README did not make any mention of any boot options or parameters so for now we’ll just keep these two files in mind.  Other distributions may require some additional options be passed to the installer.

Copy the initrd.img and vmlinuz files to “/tftpboot/images” and we’ll cd into that directory for a little bit more work. Remember when I told you about keeping your “/tftpboot” directory clean?  Well, we’re vising that once again.  (Getting tired of it yet?) The name “vmlinuz” and “initrd.img” may make sense for one version of Linux to install, however those are very common names.  Let’s say you get  a copy of CentOS4 and you want to do network boot/install on that too?  There’s a pretty darn good chance that CentOS4 uses the same filenames! Since the initrd.img and vmlinuz are compiled for each other, you can’t go about using CentOS5′s initrd on CentOS4′s vmlinuz, they just won’t work.

So let’s start off by renaming the two files to something more descriptive.

root@littleblackbox:/tftpboot/images# mv vmlinuz vmlinuz-Centos5-netboot
root@littleblackbox:/tftpboot/images# mv initrd.img initrd-Centos5-netboot

Now that we have new names for the files, it’s time for the section that I’m sure you’ve been dying to read.

Configuring boot menus using the menu.c32 from the UBCD

And to much fanfare, I’d expect.   So, let’s review again:

1. We’ve set up tftpd-hpa on our Ubuntu server.
2. We’ve configured it to stay running in memory and given it a location and files to serve.
3. We’ve configured pxelinux so that the client can find all the files necessary to boot the menu system.
4. We’ve configured the menu system with a test image to distribute and,
5. We’ve successfully TFTPbooted pxelinux, the menu system and the memtest image and know it all works.
6. We’ve got our installation media in place on the FTP server with the proper file structure
7. We’ve got our boot images in place in “/tftpboot/images” and given them descriptive filenames

Now we need to build a menu to select a menu and start the installer.  This is almost the last step, I promise.  Remember the main.mnu file from earlier? (Look down, I saved you the scrolling. )

MENU INCLUDE /menus/defaults.cfg
LABEL memtest
 MENU LABEL Memtest86 V3.3
 KERNEL /images/memtest

Well here is where we’re going to go over the options and add another image. Firstly, we are going to review what we have here:

• MENU INCLUDE /menus/defaults.cfg – This line should appear first at the top of every menu file. This tells the menu.c32 how to render your menu (colors, etc)
• LABEL memtest – This tells the menu system that we are creating a new entry definition and that it’s name is “memtest”.  All label declarations must be unique.
• MENU LABEL Memtest86 V3.3 – This tells the menu system that the menu should display “Memtest86 V3.3″ in it’s text as the selectable item
• KERNEL /images/memtest – This tells the menu system that if this menu item is selected to boot the “/images/memtest” image and execute it.

At this point, we could go ahead and declare a new entry definition and copy and paste however this will cause the machine to fail once the image is selected.  Remember, the image we want to make available is comprised of the kernel (vmlinuz) and the initial ramdisk (initrd.img).  The menu system will take an additional parameter called APPEND with additional options that are needed to get the kernel to work like installer parameters and initrd statements.

NOTE: Does this look familiar to you?  If you are thinking that it looks similar to the LILO boot menu then you are absoloutely correct.  There are some differences but mostly the same configuration for LILO can be used here.

All we need to do is to add APPEND to the menu for our new item and we can save it and test.  Add the following text into your main.mnu and let’s test it out

label Centos5
 menu label Install Centos 5
 kernel /images/vmlinuz-Centos5-netboot
 append initrd=/images/initrd-Centos5-netboot

That’s all there is to it.  We have our label, our menu label, our kernel statement and our append statement with the initrd in there. Try booting your test PC now.

If you select the “Install CentOS 5″ option and after a few moments of watching text scroll around, you see the following screen, then congratulations! You have finished making your Ubuntu server network boot a Linux installer.

Go ahead and navigate the menus and when you come to the menu asking for FTP credentials, put the following information in:

When you hit OK to this screen, the installer will be attempting to fetch the information from the FTP server. Remember, until now we have been in the Preboot Execution Environment and are running in the initrd that was loaded when we selected to install CentOS5.  We have not even attempted FTP connectivity at this point.  A few nailbiting secconds later, and you should see this screen:

Go ahead and finish the installation if you’d like, or turn off the testing machine.

You’re all done.  I do hope that you enjoyed this HOWTO.  If you have any comments or suggestions, please leave them in the comments section of this article.  If you experienced any issues, please keep reading.

Troubleshooting

So you got through the HOWTO but something didn’t go quite right, Hopefully we can get you running again.

My onboard NIC  won’t boot. My computer shows TFTP followed by a bunch of periods and eventually says “TFTP OPEN TIMEOUT” .

If you look at the top of the screen, I’m guessing you’ll see something that says “INTEL LANDesk (R) Service Agent, version 0.99b”.  If so, you will have to use a different NIC.  There was a firmware bug in .99B that resulted in a lot of PXEboot clients not being able to properly connect to a TFTP server.  Unfortunately the only fix was to update the NIC’s firmware which is a dicey thing to do anyways, especially with an onboard NIC.  I would recommend just going out and getting a different card.

When booting my CentOS image, it says “KERNEL PANIC: No Init Found”

This means that the booted kernel vmlinuz-Centos5-netboot couldn’t find the initrd to go with it.  I would start by looking at your menu file (main.mnu) and see if the APPEND initrd=/images/initrd-Centos5-netboot image name is specified correctly.  Try your boot again after editing the file and you should be good to go.

My PXE client says “File Not Found”

Check “/etc/default/tftpd-hpa” and make sure that the path specified on the OPTIONS line is pointed to “/tftpboot” and make sure that the directory has the pxelinux.0 file in it.

My PXE client pulls an IP address but times out when trying to download pxelinux.0.

This means that either the wrong address was specified on the next-server line or that the TFTP server is not responding.  Check it by performing this command: /etc/init.d/tftpd-hpa restart and verify it’s running with ps auwxf | grep tftpd

My menu for CentOS 5 shows “CentOS5″ instead of “Install CentOS 5″.

Check your menu file and make sure that you have a MENU ITEM specified for this image. If no MENU ITEM is present, the menu system will fall back on to the name assigned on the LABEL line instead.

How can I tell if my NIC will network boot?

Without sticking it in to a machine and finding out if it works, there’s no guarantee that the NIC you have will boot.  There are clues that may help you though.  Look at the card and see if there is a chip on there that has the word “ATMEL” on it.  If there’s no ATMEL chip, but there’s a large socket where a chip should go, then unfortunately that card will not network boot.   If you plug it in to your computer doesn’t show any text or banner about UNDI, PXE or Etherboot, then you also may be out of luck.  If you have an onboard NIC, take a look in your BIOS and see if there is an option to enable network booting and try again.

Will this PXE booting work over USB?  What about Wireless?

• USB – Unfortunately there is not a PXE boot installation available for USB devices.  They get initialized by the OS far after the PXE hooks in to execute
• Wireless – The same applies for USB, except if you are doing an installation to  a WIRED machine and you use a wireless bridge, you might be able to.  The wireless bridge is transparent to the network and PXE so it should function as if you were directly connected to a switch.

Tips and Tricks

Ok, so you got the basics down, let’s examine some of the more advanced aspects of the menu system.

Menu timeout to load a default image – Good for the memtest image.  Add “timeout 30” and “default memtest” to the main.mnu.  This will tell the menu system  to boot the memtest image if no key is pressed in 30 seconds.

Add a sub-menu – Want to add a submenu to the menu system?  This one’s easy.  Create a new LABEL in your main.mnu and add the following

LABEL submenu1
 MENU LABEL Sub Menu 1
 KERNEL menu.c32
 APPEND /menus/submenu1.mnu

Change the LABEL, MENU LABEL to reflect the new entry and change the APPEND line to point to your new submenu.  Copy your main.mnu to your submenu1.mnu file.  Edit it and add the necessary entries to that file.  If you want to have a “Go Back…” option, make your first entry’s APPEND line load “/menus/main.mnu”

Change your menu’s  title.

One thing overlooked here was that my defaults.cfg was already edited for my server.  If you copied the one from the UBCD directly, then yours still will say “Ultimate Boot CD” at the top which is kind of funny because the machine you’re installing might not even have a CDROM to boot from.  Edit the defaults.cfg in the “/tftpboot/menus” directory and change the MENU TITLE directive to whatever you want.  Remember that you can not exceed 76 columns (80 columns – 4 for the borders) otherwise your menu may not display properly.

Afterword

If you would like more information on how to customize your boot menu, check out http://syslinux.zytor.com/wiki/index.php/Comboot/menu.c32 They go through the entire exhaustive option set with code examples and explanations of each option.  I have only posted information here that I have used and know works.

I have enjoyed writing this HOWTO and hope that someone out there finds it useful.  If you would like to make any comments about this HOWTO or want to share your netboot experience, please by all means leave me a comment.

Thank you for reading, Happy netbooting!

FIRESTORM_v1