Installing Linux From A USB Flash Drive

Installing Red Hat Linux from a USB
flashdrive
Dave Heller
IBM Linux Technology Center
Dave Pierson
IBM Network Transformation Center
Table of Contents
1.0 INTRODUCTION ....................................................................................................................................................1

1.1 Benefits of USB flashdrive .............................................................................................................................1
1.2 Warnings ........................................................................................................................................................2
1.3 Requirements..................................................................................................................................................2
2.0 PERFORMING THE OPERATIONS IN LINUX .............................................................................................................4
2.1 Upgrading your SYSLINUX package .............................................................................................................4
2.2 Mounting and unmounting your USB flashdrive............................................................................................4
2.3 Backing up your USB flashdrive ....................................................................................................................5
2.4 Using your flashdrive’s existing partitioning and formatting ........................................................................5
2.5 Installing generic boot code to the MBR........................................................................................................6
2.6 Setting the partition boot flag.........................................................................................................................7
2.7 Installing the SYSLINUX bootloader .............................................................................................................7
2.8 Copying the Red Hat installation media ........................................................................................................8
2.9 Creating the SYSLINUX menu file .................................................................................................................9
2.10 Using Red Hat Kickstart ............................................................................................................................11
3.0 PERFORMING THE OPERATIONS IN MS WINDOWS ..............................................................................................12
3.1 Backing up your USB flashdrive ..................................................................................................................12
3.2 Installing the SYSLINUX bootloader ...........................................................................................................14
3.3 Completing the installation ..........................................................................................................................14
4.0 TEST AND DEPLOYMENT ....................................................................................................................................15
4.1 Configuring your server BIOS to boot from USB ........................................................................................15
4.2 Installing Linux ............................................................................................................................................17
4.3 Known issues................................................................................................................................................19
APPENDIX A – SAMPLE CONFIGURATION FILES........................................................................................................21
APPENDIX B – ADVANCED TOPICS ...........................................................................................................................24
B.1 Repartitioning in Linux................................................................................................................................24
B.2 Reformatting in Linux ..................................................................................................................................27
B.3 Repartitioning in Windows ..........................................................................................................................29
B.4 Reformatting in Windows ............................................................................................................................30
B.5 Device transfer speeds.................................................................................................................................31
REFERENCES ............................................................................................................................................................32
1.0 Introduction
This document describes a technique for installing Red Hat® Linux from a portable USB
flashdrive. This is essentially a “how-to” document that expects that the reader is
familiar with Red Hat kickstart and Linux installation in general, as well as the operation
of the SYSLINUX bootloader. For more information on these topics see the References
section at the end of this document.
1.1 Benefits of USB flashdrive
Installing Linux from a USB flashdrive is really not much different than installing from CD
or DVD-ROM media. The flashdrive has the distinct advantage of being a writeable
device, making it much more flexible than CD-ROM. You can easily create custom boot
media, using Red Hat kickstart and SYSLINUX menus, without having to create a new
El Torito bootable ISO image or burn physical media. And making modifications on-the-
fly is not a problem.
You can set up multiple installation tasks on a single flashdrive, limited only by your
device’s space. A 4GB flashdrive is enough to hold a single set of RHEL installation
media; an 8 GB drive should be enough space for two.
As for speed, installing from USB flashdrive is roughly equivalent to installing from a fast
DVD-ROM reader. A 16x DVD-ROM has a transfer speed of about 21 MB/s. USB
flashdrives run from about 10 MB/s on the low end to about 30 MB/s for newer “high
speed” devices (see Appendix B for examples). Be sure to compare device speeds
when shopping for a flashdrive.
Installing from flashdrive is similar to installing from CD-ROM in that it is not well suited
for mass deployment. For large-scale deployments, consider the use of PXE boot.
The USB flashdrive is in many ways ideal for field support. It is portable, fast, easy to
modify and can perform a wide variety of pre-execution tasks—including firmware
deployment, diagnostics, backup and recovery—in addition to OS installation.
Finally, some of the techniques described here cover the operation of the SYSLINUX
bootloader and its menu system. These are good techniques to learn, as SYSLINUX
also supports boot via CD-ROM (ISOLINUX) and network-based PXE boot
(PXELINUX). With a few exceptions, the SYSLINUX bootloaders work the same way
across all the media types. So, learning to work with SYSLINUX will help you build
custom boot media, regardless of which media type is best suited for the task.
© 2007 IBM, Version 2.0, Nov 26, 2007 http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/Web/Techdocs Page 1
This guide is intended as a personal productivity tool. It is not intended to be comprehensive and is provided for guidance only, on
an ‘as is’ basis, without warranty of any kind. Please be aware that its contents have not been certified by IBM.
1.2 Warnings
WARNING: Some of the procedures described here which modify the flashdrive’s
partitioning or formatting may destroy existing data on the drive. Make sure you save
any important files or backup the entire device as described below.
WARNING: In Linux, a USB flashdrive is “enumerated” just like a HDD, typically with a
designation like /dev/sdb, /dev/sdc, etc. Make sure you properly identify which disk is
your USB flashdrive! In most cases you will be performing these operations as root and
it is very easy to overwrite the contents of a HDD by writing directly to the device file.
To help identify the device assignment, tail the /var/log/messages file when inserting the
flashdrive:
[root@ss1 ~]# tail –f /var/log/messages

Nov 5 13:36:39 ss1 kernel: usb 1-4: new high speed USB device using address 26
Nov 5 13:36:39 ss1 kernel: scsi27 : SCSI emulation for USB Mass Storage devices
Nov 5 13:36:39 ss1 kernel: Vendor: Model: Patriot Memory Rev: PMAP
Nov 5 13:36:40 ss1 kernel: Type: Direct-Access ANSI SCSI revision: 02
Nov 5 13:36:43 ss1 kernel: SCSI device sdc: 16121856 512-byte hdwr sectors (8254 MB)
Nov 5 13:36:43 ss1 kernel: sdc: Write Protect is off
Nov 5 13:36:43 ss1 kernel: sdc: Mode Sense: 23 00 00 00
Nov 5 13:36:43 ss1 kernel: sdc: assuming drive cache: write through
Nov 5 13:36:43 ss1 kernel: sdc: sdc1
Nov 5 13:36:43 ss1 kernel: Attached scsi removable disk sdc at scsi27, channel 0, id
0, lun 0
Nov 5 13:36:43 ss1 kernel: USB Mass Storage device found at 26
Nov 5 13:36:43 ss1 scsi.agent[29350]: disk at
/devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4:1.0/host27/target27:0:0/27:0:0:0
Nov 5 13:36:43 ss1 fstab-sync[13220]: added mount point /media/usbdisk for /dev/sdc1
This sample output was generated on a system that already had two HDDs installed, so
the USB flashdrive is enumerated as /dev/sdc. But this will vary from system to system
so BE CAREFUL.
WARNING: Make sure the filesystem is unmounted and all data has been written to
flashdrive before removing the device from the USB port. Due to Linux disk caching
and “lazy writes”, some commands will appear to complete before the write operations
are truly done. Removing the device in mid-write can corrupt the contents of the
flashdrive or, in some circumstances, even crash your system! Check your flashdrive’s
access LED before removing it. If in doubt, issue a Linux sync command before
removing the stick.
1.3 Requirements
You will need the following:
1. A 4GB or greater capacity USB flashdrive.

