How to Burn Your Own ESX Server 3i USB Key
Introduction
This document provides step by step instructions for placing the ESX Server 3i version 3.5 Beta disk image on a USB key. Before you begin, download the ESX Server 3i disk image and ensure that it is available on your system. The following USB keys have been tested and are recommended for use: KINGSTON 1GB USB 2.0 DATATRAVELER II KINGSTON 2GB USB 2.0 DATATRAVELER II IMATION USB 1GB POCKET FLASH DRIVE IMATION USB 2GB POCKET FLASH DRIVE VERBATIM USB 2 2GB FLASH DRIVE SANDISK 1GB ULTRA II SD PLUS USB SANDISK 2GB CRUZER FREEDOM USB FD If the above USB keys are not available, use a 1GB or 2GB USB key that is USB 2.0 certified (labeled with HI-SPEED CERTITIFIED USB logo). You will use an imaging utility and a verification utility to burn your own ESX Server 3i USB key. The imaging utility is called ‘dd’. The verification utility is called ‘md5sum’. The disk image will be published along with a md5sum checksum number computed during build time. This number needs to be compared against the downloaded disk image to ensure the download was successful and then compared against the USB key to ensure the file was properly imaged on the USB key. Instructions are provided for Linux and Windows environments. The dd and md5sum utilities are included in most Linux distributions. For Windows the utilities must be downloaded (links are provided in the instructions). Windows users are encouraged to review the Linux instructions also for an overview of the process.
Instructions for imaging the USB key using Linux Instructions for imaging the USB key using Windows
Instructions for imaging the USB key using Linux
The imaging process for Linux is generally the same regardless of the Linux distribution or type (Desktop, Server, Service Console from the traditional, CD-ROM based ESX Server). However there can be some minor differences. The instructions provided in this section have been verified with ESX Server 3.5, Red Hat Linux, Gentoo, and Ubuntu. All operations must be run while logged in as a user with root privileges. The first step is to ensure that the USB key is detected by the system and assigned a device name. Next, identify which disk device name is assigned to the USB key. One way to do this is to view the list of disk devices before and after plugging in the USB key. Run the “fdisk –l” command to view the list of disk devices.
The following is a list of devices in an example Linux system before plugging in a USB key: RootUser-lx1 linux # fdisk -l Disk /dev/hda: 163.9 GB, 163928604672 bytes 255 heads, 63 sectors/track, 19929 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot /dev/hda1 * /dev/hda2 /dev/hda3 Start 1 37 787 End 36 786 19929 Blocks 289138+ 6024375 153766147+ Id 83 82 83 System Linux Linux swap Linux
Disk /dev/hdb: 80.0 GB, 80000000000 bytes 255 heads, 63 sectors/track, 9726 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot /dev/hdb1 Start 1 End 9726 Blocks 78124063+ Id 83 System Linux
The following is a list of devices in an example Linux system after a new USB key is plugged in: RootUser-lx1 linux # fdisk -l Disk /dev/hda: 163.9 GB, 163928604672 bytes 255 heads, 63 sectors/track, 19929 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot /dev/hda1 * /dev/hda2 /dev/hda3 Start 1 37 787 End 36 786 19929 Blocks 289138+ 6024375 153766147+ Id 83 82 83 System Linux Linux swap Linux
Disk /dev/hdb: 80.0 GB, 80000000000 bytes 255 heads, 63 sectors/track, 9726 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot /dev/hdb1 Start 1 End 9726 Blocks 78124063+ Id 83 System Linux
Disk /dev/sdb: 1043 MB, 1043333120 bytes 64 heads, 32 sectors/track, 995 cylinders Units = cylinders of 2048 * 512 = 1048576 bytes Device Boot Start End Blocks Id /dev/sdb1 * 1 995 1018863+ 6 Partition 1 has different physical/logical endings: phys=(993, 63, 32) logical=(994, 63, 31) System FAT16
Note that there is one additional disk device, /dev/sdb. Also note the size of the disk, 1043 MB, which indicates that the USB key is a 1GB USB key. New USB keys typically have a single partition, formatted with FAT16. The USB device name is in the form /dev/sdX, where X is a letter starting with a. In Linux, USB disks are treated like SCSI devices. If the Linux system has local SCSI disks, they will be assigned /dev/sda, /dev/sdb, etc., and the USB disk will be assigned the next available device name. In some cases (especially when you have plugged in and unplugged many USB disks), the operating system may skip a letter as it has in the case above. Partitions are listed as /dev/sdbXY, where X is the device letter and Y is the partition number. For reference, IDE disk devices in Linux show up as /dev/hdX (and partitions as /dev/hdXY). In the case above, there are two IDE drives in the system, no SCSI disks, and one USB disk.
In some Linux distributions (for example, in Ubuntu), USB keys are automatically mounted. In order to image the USB key, the key must be in the unmounted state. Verify the state by using the mount command: RootUser-lx1 linux # mount /dev/hda3 on / type ext3 (rw,noatime) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec) udev on /dev type tmpfs (rw,nosuid) devpts on /dev/pts type devpts (rw,nosuid,noexec) /dev/hdb1 on /home type ext3 (rw,noatime) none on /dev/shm type tmpfs (rw) usbfs on /proc/bus/usb type usbfs (rw,noexec,nosuid,devmode=0664,devgid=85) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) nfsd on /proc/fs/nfs type nfsd (rw) /dev/hdc on /mnt/cdrom type iso9660 (ro) Note that in this case /dev/sdb is not listed, indicating that the USB key is not mounted. The following is an example of output from the mount command for a mounted USB key: RootUser-lx1 linux # mount /dev/hda3 on / type ext3 (rw,noatime) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec) udev on /dev type tmpfs (rw,nosuid) devpts on /dev/pts type devpts (rw,nosuid,noexec) /dev/hdb1 on /home type ext3 (rw,noatime) none on /dev/shm type tmpfs (rw) usbfs on /proc/bus/usb type usbfs (rw,noexec,nosuid,devmode=0664,devgid=85) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) nfsd on /proc/fs/nfs type nfsd (rw) /dev/hdc on /mnt/cdrom type iso9660 (ro) /dev/sdb1 on /mnt/usb type vfat (rw) Note that the USB key partition 1 is listed as /dev/sdb1. The mount point (in the above case /mnt/usb) will vary depending on the Linux distribution used. If the USB key is mounted, use the following command to unmount the USB key: RootUser-lx1 linux # umount /dev/sdb1 Now you are ready to image the USB key. Use the dd command in following format: dd if=VMware-VMvisor-big-e.x.p-XXXXX.i386.dd of=/dev/sdb bs=500MB In the command above, ”if” stands for “In File,” ”of” stands for “Out File,” and ”bs” stands for “Block Size.” Note that “of” must be set to the device name, not to the partition name (/dev/sdb, not /dev/sdb1). The block size parameter is important to speed up the imaging process. Omitting may cause the imaging to take longer. On USB 2.0 controllers, this process typically takes under 5 minutes. On USB 1.1, it typically takes 30 minutes. To verify the image was burned correctly, you need to use the “md5sum” command which generates a checksum. You need to run the command on the image file and then again against the USB key to verify the checksum is the same as it provided on the download page. Before you verify the image burned correctly, retrieve the size of the image file. For example:
RootUser-lx1 linux # ls -l VMware-VMvisor-big-e.x.p-XXXXX.i386.dd -rw-r--r-- 1 qmaild qmail 734003200 2007-08-01 07:51 VMwareVMvisor-big-e.x.p-XXXXX.i386.dd The size in the above case is 734003200. Then, use the md5sum command as follows to retrieve the checksum of the image file: RootUser-lx1 linux # md5sum VMware-VMvisor-big-e.x.p-XXXXX.i386.dd 5b9abec3fee00ced402c1ab995d231d7 VMware-VMvisor-big-e.x.pXXXXX.i386.dd Compare the above checksum to the checksum number provided on the download page. If it matches then compare this number to the output of md5sum command ran against the USB key: RootUser-lx1 linux # dd if=/dev/sdb bs=734003200 count=1 2> /dev/null | md5sum 5b9abec3fee00ced402c1ab995d231d7 Note that the large hexdecimal checksum number is the same for both the original image file and the final. Please note that this is an example only. The actual checksum will differ for the image file you will download. The USB key has been successfully imaged once you have verified that the md5sum checksums match. If the checksum numbers do not match, try the process again. If it fails again, select a different USB key.
Instructions for imaging the USB key using Windows
You will need the Windows utilities dd.exe and md5sum.exe. Download dd.exe version 0.5 from http://www.chrysocome.net/downloads/dd-0.5.zip. Download md5sum.exe from http://etree.org/cgi-bin/counter.cgi/software/md5sum.exe. All operations need to be run while logged in as a user with administrator privileges. The dd.exe utility has a --list parameter that will list all the disk devices in the system (similar to fdisk –l in Linux). Run the dd --list command before plugging in the USB key and again after. It will list the CD-ROM first, then the hard disk(s) and finally the USB key(s). The following is example output without a USB key plugged in: C:\temp\dd-0.5>dd.exe --list rawwrite dd for windows version 0.5. Written by John Newbigin This program is covered by the GPL. See copying.txt for details Win32 Available Volume Information \\.\Volume{cbd444ba-15d8-11da-b5b0-806d6172696f}\ link to \\?\Device\HarddiskVolume1 fixed media Mounted on \\.\c: \\.\Volume{585e0b42-151f-11dc-9425-000c29849dae}\ link to \\?\Device\HarddiskVolume2 fixed media Mounted on \\.\f: \\.\Volume{9669c8d9-6eac-11d8-a07f-806d6172696f}\
link to \\?\Device\CdRom0 CD-ROM Mounted on \\.\d: \\.\Volume{7192253e-3b5e-11da-93fb-806d6172696f}\ link to \\?\Device\CdRom1 CD-ROM Mounted on \\.\e: \\.\Volume{9669c8d8-6eac-11d8-a07f-806d6172696f}\ link to \\?\Device\Floppy0 removeable media Mounted on \\.\a: NT Block Device Objects \\?\Device\CdRom0 size is 2147483647 bytes \\?\Device\CdRom1 size is 679575552 bytes \\?\Device\Floppy0 \\?\Device\Harddisk0\Partition0 link to \\?\Device\Harddisk0\DR0 Fixed hard disk media. Block size = 512 size is 10485760000 bytes \\?\Device\Harddisk0\Partition1 link to \\?\Device\HarddiskVolume1 \\?\Device\Harddisk1\Partition0 link to \\?\Device\Harddisk1\DR1 Fixed hard disk media. Block size = 512 size is 4294967296 bytes \\?\Device\Harddisk1\Partition1 link to \\?\Device\HarddiskVolume2 Virtual input devices /dev/zero (null data) /dev/random (pseudo-random data) (standard input) Virtual output devices (standard output) The following is example output with a USB key that is plugged in: C:\temp\dd-0.5>dd --list rawwrite dd for windows version 0.5. Written by John Newbigin This program is covered by the GPL. See copying.txt for details Win32 Available Volume Information \\.\Volume{578d8902-9694-11db-976b-806d6172696f}\ link to \\?\Device\HarddiskVolume1 fixed media Mounted on \\.\c: \\.\Volume{578d8903-9694-11db-976b-806d6172696f}\ link to \\?\Device\CdRom0 CD-ROM Mounted on \\.\d: \\.\Volume{8afb631d-361d-11dc-97bb-001641ab1208}\
link to \\?\Device\Harddisk1\DP(1)0-0+4 removeable media Mounted on \\.\e:
NT Block Device Objects \\?\Device\CdRom0 Removable media other than floppy. Block size = 2048 size is 512342016 bytes \\?\Device\Harddisk0\Partition0 link to \\?\Device\Harddisk0\DR0 Fixed hard disk media. Block size = 512 size is 100030242816 bytes \\?\Device\Harddisk0\Partition1 link to \\?\Device\HarddiskVolume1 \\?\Device\Harddisk0\Partition2 link to \\?\Device\HarddiskVolume2 Fixed hard disk media. Block size = 512 size is 4807434240 bytes \\?\Device\Harddisk1\Partition0 link to \\?\Device\Harddisk1\DR3 Removable media other than floppy. Block size = 512 size is 1039663104 bytes \\?\Device\Harddisk1\Partition1 link to \\?\Device\Harddisk1\DP(1)0-0+4 Removable media other than floppy. Block size = 512 size is 33554432 bytes Virtual input devices /dev/zero (null data) /dev/random (pseudo-random data) (standard input) Virtual output devices (standard output) C:\temp\dd-0.5> Note that there is one additional disk device, Harddisk1. Also note that it lists Partition0 and Partition1. Partition0 represents the device itself, similar to Linux /dev/sdX. Partition1 represents the partition that Windows mounts similar to Linux /dev/sdXY. Always address the whole device by using Partition0. To image the USB key use the following command: C:\temp\dd-0.5>dd if=VMware-VMvisor-big-e.x.p-XXXXX.i386.dd of=\\?\Device\Harddisk1\Partition0 bs=1M --size --progress To verify the image was burned correctly, you need to use the “md5sum” command which generates a checksum. You need to run the command on the image file and then again against the USB key data and verify the checksum is the same as it provided on the download page. Use the dd command again, but this time read the data from the key and place the contents in a temporary file. For example: dd if=\\?\Device\Harddisk1\Partition0 of=temp.dd bs=1M count=700 – progress
In the above example, the count=700 indicates the number of 1MB blocks to read. This is important because the image file in this example was 700MB in size. If we were to omit the count=700, the full 1GB USB key would be read back, and the original image file would not match the temporary image file. Now run md5sum to compute the checksum of the original image file and the temporary file: C:\temp\dd-0.5>md5sum VMware-VMvisor-big-e.x.p-XXXXX.i386.dd 5b9abec3fee00ced402c1ab995d231d7 *VMware-VMvisor-big-e.x.pXXXXX.i386.dd Compare the above checksum to the checksum number provided on the download page. If it matches then compare this number to the output of md5sum command ran against the USB key temporary file: C:\temp\dd-0.5>md5sum temp.dd 5b9abec3fee00ced402c1ab995d231d7
*temp.dd
Note that the large hexdecimal checksum number is the same for both the original image file and the final. Please note that this is an example only. The actual checksum will differ for the image file you download. The USB key has been successfully imaged once you have verified that the md5sum checksums match. If the checksum numbers do not match, try the process again. If it fails again, select a different USB key.