2. Full set of Red Hat Linux installation media in either CD-ROM or DVD-ROM ISO
image format.
3. The latest SYSLINUX bootloader package from H. Peter Anvin.
(www.syslinux.org).
4. Windows® only: Microsoft® Virtual CD Control Panel, WinImage v8.0 or
comparable utility (for extracting files from a CD-ROM ISO image)
2.0 Performing the operations in Linux
This section explains how to prepare the USB flashdrive in Linux. It is also possible to
perform the operations in MS Windows and those procedures are described below.
However, Linux provides a rich set of native tools that allow you to perform all the
necessary operations with any additional software, and the tools provide a good deal of
visibility. In Windows, you will need a separate utility program to perform some of the
operations and visibility is somewhat limited.
2.1 Upgrading your SYSLINUX package
SYSLINUX is bundled with most popular Linux distributions, but it is recommended to

update to the latest version. RPM packages are available from a number of sources
including: http://rpmfind.net. Select the correct package for your Linux distribution
(“i386” => 32-bit; “x86_64” => 64-bit). To install:
rpm –ihv syslinux-3.52-1.el4.rf.x86_64.rpm
To upgrade from a previous version:
rpm –Uhv syslinux-3.52-1.el4.rf.x86_64.rpm
Note: Starting with v.3.52, SYSLINUX has a dependency on “perl-Crypt-PasswdMD5”

so you may need to install that package first.
2.2 Mounting and unmounting your USB flashdrive
For the first few operations below, your USB flashdrive’s filesystem should be in an
unmounted state. However, Linux hotplug may automatically mount your filesystem as
soon as the device is inserted. If this happens you should see a message in the
/var/log/messages file (as shown above).
If in doubt, check using the mount command:
[root@ss1 ~]# mount

/dev/sdc1 on /media/usbdisk type vfat \
(rw,nosuid,nodev,sync,noatime,fscontext=system_u:object_r:removable_t)
To unmount:
umount /media/usbdisk
To mount manually:
mount /dev/sdc1 /media/usbdisk
2.3 Backing up your USB flashdrive
Before beginning you may want to backup your USB flashdrive. The following
command will save the full contents to a HDD image file:
dd if=/dev/sdc of=my_flashdrive_backup.img
Since the resulting file will be as large as full capacity of your flashdrive, you may want
to compress the image. This will reduce the file size considerably, especially if there is
unused space:
dd if=/dev/sdc | gzip -c > my_flashdrive_backup.img.gz
Note the use of “sdc” here, NOT “sdc1”. “sdc” refers to the entire device whereas
“sdc1” refers to the first partition. If you use “sdc1” your backup will not contain the
Master Boot Record (MBR) or first data track (“track 0”), making restore more difficult.
To restore:
dd if=my_flashdrive_backup.img of=/dev/sdc
Or, if compression was used:
gunzip -c my_flashdrive_backup.img.gz | dd of=/dev/sdc
Finally, to back up your flashdrive’s MBR only:
dd bs=512 count=1 if=/dev/sdc of=my_flashdrive_mbr.bin
To restore:
dd bs=512 count=1 if=my_flashdrive_mbr.bin of=/dev/sdc
Restoring the MBR will recover the original partition table should that ever become
necessary.
Note: Any change to the partition table accomplished by writing directly to the MBR
should be followed by command like hdparm -z or partprobe to force the system re-read
the partition table (the functional equivalent of removing and reinserting the device).
This should not be necessary when repartitioning with fdisk or sfdisk, as these re-read
the partition table automatically after making any changes.
2.4 Using your flashdrive’s existing partitioning and formatting
In most cases your flashdrive’s original partitioning and formatting will work fine, and all
you’ll need to do is follow the steps to make the device bootable. You can use either a
FAT16 or FAT32 filesystem, but with FAT16 you will hit a file size limitation at 2GB and
a volume size limitation at 4GB, so FAT32 is recommended (see Appendix B). In
general, the device must meet the following requirements:
1. The MBR must contain a valid partition table with at least one (and typically just
one) primary partition
2. The filesystem must be formatted FAT16 or FAT32
3. The “partition ID” must match with filesystem contained within the partition,
typically: “0x6” (FAT16), “0xe” (FAT16-LBA), “0xb” (FAT32) or “0xc” (FAT32-LBA)
To make the device bootable there are two additional conditions, which are commonly
NOT met with the as-shipped configuration:
1. The MBR must contain generic “boot code”

2. The first partition must be bootable (i.e. the “active” flag must be set)
We will review these requirements and make any necessary changes as we go.
Remember, you can always restore your flashdrive to its original state if you created a
backup as described above.
2.5 Installing generic boot code to the MBR
In most cases the factory formatting will NOT include generic boot code simply because
most flashdrives are not configured to be bootable as-shipped. You can try examining
the contents of the MBR with the Linux command:
hexdump -C /dev/sdc | more
You may be able to discern if boot code is present by looking for such telltale strings as
“Missing operating system”, “Operating system load error”, etc. However, the only to
way to be sure is to try booting from the flashdrive. If you install the SYSLINUX
bootloader as described below and your USB flashdrive still won’t boot, chances are the
MBR boot code is missing (or the partition active flag has not been set).
To install the SYSLINUX generic MBR boot code:
dd if=/usr/lib/syslinux/mbr.bin of=/dev/sdc
In general, any operation that writes to the MBR can potentially destroy existing data on
the drive, if it overwrites the partition table at the end of the MBR. However, since the
SYSLINUX bootcode file mbr.bin is only 440 bytes long (less than the full 512 bytes of
the MBR) the following procedure should NOT overwrite the partition table and is
generally safe. Still, having a backup is never a bad idea.
2.6 Setting the partition boot flag
To check if your partition boot flag is set “active”, run fdisk and print the partition table.
(Note: for brevity, some extraneous info is deleted from the fdisk output below. See
Appendix B for complete examples.):
Command (m for help): p
Disk /dev/sdc: 8254 MB, 8254390272 bytes

16 heads, 32 sectors/track, 31488 cylinders
Units = cylinders of 512 * 512 = 262144 bytes
Device Boot Start End Blocks Id System

/dev/sdc1 1 31488 8060912 c W95 FAT32 (LBA)
The “Boot” column is empty, indicating the boot flag is not set. Set it as follows, then
reprint the partition table:
Command (m for help): a

Partition number (1-4): 1
Command (m for help): p
Disk /dev/sdc: 8254 MB, 8254390272 bytes

16 heads, 32 sectors/track, 31488 cylinders
Units = cylinders of 512 * 512 = 262144 bytes
Device Boot Start End Blocks Id System

/dev/sdc1 * 1 31488 8060912 c W95 FAT32 (LBA)
Now, write the partition table (commit the changes) and exit:
Command (m for help): w

The partition table has been altered!
Calling ioctl() to re-read partition table.

Syncing disks.
2.7 Installing the SYSLINUX bootloader
This step will install the SYSLINUX boot code to the Partition Boot Record (PBR) and
will install the bootloader file ldlinux.sys to the root directory:
syslinux /dev/sdc1
Note the use of “sdc1” here, as we are performing these operations on the first partition.
If you use “sdc” by mistake you will overwrite your MBR!
Now, mount your partition:
mount /dev/sdc1 /media/usbdisk
and copy the menu.c32 file to the root directory. This is the SYSLINUX “com32” file that
supports the simple menu system:
cp -p /usr/lib/syslinux/menu.c32 /media/usbdisk/
Your flashdrive should now be bootable.
2.8 Copying the Red Hat installation media
Now you are ready to copy the installation media to the flashdrive. You can use either
the CD-ROM or DVD-ROM ISO images (remember: FAT32 is required for files > 2 GB).
Because you are creating a custom boot disk, you will need to extract the Anaconda
installer files vmlinuz and initrd.img from the installation media. These can be found in
the “/isolinux” directory on the DVD-ROM ISO, or on disc #1 of the CD-ROM ISO image
set.
The vmlinuz and initrd.img files can reside anywhere on the flashdrive as long as they
are properly referenced in the syslinux.cfg file. However, you may want to create a
standard directory structure to help organize the files. This will allow you to store the
files from multiple Linux versions without having to rename them. The files are relatively
small, and saving a copy will prevent you from having to extract the files again in the
future. For example:
[root@ss1 ~]# tree /media/usbdisk/li/

/media/usbdisk/li/
| |-- RHEL3.8
| `-- i386
| |-- initrd.img
| `-- vmlinuz
|-- RHEL4.4
| |-- i386
| | |-- initrd.img
| | `-- vmlinuz
| `-- x86_64
| |-- initrd.img
| |-- vmlinuz
`-- RHEL5.1
`-- x86_64
|-- initrd.img
`-- vmlinuz
Remember, your flashdrive will only have room for one or two sets of installation media
at a time, but if you keep a copy of the vmlinuz and initrd.img files you can easily switch
back and forth by just recopying the appropriate ISO images to the drive
Note: You MUST use the correct vmlinuz and initrd.img files for the Linux version you
wish to install. Files from a different “point release” (e.g. RHEL 4.3 vs. RHEL 4.4) and
technology (i386 vs. x86_64) will NOT work. The Anconda installer will boot but when it
goes to read the installation media from the ISO it will complain you have the wrong
version and abort.
Use the following commands to loopback-mount the ISO image and copy the necessary
files to the flashdrive. This example is for RHEL 4.4, i386 version:
mkdir loop
mount -o loop RHEL4-U4-i386-AS-disc1.iso loop
mkdir /media/usbdisk/li/RHEL4.4
mkdir /media/usbdisk/li/RHEL4.4/i386
cp -p loop/isolinux/vmlinuz /media/usbdisk/li/RHEL4.4/i386/
cp -p loop/isolinux/initrd.img /media/usbdisk/li/RHEL4.4/i386/
umount loop
This example is for RHEL 5.1, x86_64 version:
mount -o loop RHEL5.1-Server-x86_64-DVD.iso loop
mkdir /media/usbdisk/li/RHEL5.1
mkdir /media/usbdisk/li/RHEL5.1/x86_64
cp -p loop/isolinux/vmlinuz /media/usbdisk/li/RHEL5.1/x86_64/
cp -p loop/isolinux/initrd.img /media/usbdisk/li/RHEL5.1/x86_64/
umount loop
Now copy the complete set of CD-ROM ISO images to the flashdrive:
cp -p RHEL4-U4-i386-AS-disc*.iso /media/usbdisk/
and / or the DVD-ROM ISO:
cp -p RHEL5.1-Server-x86_64-DVD.iso /media/usbdisk/
Again, you can store multiple versions of the installation media on your flashdrive if you
have enough space.
HINT: If you make a backup of your flashdrive before copying the ISO images you can
create a “base image” containing only the SYSLINUX bootloader and the Anaconda
installer files. This will save you having to recreate the entire environment each time.
You can simply restore your snapshot, copy the ISO images and go.
2.9 Creating the SYSLINUX menu file
You can easily set up custom installation tasks using SYSLINUX menus. The file that
governs the operation of the boot menu is syslinux.cfg. For a full description of this file
refer to the SYSLINUX documentation at: http://syslinux.zytor.com/faq.php. A sample
file is provided in Appendix A.
Here are two sample stanzas from syslinux.cfg:
## -- Manual install of RHEL 5.1...

LABEL RHEL5.1
MENU LABEL RHEL AS 5.1 Manual Install
KERNEL li/RHEL5.1/x86_64/vmlinuz
APPEND linux load_ramdisk=1 initrd=li/RHEL5.1/x86_64/initrd.img
## -- Kickstart install of RHEL 5.1...

LABEL RHEL5.1_KS
MENU LABEL RHEL AS 5.1 Kickstart Install
APPEND linux load_ramdisk=1 initrd=li/RHEL5.1/x86_64/initrd.img \
method=hd:sdb1:/ ks=hd:sdb1:/ks.cfg
LABEL is the unique identifier for that stanza. MENU LABEL is the string that will
appear in the boot menu. KERNEL is the path to the Anaconda installer kernel file.
APPEND passes boot-time parameters to the kernel, including the path to initrd.img.
The parameters pertinent to USB flashdrive installation are “method=”, which specifies
the location of the installation media (ISO images) and “ks=”, which points to the
kickstart file. The syntax should be fairly self-explanatory.
Note the use of “sdb1” here rather than “sdc1”. This is because the system we are
INSTALLING TO has only one fixed HDD installed, whereas the system we built our
USB key on had two HDDs. This points out an important caveat: it may take a bit of
experimentation to determine how the USB flashdrive is enumerated on a given system.
And obviously, the system you used to build the flashdrive may have no bearing on the
system on which you intend to install Linux. If in doubt, run through a manual install first
to help identify your devices, then edit your syslinux.cfg if necessary.
To copy the completed file to the USB flashdrive:
cp -p syslinux.cfg /media/usbdisk/
Finally, note how flexible the SYSLINUX menu file is. You can set up multiple
installation tasks for different versions of Linux or for different variations of the install
method. The syslinux.cfg in Appendix A includes a stanza to boot Linux “rescue” mode,
for example, which is a VERY HANDY feature to have on a portable boot device.
2.10 Using Red Hat Kickstart
You can create an unattended installation task using Red Hat Kickstart. A kickstart file
is essentially a “response file” for the Anaconda installer; it contains all the data you
would normally enter during an interactive install. (For a full description of kickstart see:
http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Installation_Guide-en-
US/ch-kickstart2.html.) A sample file is provided in Appendix A.
Remember, because you have the ability to set up multiple installation tasks in
syslinux.cfg, you can create both manual and automated installation tasks against the
same set of media. So just because you have a kickstart file on the drive does not
mean you have to use it in every case.
cp -p ks.cfg /media/usbdisk/
At this point your root directory should look something like this: (Note this is an 8GB
flashdrive so it has room for both versions of RHEL):
ls -l /media/usbdisk/
total 5903312
-rwxr-xr-x 1 root root 3902 Nov 5 23:10 ks.cfg
-r-xr-xr-x 1 root root 10827 Nov 5 20:46 ldlinux.sys
drwxr-xr-x 4 root root 4096 Nov 5 20:48 li
-rwxr-xr-x 1 root root 36108 Sep 26 18:01 menu.c32
-rwxr-xr-x 1 root root 196493312 Aug 9 2006 RHEL4-U4-x86_64-AS-disc1.iso
-rwxr-xr-x 1 root root 3515662336 Oct 17 23:47 RHEL5.1-Server-x86_64-DVD.iso
-rwxr-xr-x 1 root root 2141 Nov 5 20:52 syslinux.cfg
Your flashdrive is now ready for deployment.
3.0 Performing the operations in MS Windows
It is possible to prepare your USB flashdrive in Windows, as there is a Win32 version of

the SYSLINUX installer. However, because Windows XP does not natively support
mounting a CD-ROM ISO image, you may need to install the MS Virtual CD Control
Panel (see support.microsoft.com/kb/916902) or a comparable utility to allow you to
extract the kernel and initrd.img files from your Red Hat installation media. (Or you can
just burn the first CD and copy the files from physical media.) Also, Windows does not
natively provide a way to backup & restore a flashdrive disk image, so you may want a
helper program for that as well. The shareware program WinImage 8.0
(www.winimage.com) supports full backup and restore as well as the ability to browse or
mount ISO, floppy or HDD images. Another good alternative is the open-source
program “dd for Windows” (www.chrysocome.net/dd) which provides functionality
equivalent to Linux dd.
3.1 Backing up your USB flashdrive
Using WinImage, select Disk -> Create Virtual Hard Disk image from physical drive. To
restore, select Disk -> Restore Virtual Hard Disk image to physical drive. This is the
equivalent of a Linux dd operation; the resulting file is raw HDD image file, which should
be interoperable with dd. One of the advantages of WinImage is that it clearly identifies
your removable drives, making it much less likely to overwrite a hard drive by mistake.
Using dd for Windows you can backup the entire device in a manner similar to dd for
Linux. As in the Linux environment, you must be very careful to properly identify your
target device. The command dd --list will display all mounted Volumes (i.e. filesystems)
and all attached Block Devices. The Volume references only the contents of the
partition. The Block Device references the entire flashdrive.
Here is sample output from a machine with one hard drive (containing two partitions, c:
and d:), and an 8GB USB flashdrive (e:). Note that the flashdrive appears as
“Harddisk1” but is clearly designated as “removable media”:
C:\>dd --list
rawwrite dd for windows version 0.5.
Written by John Newbigin <jn@it.swin.edu.au>
This program is covered by the GPL. See copying.txt for
Win32 Available Volume Information
\\.\Volume{46add03f-5b11-11da-9d19-806d6172696f}\
link to \\?\Device\HarddiskVolume1
fixed media
Mounted on \\.\c:
\\.\Volume{c2c0ee50-f6e0-11d7-ad9e-806d6172696f}\
fixed media
Mounted on \\.\d:
\\.\Volume{f58b907a-5bb4-11da-ae13-806d6172696f}\
link to \\?\Device\CdRom0
CD-ROM
Mounted on \\.\z:
\\.\Volume{d87abfa8-e0cb-11d7-81dc-806d6172696f}\
link to \\?\Device\Floppy0
removeable media
Mounted on \\.\a:
\\.\Volume{a858ba7c-8cf8-11dc-b1a5-005056c00008}\
link to \\?\Device\Harddisk1\DP(1)0-0+7
removeable media
Mounted on \\.\e:
NT Block Device Objects

\\?\Device\CdRom0
size is 2147483647 bytes
\\?\Device\Floppy0
\\?\Device\Harddisk0\Partition0
link to \\?\Device\Harddisk0\DR0
Fixed hard disk media. Block size = 512
link to \\?\Device\Harddisk1\DR6
Removable media other than floppy. Block size = 512
link to \\?\Device\Harddisk1\DP(1)0-0+7
Removable media other than floppy. Block size = 512
Windows dd has a feature that can help safeguard against accidentally writing to the
wrong device. The command-line switch --filter allows you to specify the type of device
you intend to target. If the device types don’t match, dd will not perform the operation.
In our examples we use --filter=removable to prevent overwriting the fixed disk. We
also use the --progress switch, which shows the realtime status of the copy.
The following command will backup the full contents of the flashdrive. Note that we are
referencing the Block Device here, not the Volume. Partition0 refers to the entire
device:
C:\>dd --progress if=\\?\Device\Harddisk1\Partition0 of=my_FD_backup.img bs=1M

This program is covered by the GPL. See copying.txt for details
8,254,390,272
7872+0 records in
7872+0 records out
To restore:
C:\> dd --progress --filter=removable if=HDD_backup.tmp.img \

of=\\?\Device\Harddisk1\Partition1 bs=1M
This program is covered by the GPL. See copying.txt for details
8,254,390,272
7872+0 records in
7872+0 records out
Note: The choice of block size affects the copy speed considerably. We used bs=1M as
recommended in the documentation. You may also need to use the --size parameter to
help dd correctly identify the end of the device. See the dd for Windows “man page” for
more info.
If you use a backup utility other than dd or WinImage, make sure it has the ability to
capture the entire contents of the flashdrive including the MBR, not just the contents of
the filesystem.
3.2 Installing the SYSLINUX bootloader
First you will need to obtain the files syslinux.exe (the Win32 SYSLINUX installer) and
menu.c32. You can copy these files from your Linux installation or download the
package syslinux-3.52.zip from http://www.kernel.org/pub/linux/utils/boot/syslinux/.
To make the flashdrive bootable with SYSLINUX enter the following command
(substitute a different drive letter as appropriate):
C:\Utils\Syslinux> syslinux –am e:
This sets the partition boot flag and installs generic boot code to the MBR (equivalent of
steps 2.5 and 2.6 above) as well as initializing the PBR and installing the ldlinux.sys file
(step 2.7).
Following this you will need to copy the menu.c32 file to the root directory of the
flashdrive.
3.3 Completing the installation
Finally, copy the syslinux.cfg and ks.cfg files to the flashdrive as described for Linux.
Extract the vmlinuz and initrd.img files from the Red Hat installation media using the
Microsoft Virtual CD Control Panel, WinImage or comparable utility. Install the files into
the appropriate directory structure on the flashdrive.
4.0 Test and deployment
At this point you should have a bootable USB flashdrive capable of installing Red Hat
Linux. In general, installing from flashdrive is not much different than installing from any
other media type. In this section we will address the handful of known issues specific to
installing from flashdrive, and review some of the common problems encountered when
trying to get a machine to boot from USB.
4.1 Configuring your server BIOS to boot from USB
You may have to make some adjustments to your server BIOS to make it boot from a
flashdrive. If your server supports a “boot menu” during POST (F12 on IBM servers),
you can boot from the flashdrive without having to make the change permanent in the
BIOS. Otherwise, you may have to enter the BIOS setup screen to change the boot
order (F1 on IBM servers).
An IBM HS20 Blade server, for example, has a boot menu. Insert your USB flashdrive
in the BladeCenter’s Media Tray, reboot and hit F12 at the appropriate point. When the
boot menu appears, select “USB Key/Disk”. The system will display a list of available
devices, which should include your flashdrive; select your device and hit Enter. You will
then see a screen that allows you to choose “Persistent” or “This boot only”. Make your
selection, then “Exit and continue booting”.
If your system does not have a boot menu you may have to go into the BIOS and
change the boot order. The following example is from a generic whitebox server with
Phoenix® BIOS. Note the USB key falls under the “Hard Drive” category. This can be
a bit confusing but is the way most BIOS do it. One of the drawbacks to putting a
removable drive in the same category as the fixed HDD is that when the USB device is
removed and later reinserted, it may not go back to the top of the list. So it is a
frustrating fact of some BIOS that there is no easy way to make them always boot the
USB key first if present. On some machines you need to edit the boot order each time.
Note that many older BIOS have entries like “USB-HDD”, USB-FDD” and “USB-
CDROM” in the boot device menu. These are more commonly for USB-attached
devices like a ZIP drive, USB floppy or USB CD-ROM, NOT a USB flashdrive. It is
more common to find the USB flashdrive listed under the “Hard Drive” as shown above.
Finally, be aware that many older BIOS simply will not boot from USB flashdrive, even if
it is listed in the boot menu. This is just one of the pitfalls of a relatively new technology.
If in doubt, upgrade your system BIOS to the latest available and try again.
4.2 Installing Linux
Upon booting from the flashdrive you should see a SYSLINUX menu like the one shown
here:
Tip: If you hit Tab from SYSLINUX menu you can view or even edit your kernel
command line. This is very useful for debugging as it allows you to try something
different without having to edit your syslinux.cfg:
Make your selection from the menu and hit Enter, and SYSLINUX will to load the
appropriate kernel and initrd which will start the installer running. After a moment,
Anconda will try to locate the install media (ISO images) as specified on the kernel
command line (above) or in the kickstart file. If this is not specified, or for whatever
reason Anaconda cannot find the files, it will prompt you for the location. This is a
common point of failure when trying to automate the install as it depends on a correct
reference to the USB device, which may vary from system to system. As described in
section 2.9, it may take a little experimentation to get this right. Once the install media
is located you will see the following message at the bottom of the screen:
After which, the GUI installer should start:
Note: When using Kickstart (for unattended install), by default you will not see any of the
Anaconda screens that you would during a manual install, unless the installer cannot
find the necessary response in the kickstart file and needs to prompt you. However,
there are two switches you can use within the kickstart file to give you a degree of
control over this. The first is autostep, which tells Anaconda to flash each screen for a
second, even if no input is required. The other is interactive, which tells Anconda to
stop on each screen. The result is similar to a manual install except each screen is pre-
populated with the info from your kickstart file. If all the parameters are correct, all you
need to do is hit “Next” at each screen. This is particularly useful for debugging,
4.3 Known issues
One of the caveats of using USB flashdrive for installation is that the system treats the
flashdrive just like a HDD, and in some circumstances this can confuse the Linux
installer. The major issue is not with the Anaconda installer itself, which seems to
always enumerate the real HDDs before the USB flashdrive, even if the system was
booted from the flashdrive. In all our tests, Anaconda successfully chose the real HDD
as the correct installation target, rather than the USB flashdrive, by default. The worst
side effect of having the USB stick present is that an extra entry is sometimes placed in
grub.conf that refers to the USB flashdrive (as if to infer the flashdrive could be an
additional boot option, even if it were present after the install). If this occurs, you may
want to clean up grub.conf by removing the entry. Or, you can prevent this during
installation by de-selecting the USB flashdrive if it appears in the list of possible install
destinations, or by using the following line in kickstart:
ignoredisk --drives=sdb
The bigger issue is with the GRUB bootloader which can, in some circumstances,
confuse the USB flashdrive with the target installation drive. This is likely due to the fact
that the flashdrive is first in the BIOS boot order (drive 0x80) during the install. When
this happens, GRUB will mistakenly install itself to the MBR of the flashdrive instead of
the target installation drive, overwriting the SYSLINUX bootcode on the flashdrive. In
addition, GRUB may write incorrect entries to grub.conf. If GRUB treats the flashdrive
as the first drive in the boot order, hd(0), then it will mistakenly refer to the target
installation drive as hd(1).
The result is that the newly-installed system will not be bootable. (Or, it’s possible the
system WILL be bootable as long as the USB stick is present but will not boot after it’s
removed). This can be repaired post-installation by booting to Linux rescue mode,
editing grub.conf and performing a GRUB restore operation (root command followed by
setup). Or it can be prevented during install, simply by making sure the flashdrive is
NOT selected first in the GRUB Drive Order. During the partitioning phase, select
“Configure advanced bootloader options” followed by “Change Drive Order” and make
sure your target installation drive appears first in the list. This can also be done with the
following line in kickstart:
bootloader --driveorder=sda
where the drive specified is the target installation drive, not the USB flashdrive. This will
ensure that GRUB treats the target installation drive as first in the BIOS boot order,
even if that is not the case at the time of installation.
Appendix A – Sample configuration files
Sample SYSLINUX menu file (syslinux.cfg):
DEFAULT menu.c32
MENU TITLE Linux Installation Boot Menu

LABEL RHEL4.4
KERNEL li/RHEL4.4/i386/vmlinuz
APPEND linux load_ramdisk=1 initrd=li/RHEL4.4/i386/initrd.img

LABEL RHEL4.4_KS
APPEND linux load_ramdisk=1 initrd=li/RHEL4.4/i386/initrd.img \
## -- Linux Rescue mode - RHEL 4.4...

LABEL RHEL4.4_Rescue
MENU LABEL RHEL AS 4.4 Linux Rescue mode
APPEND linux rescue load_ramdisk=1 initrd=li/RHEL4.4/i386/initrd.img \

LABEL RHEL5.1
APPEND linux load_ramdisk=1 initrd=li/RHEL5.1/x86_64/initrd.img

LABEL RHEL5.1_KS
APPEND linux load_ramdisk=1 initrd=li/RHEL5.1/x86_64/initrd.img \
## -- Linux Rescue mode - RHEL 5.1...

LABEL RHEL5.1_Rescue
MENU LABEL RHEL AS 5.1 Linux Rescue mode
APPEND linux rescue load_ramdisk=1 initrd=li/RHEL5.1/x86_64/initrd.img \
Sample Red Hat Kickstart file (ks.cfg):
# ====================================================================
# Kickstart configuration file for Red Hat
# ====================================================================
# --------------------------------------------------------------------
# Select install (default) or upgrade...
# --------------------------------------------------------------------
# upgrade
install
# --------------------------------------------------------------------
# Enable interactive or autostep installation...
# --------------------------------------------------------------------
# interactive
autostep
# --------------------------------------------------------------------
# System language, language modules, keyboard...
# --------------------------------------------------------------------
lang en_US
langsupport --default=en_US
keyboard us
# --------------------------------------------------------------------
# Comment out to prevent from being prompted for "Installation number",
# RHEL 5 only!
# --------------------------------------------------------------------
# key --skip
# --------------------------------------------------------------------
# X11 configuration...
# --------------------------------------------------------------------
# xconfig --vsync 80-85 --resolution 1024x768 --depth 24 --startxonboot --
defaultdesktop gnome
xconfig --resolution 1280x1024 --depth 24
# --------------------------------------------------------------------
# Network configuration...
# --------------------------------------------------------------------
network --device eth0 --bootproto dhcp
# network --bootproto=static --ip=192.168.0.29 --netmask=255.255.255.0 --
gateway=192.168.0.1 --nameserver=192.168.0.1
# --------------------------------------------------------------------
# Set root password...
# --------------------------------------------------------------------
rootpw passw0rd
# --------------------------------------------------------------------
# Timezone, firewall, use shadow file with md5 hash...
# --------------------------------------------------------------------
timezone America/New_York
firewall --disabled
authconfig --enableshadow --enablemd5
# ====================================================================
# Disk Partitioning (comment out this entire section for "upgrade")...
# ====================================================================
# --------------------------------------------------------------------
# Force Anaconda to ignore the USB flashdrive...
# --------------------------------------------------------------------
ignoredisk --drives=sdb
# --------------------------------------------------------------------
# Force grub to treat the real HDD as first in the BIOS boot order
# (drive 0x80) even though the system is currently booted from the USB stick.
# --------------------------------------------------------------------
bootloader --driveorder=sda
# --------------------------------------------------------------------
# Clear the Master Boot Record...
# --------------------------------------------------------------------
zerombr yes
# --------------------------------------------------------------------
# Clear all partitions (UNCOMMENTING THIS LINE WILL DELETE ALL PARTITIONS!!!).
# --------------------------------------------------------------------
clearpart --all --initlabel
# --------------------------------------------------------------------
# Partitioning scheme...
# --------------------------------------------------------------------
# part /boot --fstype ext3 --size 75 --asprimary
# part swap --recommended
# part / --fstype ext3 --size 2700 --grow
# --------------------------------------------------------------------
# Use auto partitioning...
# --------------------------------------------------------------------
autopart
# ====================================================================
# Package selection...
# ====================================================================
%packages
@Everything
Appendix B – Advanced topics
Here we will review some advanced topics like partitioning, formatting and device
transfer speeds.
B.1 Repartitioning in Linux
Linux allows you to repartition a removable drive just as you would a fixed HDD.
However, you may find that after repartitioning, the new partitioning scheme does not
exactly match the old one. There are a number of reasons why this might be, and we
touch on a few of these reasons below. In short, most of the differences are due to
differences in interpretation of the disk geometry, a legacy concept that is largely
irrelevant for a device like flash memory. In terms of actual operation, these differences
are usually of no consequence and can be ignored.
Here we will run through the procedure of repartitioning a flashdrive and then restoring it
to its original state. We start by examining the existing partition table with fdisk “expert
mode”. The following example is from a generic 8GB drive:
[root@ss1 ~]# fdisk /dev/sdc
The number of cylinders for this disk is set to 31488.

There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): x
Expert command (m for help): p
Disk /dev/sdc: 16 heads, 32 sectors, 31488 cylinders
Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID

1 00 1 1 0 15 32 767 32 16121824 0c
2 00 0 0 0 0 0 0 0 0 00
3 00 0 0 0 0 0 0 0 0 00
4 00 0 0 0 0 0 0 0 0 00
Here we see that the partition identifier is set to “0xc” (FAT32-LBA) and that the partition
is currently not bootable (AF=00). The total sector count is 16121824 + 32 = 16121856,
or about 8GB. Note that this partition table was made using a CHS geometry of 31488
cylinders, 16 heads and 32 sectors/track, or 31488/16/32. And fdisk is giving us a
warning that the cylinder count is greater than 1024.
Next, return to the main menu, delete the partition, write and exit:
Expert command (m for help): r
Command (m for help): d
Selected partition 1


Syncing disks.
The partition table is now empty. Next, rerun fdisk to create a new partition, accepting
the default values (utilize all space). Also, change the partition ID (“type”, in fdisk) to
match the original value of 0xc, and set the active flag to make the partition bootable.
Write the new partition table and exit:
Command (m for help): n

Command action
e extended
p primary partition (1-4)
p
First cylinder (1-1023, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-1023, default 1023):
Using default value 1023
Command (m for help): t

Selected partition 1
Hex code (type L to list codes): c
Changed system type of partition 1 to c (W95 FAT32 (LBA))
Command (m for help): a



Syncing disks.
Now rerun fdisk and print the new partition table:
Command (m for help): x
Expert command (m for help): p

1 80 1 1 0 253 62 1022 62 16110142 0c
2 00 0 0 0 0 0 0 0 0 00
3 00 0 0 0 0 0 0 0 0 00
4 00 0 0 0 0 0 0 0 0 00
Note that this partition table is slightly different than the original. The total sector count
(Start plus Size) is now 16110204 . The new CHS geometry is 1023/254/62, and fdisk
no longer complains about the cylinder count being greater than 1024. Why the
difference?
The original partition table (as-shipped from the factory) was made under CHS
geometry 31488/16/32. While this is a valid (ANSI standard ATA-1) geometry, it is valid
only as a physical CHS (P-CHS) geometry, not a logical CHS (L-CHS) geometry. Put
another way, it is not a geometry that be represented in the standard 24-bit (CHS 10-
bit/8-bit/6-bit) partition table, since the cylinder count is greater than 10-bits (1024).
Legacy bootloaders and OSes (like older versions of DOS) that follow the original BIOS
Int 13h specification (so-called “pre-LBA” systems) are restricted to using only L-CHS
(i.e. 24-bit) addresses. Such systems will be incapable of handling this P-CHS disk
geometry—or, at least, will be restricted to operating only within the first 1024 cylinders.
This is why fdisk gave us the warning.
Taking a closer look at the ending CHS values in the original partition table, we see that
the values are essentially meaningless. The ending cylinder value of 767 is simply what
would be the correct value, 31487, truncated to 10-bits! A legacy OS would likely not
understand this partition table at all—or, at best, would be restricted to using only the
first 768 cylinders (roughly 192 MB) of the device.
As for the LBA values in the original partition table (which is all that really matters to
modern OS like Linux and Window), they are correct and consistent with an 8GB
device. To prove that the CHS geometry is indeed valid (if only in terms of P-CHS) we
see that:
31488 cylinders * 16 heads * 32 sectors/track = 16121856 sectors
which agrees with the total LBA sector count (16121824 + 32) in the original partition
table.
So, why did fdisk alter the partitioning? Because this device is under the 8 GB
“barrier”—just under, in fact—the CHS geometry CAN actually be represented in L-CHS
(24-bit) values. And Linux fdisk, being old-fashioned, always tries to use valid CHS
values (and end the partition on a cylinder boundary) when creating a new partition
table. So, fdisk translated the CHS geometry into one that would be valid in the pre-
LBA world: 1023/254/62. This is a geometry that should allow legacy systems to utilize
the entire disk. To prove the new CHS and LBA values agree:
1023 cylinders * 254 heads * 62 sectors/track = 16110204 sectors
which agrees with the total LBA sector count (16110142 + 62) in the new partition table.
Note there is a slight penalty for playing by the L-CHS rules: the new sector count is
less than the original, meaning we’ve lost a small amount (about 6 MB) of usable space.
(This is mostly likely why the device is partitioned as it is from the factory: it is
considered more important to utilize all available space than it is to provide compatibility
for legacy systems.)
So, which partitioning scheme is correct, and does it make a difference which one we
use? Strictly speaking, both are correct; the partitioning scheme created by fdisk is just
a bit more “friendly” to legacy systems. And for most modern OSes and bootloaders, it
probably does not matter which one we use. Newer systems pay attention only to the
LBA (raw sector) values in the partition table and typically ignore the CHS values
entirely. In our tests, both partitioning schemes worked fine in both Linux and Windows,
and neither caused any problems for SYSLINUX or the Anaconda installer. However, if
you were trying to configure a USB flashdrive to boot a pre-LBA OS like DOS, these
differences might be very important.
One final note: repartitioning in Windows XP will produce similar results (see section
B.3). Windows also will also try to create a partition table with valid L-CHS values,
although the new geometry may not mach the one created by Linux fdisk. (Such is the
nature of partitioning tools: they all operate a little bit differently.)
To recover the original the original partition table, you either can restore the MBR (or the
entire disk image) from backup as described earlier, or you can try to recreate the
partition table with fdisk. This a bit tricky, since fdisk does not like to break the legacy
CHS rules. However, you can brute-force it by using the Linux sfdisk command (see
man sfdisk for more info):
echo "0,,c * 0,1,1 767,15,32" | sfdisk -D -C 31488 -H 16 -S 32 /dev/sdc
This will recover the original partition table, with the exception that we are leaving the
partition in a bootable state (AF=80):

1 80 1 1 0 15 32 767 32 16121824 0c
2 00 0 0 0 0 0 0 0 0 00
3 00 0 0 0 0 0 0 0 0 00
4 00 0 0 0 0 0 0 0 0 00
B.2 Reformatting in Linux
You can use Linux mkdosfs to create a FAT16 or FAT32 filesystem. You can also use
dosfsck to check or repair a FAT16 or FAT32 filesystem. SYSLINUX and the Anaconda
installer support both filesystems. However, with FAT16 you will hit a file size limitation
at 2GB and a max volume size limitation at 4GB, so in the long run you are better off
using FAT32.
Note: Stay away from older versions of dosfsck where the FAT32 support is still listed
as “ALPHA” level, as they may report erroneous errors. The tests here were done with
mkdosfs and dosfsck v2.11.
To format the partition with mkdosfs and assign a volume label:
[root@ss2 ~]# mkdosfs -v -n "Flashdrive" /dev/sdc1

mkdosfs 2.11 (12 Mar 2005)
Auto-selecting FAT32 for large filesystem
/dev/sdc1 has 254 heads and 62 sectors per track,
logical sector size is 512,
using 0xf8 media descriptor, with 16121824 sectors;
file system has 2 32-bit FATs and 8 sectors per cluster.
FAT size is 15714 sectors, and provides 2011295 clusters.
Volume ID is 473a6a0d, volume label Flashdrive .
In this case mkdosfs selected FAT32 by default. (To override this selection manually,
use the ‘-F’ switch.) Now verify the results with dosfsck:
[root@ss2 ~]# dosfsck -v /dev/sdc1
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "mkdosfs"
Media byte 0xf8 (hard disk)
512 bytes per logical sector
4096 bytes per cluster
32 reserved sectors
First FAT starts at byte 16384 (sector 32)
2 FATs, 32 bit entries
8045568 bytes per FAT (= 15714 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 16107520 (sector 31460)
2011295 data clusters (8238264320 bytes)
62 sectors/track, 254 heads
0 hidden sectors
16121824 sectors total
Checking for unused clusters.
Checking free cluster summary.
/dev/sdc1: 1 files, 1/2011295 clusters
The use of FAT32 is confirmed by the listing of “32 bit entries” in the output. (Don’t be
confused by the “FAT32” in the dosfsck banner; it will say that even if the filesystem is
FAT16.)
Just as a heads-up, we note a bit of unusual behavior after initializing the partition with
SYSLINUX:
[root@ss2 ~]# syslinux /dev/sdc1
[root@ss2 ~]# dosfsck -v /dev/sdc1

dosfsck 2.11 (12 Mar 2005)
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
Checking we can access the last sector of the filesystem
There are differences between boot sector and its backup.
Differences: (offset:original/backup)
90:fa/0e, 91:fc/1f, 92:31/be, 93:c0/77, 94:8e/7c, 95:d0/ac, 96:bc/22
, 97:b4/c0, 98:7b/74, 99:8e/0b, 100:c0/56, 101:b9/b4, 102:08/0e, 103:00/bb
, 104:89/07, 105:e7/00, 106:f3/cd, 107:a5/10, 108:8e/5e, 109:d8/eb
, 110:bb/f0, 111:78/32, 112:00/e4, 113:0f/cd, 114:b4/16, 115:37/cd
.
.
, 487:74/00, 488:20/00, 489:65/00, 490:72/00, 491:72/00, 492:6f/00
, 493:72/00, 494:0d/00, 495:0a/00, 504:86/00, 505:3d/00, 508:7f/00
1) Copy original to backup
2) Copy backup to original
3) No action
?
FAT32 stores a backup Partition Boot Record (PBR) as a failsafe, and dosfsck is
complaining that the backup does not match PBR currently in use. This is because
SYSLINUX altered the active PBR (by installing boot code) without updating the
backup. To correct this you can run dosfsck in repair mode (-r), and copy the new PBR
to the FAT32 backup (“Copy original to backup”).
Note that this PBR mismatch issue is reported here FYI, and is unlikely to cause a
problem in any real life scenario. And it will not be an issue at all with FAT16.
One final anomaly worth mentioning: Linux mkdosfs does not seem to be able to
determine the number of hidden sectors (a.k.a. partition offset) when creating a new file
system. This value should agree with the LBA Start value in from the partition table. It
is unlikely this will cause a problem in any real life scenario, as most modern kernels
simply ignore this value in the PBR. Nevertheless, the value can be set manually using
the mkdosfs -h option.
B.3 Repartitioning in Windows
By default, Windows XP will not allow you to repartition a flashdrive. If you try to delete
the partition via Disk Management you will find the option grayed out. The command
line tool DISKPART is of no help since that program will not operate on a removable
drive at all. However, if you do wish to alter the partitioning from within Windows, there
is a way around this.
If you change the partition identifier (PartID) to a value Windows does not recognize
(such as 0x83 / Linux), Disk Management will allow you to delete the partition, after
which it will consider the device as Unallocated space. Or, if you change PartID to 0x0
(Empty partition), Windows will recognize the device as Unallocated immediately. Once
in the Unallocated state, Disk Management will allow you to run the New Partition
Wizard on the device. The PartID can be changed using an external program like Linux
dd.
One might think that deleting the partition, or overwriting the partition table entirely,
would have the same effect as changing the PartID to zero. But this is not the case. If
Windows does not recognize a valid partition table it will treat the device as
Unpartitioned space. If you format the device in this state Windows will create a new
filesystem without creating a partition table first (e.g. “superfloppy” or Magneto-optical
format). This is not a desirable formatting for most modern systems.
This last point is noteworthy because it means that simply overwriting the MBR with all
zeros, as in the following command, will NOT have the desired effect:
dd if=/dev/zero of=\\?\Device\Harddisk1\Partition0 bs=512 count=1
While it is possible, using Linux dd, to zero ONLY the PartID (of partition 1) with a
command like:
dd if=/dev/zero of=/dev/sdc bs=1 count=1 seek=450
dd for Windows apparently does NOT support block sizes less than 512, making it
incapable of editing any such data WITHIN a sector. This makes it difficult to perform
the repartitioning operation entirely within Windows. A third-party partitioning tool would
be required—one specifically designed to operate on removable drives (e.g. Acronis®
Disk Director Suite).
B.4 Reformatting in Windows
Formatting a removable drive is easy in Windows. Disk Management will allow you to
create (or check) a FAT16 or FAT32 filesystem on a removable drive. Or if you want to
see more detailed output, you can still use the command-line format:
C:\>format e: /FS:FAT32 /V:Flashdrive /Q

Insert new disk for drive E:
and press ENTER when ready...
The type of the file system is FAT32.
QuickFormatting 7866M
Initializing the File Allocation Table (FAT)...
Format complete.
8,039,348 KB total disk space.
8,039,344 KB are available.
4,096 bytes in each allocation unit.

2,009,836 allocation units available on disk.
32 bits in each FAT entry.
Volume Serial Number is E4FE-0DDF
and chkdsk:
C:\>chkdsk e:
The type of the file system is FAT32.
Volume FLASHDRIVE created 11/20/2007 11:50 PM
Volume Serial Number is E4FE-0DDF
Windows is verifying files and folders...
File and folder verification is complete.
Windows has checked the file system and found no problems.
8,039,348 KB total disk space.
8,039,344 KB are available.
4,096 bytes in each allocation unit.

2,009,837 total allocation units on disk.
2,009,836 allocation units available on disk.
B.5 Device transfer speeds
Not all flashdrives are created equal. Here are some simple benchmarks generated by
Linux hdparm on USB 2.0 capable machine running RHEL 4.4. This covers read speed
only; write speed tends to be roughly half the read speed or less. Your mileage may
vary.
[root@ss1 ~]# hdparm -t /dev/sdc
## -- Memorex Mini TravelDrive (256 MB),,,

Timing buffered disk reads: 38 MB in 3.16 seconds = 12.04 MB/sec
## -- PQI Cool Drive (512 MB)...

## -- Sandisk Cruzer (1 GB)...

## -- Memorex TravelDrive (2 GB)...

## -- PNY Mini Attache (4 GB)...

## -- Patriot Xporter (8 GB)...

References
Anvin, H. Peter. “The SYSLINUX Project”, <http://syslinux.zytor.com>
Heller, David E., Pierson, David R. and Nolterieke, Mike. “Updating System Firmware
using the PXE Boot Method of Remote Deployment”, 6 July, 2007, IBM Techdocs - The
Technical Sales Library (Internal),
<http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101079>
Landis, Hale. “BIOS Types, CHS Translation, LBA and Other Good Stuff”, 11 February
1995, For the T10 Technical Committee of the InterNational Committee on Information
Technology Standards (INCITS), <www.t10.org/ftp/t10/document.95/95-156r0.pdf>
Newbigin, John. “dd for Windows”, <http://www.chrysocome.net/dd>
Norton, Peter. Inside the IBM PC, New York: Brady Communications, 1986.
Sedory, Daniel B. “Understanding Disk Drive Terminology, Technology

and Capacity Calculations”, 14 June 2005,
<http://www.geocities.com/thestarman3/asm/mbr/DiskTerms.htm>
“Red Hat Enterprise Linux Installation Guide (RHEL 5 version)”, Red Hat, Inc., © 2006,
<http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Installation_Guide-
en-US/>
“AT Attachment”, Wikipedia / The Wikimedia Foundation, 12 Nov 2007,

<http://en.wikipedia.org/wiki/AT_Attachment>
“Disk Management Cannot Create or Delete Partitions on Removable Storage Media”,

28 Feb 2007, Microsoft Knowledge Base – Article ID: KB254109 / Q254109,
<http://support.microsoft.com/kb/254109>
“How to customize Windows PE by using the source files that are included with the
Microsoft SMS 2003 Operating System Deployment (OSD) Feature Pack”, 30 Oct 2006,
Microsoft Knowledge Base – Article ID: KB916902,
<http://support.microsoft.com/kb/916902>

Installing Linux From A USB Flash Drive

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Installing Linux From A USB Flash Drive

Uploaded by

Copyright:

Available Formats

Installing Red Hat Linux from a USB

1.0 INTRODUCTION ....................................................................................................................................................1

1.1 Benefits of USB flashdrive

© 2007 IBM, Version 2.0, Nov 26, 2007 http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/Web/Techdocs Page 1

[root@ss1 ~]# tail –f /var/log/messages

You will need the following:

1. A 4GB or greater capacity USB flashdrive.

© 2007 IBM, Version 2.0, Nov 26, 2007 http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/Web/Techdocs Page 2

© 2007 IBM, Version 2.0, Nov 26, 2007 http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/Web/Techdocs Page 3

2.1 Upgrading your SYSLINUX package

SYSLINUX is bundled with most popular Linux distributions, but it is recommended to

rpm –ihv syslinux-3.52-1.el4.rf.x86_64.rpm

To upgrade from a previous version:

rpm –Uhv syslinux-3.52-1.el4.rf.x86_64.rpm

Note: Starting with v.3.52, SYSLINUX has a dependency on “perl-Crypt-PasswdMD5”

2.2 Mounting and unmounting your USB flashdrive

If in doubt, check using the mount command:

[root@ss1 ~]# mount

mount /dev/sdc1 /media/usbdisk

© 2007 IBM, Version 2.0, Nov 26, 2007 http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/Web/Techdocs Page 4

dd if=/dev/sdc | gzip -c > my_flashdrive_backup.img.gz

Or, if compression was used:

gunzip -c my_flashdrive_backup.img.gz | dd of=/dev/sdc

Finally, to back up your flashdrive’s MBR only:

dd bs=512 count=1 if=/dev/sdc of=my_flashdrive_mbr.bin

dd bs=512 count=1 if=my_flashdrive_mbr.bin of=/dev/sdc

2.4 Using your flashdrive’s existing partitioning and formatting

© 2007 IBM, Version 2.0, Nov 26, 2007 http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/Web/Techdocs Page 5

1. The MBR must contain generic “boot code”

2.5 Installing generic boot code to the MBR

hexdump -C /dev/sdc | more

To install the SYSLINUX generic MBR boot code:

© 2007 IBM, Version 2.0, Nov 26, 2007 http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/Web/Techdocs Page 6

Command (m for help): p

Disk /dev/sdc: 8254 MB, 8254390272 bytes

Device Boot Start End Blocks Id System

Command (m for help): a

Command (m for help): p

Disk /dev/sdc: 8254 MB, 8254390272 bytes

Device Boot Start End Blocks Id System

Command (m for help): w

Calling ioctl() to re-read partition table.

2.7 Installing the SYSLINUX bootloader

Now, mount your partition:

© 2007 IBM, Version 2.0, Nov 26, 2007 http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/Web/Techdocs Page 7

Your flashdrive should now be bootable.

2.8 Copying the Red Hat installation media

[root@ss1 ~]# tree /media/usbdisk/li/

© 2007 IBM, Version 2.0, Nov 26, 2007 http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/Web/Techdocs Page 8

This example is for RHEL 5.1, x86_64 version:

mount -o loop RHEL5.1-Server-x86_64-DVD.iso loop

and / or the DVD-ROM ISO:

2.9 Creating the SYSLINUX menu file

© 2007 IBM, Version 2.0, Nov 26, 2007 http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/Web/Techdocs Page 9

## -- Manual install of RHEL 5.1...

## -- Kickstart install of RHEL 5.1...

To copy the completed file to the USB flashdrive:

© 2007 IBM, Version 2.0, Nov 26, 2007 http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/Web/Techdocs Page 10

Your flashdrive is now ready for deployment.

© 2007 IBM, Version 2.0, Nov 26, 2007 http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/Web/Techdocs Page 11

It is possible to prepare your USB flashdrive in Windows, as there is a Win32 version of

3.1 Backing up your USB flashdrive

© 2007 IBM, Version 2.0, Nov 26, 2007 http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/Web/Techdocs Page 12