Using

Using USB pen drive

mount /dev/sdb /media/usbdrive/

dir /media/usbdrive/

sudo umount /media/usbdrive
sudo eject /dev/sdb

documented on: 2006.03.07

Debian Wiki: BootUsb

http://wiki.debian.org/BootUsb

USB pendrive location and mount

Most USB pendrives are located at device node /dev/sda after they are plugged into the USB port.

However, you can verify this location by typing this command inside a terminal window:

dmesg | grep scsi -A 3

and it should tell you the device name for your USB (SCSI emulated) devices, along with the vendor name.

If you cannot find it, you have to load the USBStorage module. In a terminal, type:

modprobe usb-storage

and mount the usb filesystems

mount -t usb-devfs none /proc/bus/usb

Partitioning the USB key

The resulting partition table will look something like this:

Device       Boot      Start         End      Blocks        Id     System
 /dev/sda1   *           1              3730     1014544    6      FAT16

Now enter mkdosfs /dev/sda1 at the prompt to create a FAT16 filesystem, because otherwise the installation steps described under 'Unburned using DSL' later on won't work.

Unburned using DamnSmallLinux

download the ISO file and copy its contents into the USB pendrive.

To install DamnSmallLinux download the ISO image and as root user go the directory with the dsl-*.iso file and type the following:

mkdir dsl_temp
mkdir dsl_usb
mount -o loop dsl-*.iso dsl_temp
cp -a dsl_temp/* dsl_usb
cd dsl_usb
mv boot/isolinux/* ./
rm -Rf boot
mv isolinux.bin syslinux.bin
mv isolinux.cfg syslinux.cfg
cd ..
mkdir usb_pen
mount -t vfat /dev/sda1 usb_pen
cp -a dsl_usb/* usb_pen
umount usb_pen
umount dsl_temp
syslinux /dev/sda1

fstab entries for two different pendrives?

Newsgroups:  gmane.linux.debian.user
Date:        Sat, 26 Aug 2006 14:28:56 +0200

> yesterday I bought a new 256 MB pendrive, that wants to be mounted as
> `/dev/sda' whereas the other one I have wants `/dev/sda1'. Now, if in
> /etc/fstab I put the sda entry first, then can't mount sda1; and vice
> versa, if I put sda1 first then I can't mount sda.

If you install the "pmount" package and add your user to the "plugdev" group then you will not need fstab entries for pluggable devices anymore. (You should then just comment these entries out or remove them entirely.) Devices will be mounted at the correct mount point automatically. Even better, if you use the "pmount-hal" command then the devices will be mounted by their volume label so that you can address each medium unambiguously and independent of the order in which you attached them. This is also fully integrated in e.g. KDE and Gnome.

Florian Kulzer

fstab entries for two different pendrives?

> > Devices will be mounted at the correct mount point automatically.
>
> Don't they get mounted at some random point in /media?

OK, my statement is somewhat misleading. I was assuming, maybe mistakenly, that the OP needed a way to make sure that he could always address each of his two USB sticks in a deterministic way, regardless of the order in which they were plugged in. To my knowledge the easiest way to achieve this is to either use pmount-hal (if you are scripting yourself) or to rely on the built-in functionality of (some) modern desktop environments. If you have to bring both worlds together you can always use "lshal" and a bit of awk/grep/sed to find a specific device.

> (/me stabs repeatedly whatever fool decided the world needed two places
> to mount things...)

Well, somebody probably thought "media" is easier to understand than "mnt". I am not sure if it matters so much; the people who write their own scripts can (p)mount where they please and the other ones just click on the icon and often do not really have to know the mount point at all.

> > Even better, if you use the "pmount-hal" command then the devices will
> > be mounted by their volume label so that you can address each medium
> > unambiguously and independent of the order in which you attached them.
>
> Pre-supposing that the device *has* a volume label, and that you *know*
> what it is, so that you can find it in /media.

You can set the volume label yourself to provide unique identifiers for your stuff. (At least for USB sticks; I have never tried this with a camera.) If this is not feasible then you can normally use the uuid (universally unique identifier). For example, if I run "lshal —monitor" and plug in my USB stick, I see this:

Start monitoring devicelist:

usb_device_67b_2515_noserial added
usb_device_67b_2515_noserial_if0 added usb_device_67b_2515_noserial_usbraw
added usb_device_67b_2517_noserial added
usb_device_67b_2517_noserial_if0 added usb_device_67b_2517_noserial_usbraw
added usb_device_67b_2517_noserial_if0_scsi_host added
usb_device_67b_2517_noserial_if0_scsi_host_scsi_device_lun0 added
usb_device_67b_2517_noserial_if0_scsi_host_scsi_device_lun0 property
info.linux.driver = 'sd' (new)
storage_serial_Prolific_Technology_Inc__USB_Mass_Storage_Device added
volume_uuid_44E1_54A2 added

I can specify the desired mount point by generating a file named /usr/share/hal/fdi/policy/custom.fdi (or whatever.fdi) with the following contents:

<?xml version="1.0" encoding="UTF-8"?> <!-- -*- SGML -*- --> <deviceinfo
version="0.2">

<device>
  <match key="block.is_volume" bool="true">
    <match key="volume.fsusage" string="filesystem">
      <match key="volume.uuid" string="44E1-54A2">
        <merge key="volume.policy.desired_mount_point"
        type="string">usbstick-flo1</merge>
      </match>
    </match>
  </match>
</device>

</deviceinfo>

This device should now be mounted at /media/usbstick-flo1 by every DE, daemon, etc. that uses the hardware abstraction layer to handle devices.

> > This is also fulls integrated in e.g. KDE and Gnome.
>
> Fortunately, everyone does not use KDE or Gnome.

I did not mean to imply that everyone should. I know that the "automatic" mechanism which uses pmount and hal works for these two DEs, therefore I mentioned them; I would assume that it works on others, too, if they follow the freedesktop.org specifications.

If you write your own (auto)mounting scripts then you probably only need to use a udev rule to make sure a unique device symlink is created; see Alan Chandler's nice summary earlier in this thread.

Florian Kulzer

fstab entries for two different pendrives?

> I have the following problem: ...
> Any suggestion to be able to mount both?

Use udev to recognise the pendrive from its manufactures name, and create a symlink (or actual device) called /dev/flash. Mount that in /etc/fstab

[Sorry about mail wordwrap in the stuff below - you need to un wordwrap it in the real file]

I have a file in /etc/udev/rules.d called 01akcspecialrules that is shown below. I am not doing the same thing, but you would use a similar thing to my first two devices, except something like this (where the jumpdrive is not partitioned and the other device is)

# Portable Flash Storage
 BUS=="usb", SYSFS{product}=="JUMPDRIVE ELITE", KERNEL=="sd*",
 NAME="flash"
SYMLINK="jumpdrive flash"
 BUS=="usb", SYSFS{product}=="USB DISK 2.0", KERNEL=="sd?1", NAME="flash"
SYMLINK="integral_storage flash"
# use this line to get rid of the /dev/sda type entry for the partitioned
device
 BUS=="usb", SYSFS{product}=="USB DISK 2.0", KERNEL=="sd*", NAME=""
SYMLINK="integral_storage flash"

udevinfo

something like

udevinfo -a -p /block/sdc/sda1

Example: My 01akcspecialrules

# Portable Flash Storage
 BUS=="usb", SYSFS{product}=="JUMPDRIVE ELITE", KERNEL=="sd?1",
SYMLINK="jumpdrive flash"
 BUS=="usb", SYSFS{product}=="USB DISK 2.0", KERNEL=="sd?1",
SYMLINK="integral_storage flash"


# IRiver T30
 BUS=="usb" SYSFS{product}=="t30", KERNEL=="sd?1", NAME="iriver_t30",
SYMLINK="audioplayer", GROUP="audio"

# Digital Camera (either the C745UZ or the C220Z)
 BUS=="usb", SYSFS{product}=="C220Z", KERNEL=="sd?1", NAME="olympus_c220z"
 ,
SYMLINK="camera"
 BUS=="usb", SYSFS{product}=="C740UZ", KERNEL=="sd?1",
 NAME="olympus_c745uz",
SYMLINK="camera"

Alan Chandler

Pen drive real unmount

Newsgroups:  gmane.linux.debian.user
Date:        Sat, 11 Feb 2006 08:21:41 +0000

> My question is that I can mount-unmount the device perfectly, but in
> windows I notice that when I unmount it  the light from the pen drive
> goes off... and when I unmount it under linux the light stays on. A
> friend told me that I should unmount it using eject, that the light not
> going off is not a good thing, but nothing changes. I don't know if it
> has to do with the fact that my pen drive seems to be different ( having
> to mount it on another device ), or what.

The main reason for unmounting before unplugging is to make sure there isn't any data transfer occurring when you unplug the device, as this could cause permanent damage.

However, unmounting from the filesystem is not the same as removing the pen drive as a device. When you unmount the device, while it no longer appears in your filesystem, it still remains recognised by your PC as a device, it will still have a device assigned for it in /dev, it will still be drawing power, etc. This is a distinction that is less clear in Windows, which unmounts and unplugs a device simultaneously (even if that's not what you *want* it to do…)

I'm guessing that's why the light is still appearing. If the drive is unmounted then you should be able to unplug it without any risk, but if you want to be certain then you can always use "eject /dev/sda" (run as root or using sudo) which should then mean the light comes off.

(NB eject using "/dev/sda" because /dev/sda is the device itself, and /dev/sda1 is the partition on the device which stores the files.)

I have the same issue with my iPod, which keeps the "Do not disconnect" message up even after it's been unmounted from the filesystem, and if I just unplug it there are no problems.

John Halton

Using USB pen drive

Newsgroups:  gmane.linux.debian.user
Date:        Fri, 30 Dec 2005 17:13:29 -0500

Hi,

I need to copy some file from my friend's USB pen drive, but wasn't able to because I don't know how to properly mount it.

The disk partition looks like this:

$ fdisk -l /dev/sdb
Disk /dev/sdb: 521 MB, 521928704 bytes 17 heads, 59 sectors/track, 1016
cylinders Units = cylinders of 1003 * 512 = 513536 bytes

This doesn't look like a partition table Probably you selected the wrong
device.

What should I do to copy files from my friend's USB Drive? (I don't know how he created it, but it can be accessed ok in WinXP).

Using USB pen drive

> I tried to mount /dev/sdb1 with type auto and vfat, but failed. Then I
> tried with usbfs. It mounted ok, but I wasn't able to find any
> meaningful files from the mount:

usbfs is a virtual filesystem, like proc. It gives you information about connected USB devices by presenting it as part of the filesystem.

Try mounting /dev/sdb. I've seen Windows format the raw device without setting up a partition table — this is how floppies work usually, so Windows probably carried the concept over to other removable media.

Chris Howie

Using USB pen drive

> merely mount /dev/sdb will definately won't work, since there
> are apparently partitions in it...

Those "partitions" are the misinterpretation of the filesystem data as a partition table. There is a very good chance that /dev/sdb contains a file system. Try it before saying it won't work.

Chris Howie

Using USB pen drive

> I need to copy some file from my friend's USB pen drive, but wasn't able
> to because I don't know how to properly mount it.

The answer depends on which kernel version you are running, because there has been a switch from something older to something newer in the way usb pluggable devices are handled. The something newer is called 'udev'. There is some controversy about what to call the older, obsolete stuff. I am somewhat ahead of you in learning about this, but don't yet know the answer to your question. Just be sure to suspect any answer by someone who doesn't ask what kernel version you have before giving advice.

Paul E Condon

Storing files on a USB Flash Drive

http://linux.ncl.ac.uk/pen/

A USB flash drive is a small storage device that you can plug into a USB port on a computer and copy files to it like any other drive. The capacity of such a device is much higher than a floppy disk and much more reliable as there are no moving parts. They are ideal for moving files between machines and backing up your work. You can even get flash drives built into cameras, MP3 players, phones and even watches.

Insert a USB flash drive into a free USB port on the machine. An icon will appear on the desktop. Double-click on the usb icon to open a window showing the files on your flash drive. Drag and drop files from the file manager to add and remove files.

When you are ready to remove the flash drive, close the folder window and right-click on the desktop icon. Select Unmount Volume and the icon should disappear. It is now safe to remove your flash drive.

Troubleshooting

Open a terminal window (right-click on the desktop and select Open Terminal), login as root and create a mount point for the new device

# mkdir -p /mnt/usb

Add the following line to your /etc/fstab file

/dev/sda1 /mnt/usb vfat noauto,user 0 0

You can now use your flash drive as described above. See the mount and fstab man pages for more information.

Troubleshooting

If you get errors when trying to Unmount Volume it is because the device is still in use somehow. This is usually because you have a terminal open in that folder, or you are editing a file on the flash drive. You can use the command /usr/sbin/lsof +D /mnt/usb to see which programs are still accessing the drive.

Troubleshooting

If you follow the instructions above but don't get a Desktop icon then it is possible your distrobution is not using HAL and udev to detect new hardware. … which creates entries in your fstab file automatically.

If you plug in your USB flash drive then select the usb menu item but don't get an icon on the desktop, then it is possible that the hotplug program failed to load the drivers for your device correctly. Try unplugging the flash drive, waiting a few seconds, then replugging the drive and trying again.

Try opening a terminal window (right-click on desktop and select Open Terminal) then type dmesg. This shows you a list of messages from the kernel from when the machine was switched on and when drivers are loaded and unloaded on the machine. You should see lines similar to the following if the driver was loaded successfully,

Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
scsi1 : SCSI emulation for USB Mass Storage devices
  Vendor: USB Card  Model: Intelligent Stic  Rev: 2.02
  Type:   Direct-Access                      ANSI SCSI revision: 02
Attached scsi removable disk sda at scsi1, channel 0, id 0, lun 0
SCSI device sda: 261056 512-byte hdwr sectors (134 MB)
sda: Write Protect is off
 sda: sda1
WARNING: USB Mass Storage data integrity not assured
USB Mass Storage device found at 4
USB Mass Storage support registered.

Here we have a PQI Intelligent Stick with 134MB of storage and the SCSI emulation has assigned the name sda1 to the device. If you have more than one USB mass storage device connected to your machine at the same time then the device name that is assigned will be different and you should create additional mount points and entries in the /etc/fstab file.

If you unplug the flash drive before you Unmount Volume then the machine may still think the drive is connected and may lockup trying to talk to it.

USB flash drives will only work on versions of Linux with a 2.4.x kernel or above.

Flash drives that use Windows software to encrypt the filesystem will not work in Linux. The filesystem must be a normal FAT16 or FAT32 file system to work on both Windows and Linux desktops. It is also possible to use an encrypted filesystem in Linux, see Using an Encrypted Filesystem for more details.

The instructions on this page will be out of date once the gnome-volume-manager is introduced to the desktop which should be about the end of 2004 and should automate the entire process.

Using an Encrypted Filesystem

http://linux.ncl.ac.uk/encrypt/

If your machine is stolen then the thief will be able to read your confidential data directly off the hard drive. You can protect your data by using an encrypted file system. This method of protection is useful for laptop users who carry around sensitive data and for encrypting your backup data.

First create a large file and attach it to a loopback device using encryption, you will need to load the loopback module cryptoloop and the encryption module blowfish first. Provide a password for this file, then make a filesystem on the loopback device. Mount the new filesystem as normal, copy over the files you want to store securely, then unmount the filesystem. Finally detach the file from the loopback device. You should probably sync to make sure the data is written back to disk immediately. The following creates a 650Mb file suitable for pressing onto a CDR using blowfish encryption.

# /sbin/modprobe cryptoloop
# /sbin/modprobe blowfish
# dd if=/dev/zero of=secure bs=1k count=665600
# losetup -e blowfish /dev/loop0 secure
Password:
# mkfs -t ext2 /dev/loop0 665600
# mount -t ext2 /dev/loop0 /mnt/loop
...
# umount /dev/loop0
# losetup -d /dev/loop0
# sync

To access the encrypted filesystem again simply reattach the file to a loopback device and provide the password. Mount the filesystem then add, edit or remove files as required. When you are finished you can unmount then detach the file from the loopback device.

# losetup -e blowfish /dev/loop0 secure
Password:
# mount -t ext2 /dev/loop0 /mnt/loop
...
# umount /dev/loop0
# losetup -d /dev/loop0
# sync

You can make a couple of bash aliases similar to the following to make mounting and unmounting the encrypted filesystem easier, just add them to your .bashrc file.

alias mntsec='losetup -e blowfish /dev/loop0 secure; mount -t ext2 /dev/loop0 /mnt/loop'
alias umntsec='umount /dev/loop0; losetup -d /dev/loop0; sync'

You would use the aliases as follows,

# mntsec
Password:
...
# umntsec

If you enter the wrong password the mount will fail and you will have to detach the file using losetup -d /dev/loop0 and start again. You don't have to use blowfish for encryption but it is a good default if you know nothing about types of encryption. If you want to use a different type of encryption you can choose from the modules found in /lib/modules/…/kernel/crypto

Installing Debian onto USB flash media with everything encrypted

http://www.debian-administration.org/articles/179

by DaveV on Sat 9 Jul 2005

This is a simple procedure for installing Debian GNU/Linux onto a USB key flash media. It includes several configuration changes but tries to stay as close to a default debian install as possible.

This is useful for administrators that need to carry sensitive information or people concerned about their privacy.

This was tested on Debian Sid and Knoppix 3.8.

Installation Procedure

Shred the drive

shred -n 1 -z -v /dev/sdd

(One pass to shred, one pass to zero)

Create Partitions

We will create two partitions on the USB key, one for /boot and one for / (root). We do not create a swap partition because that would prematurely age the usb key. You may mount and use swap partitions from the local harddrives ala knoppix but that is up to you.
```
parted /dev/sdd "mklabel msdos mkpart primary 0 14 mkpart primary 15 -0"
```

Shred rootfs

shred -n 1 -v /dev/sdd2

(zero'd filesystems are bad for encrypted ones.)

Load modules if necessary

modprobe dm-crypt
modprobe aes

KNOPPIX NOTE: We need to install a few packages.

apt-get update
apt-get install cryptsetup dmsetup libdevmapper1.01

Created mapped crypt device for root
```
cryptsetup -y create rootfs /dev/sdd2
```
Format filesystems:

Since we can't use journaling filesystems on flash media (premature aging again), we fall back to good old ext2.
```
mkfs.ext2 /dev/mapper/rootfs
mkfs.ext2 /dev/sdd1
sync ; sync
```
Apply disk labels

We do this so that we can identify our drive when we boot on various systems. Using a strict device mapping often breaks if other usb or flash devices are detected before ours.You may use any label that you like, but you will have to remember to update the initrd (file: /sbin/init)
```
e2label /dev/sdd1 PRIVDEB_BOOT
```

Make temporary mount points and mount

mkdir /mnt/buildroot/
mount /dev/mapper/rootfs /mnt/buildroot
mkdir /mnt/buildroot/boot
mount /dev/sdd1 /mnt/buildroot/boot

Install base files.

debootstrap --arch i386 sid /mnt/buildroot

Note: Installed size is about 160MB at this stage.

KNOPPIX NOTE: We need to copy a few extra devices over.

cp -ap /dev/ub[a-f]* /mnt/buildroot/dev/

Enter chroot jail to work on system.
```
chroot /mnt/buildroot/ /bin/su -
```

Build fstab and mount everything.

Create /etc/fstab file

#/etc/fstab: static file system information.
#
LABEL=PRIVDEB_BOOT  /boot          ext2    defaults,noatime                   0 2
/dev/mapper/rootfs  /              ext2    defaults,errors=remount-ro,noatime 0 1
proc                /proc          proc    defaults                           0 0
tmpfs               /etc/network/run tmpfs defaults,noatime                   0 0
tmpfs               /tmp           tmpfs   defaults,noatime                   0 0
tmpfs               /var/lock      tmpfs   defaults,noatime                   0 0
tmpfs               /var/log       tmpfs   defaults,noatime                   0 0
tmpfs               /var/run       tmpfs   defaults,noatime                   0 0
tmpfs               /var/tmp       tmpfs   defaults,noatime                   0 0
tmpfs               /home//Scratch tmpfs defaults,noatime               0 0

#Warning:  By mounting /var/log on tmpfs, logs will only be available for the current session.

Mount it all

mount -a

Build sources.list

Create /etc/apt/sources.list

deb http://mirrors.kernel.org/debian/[] sid main non-free contrib
deb-src http://mirrors.kernel.org/debian/[] sid main non-free contrib

deb http://ftp.uk.debian.org/debian-non-US/[] sid non-US/main non-US/non-free non-US/contrib
deb-src http://ftp.uk.debian.org/debian-non-US/[] sid non-US/main non-US/non-free non-US/contrib

# If you are using debian stable (woody) include the security updates.
# deb http://security.debian.org/[] sid/updates main non-free contrib

Note: You can install and use apt-spy to test for the fastest downloading mirrors in your area.

System adjustments

blkid.tab: this file is cached as drives are scanned. Since the scan only takes a few seconds, you dont lose much by not caching or setting the default cache to /dev/null. This file generates an error on boot if the cache file has different device mappings than are currently detected. By removing the cache and forcing a fresh scan every time, the error is eliminated.
```
rm -f /etc/blkid.tab*
ln -s /dev/null /etc/blkid.tab
```
mtab: This file is written a lot and may prematurely age parts of the flash media and the information can simply be accessed from /proc directly.
```
rm -f /etc/mtab
ln -s /proc/mounts /etc/mtab
```
Set Hostname
```
vi /etc/hostname
```
Set /etc/hosts with localhost + hostname
```
vim /etc/hosts
127.0.0.1 localhost.localdoman localhost
```

Install additional required packages

apt-get update
apt-get install cryptsetup dmsetup libdevmapper1.01
apt-get install discover1 libdiscover1
apt-get install module-init-tools equivs cramfsprogs
apt-get clean

Install custom mkinitrd script and equiv package

Create mkinitrd.dmcrypt-usb file in /usr/local/sbin

#!/bin/bash

# Filename:      mkinitrd.dmcrypt-usb
# Maintainer:    Dave Vehrs

# Help
 : << HELP_STEXT
Options:
    -c           Temporary directory to build image in.
    -k           Keep temporary directory used to build image.
    -l    Use  to indenify boot partition.
    -o  Write to outfie
    -d,-m,-r     Included for fake support of default mkinitrd script
                 (anything passed to them is discarded).

See http://www.saout.de/tikiwiki/tiki-index.php?page=USBFlashMedia[] for more info.
HELP_STEXT

function display_shelp {
        echo; echo "Usage $0 [OPTION]...<-o outfile> [version]"
        sed --silent -e '/HELP_STEXT$/,/^HELP_STEXT/p' "$0" | sed -e '/HELP_STEXT/d'
}

# Set defaults
BOOT_LABEL="PRIVDEB_BOOT"
CRAMFSDIR=/tmp/cramfs
keep_temp=0
unset VERSION

# Parse command line.
# if version + other options not specified, exit.
if [ $# -eq 0 ] ; then
    display_shelp
    exit 1
fi

while [ $# -ge 1 ] ; do
        case $1 in
        -c  ) CRAMFSDIR=$2          ; shift ; shift ;;
        -d  ) dir_conf=$2           ; shift ; shift ;;
        -k  ) keep_temp=1           ; shift ;;
        -l  ) BOOT_LABEL=$2         ; shift ; shift ;;
        -m  ) cmd_mkinitrd=$2       ; shift ; shift ;;
        -o  ) outfile_name=$2       ; shift ; shift ;;
        -r  ) initrd_root=$2        ; shift ; shift ;;
                *   ) VERSION=$1            ; shift ;;
        esac
done

# Exit if version not specified
if [ -z "$VERSION" ] ; then
    echo "Error: You need to specify a kernel version to build for."
    exit 1
else
    VERSION=${VERSION##*/}
fi

# Start build...
echo "Build directory tree."
install -d $CRAMFSDIR/{bin,dev/mapper,etc,proc,mnt,sbin}

echo "Copy binaries from /bin."
# Copy /bin binaries over and any require libraries.
files_bin="bash grep mount umount mkdir mknod sed sleep uname"
for file in $files_bin ; do
    install /bin/$file $CRAMFSDIR/bin/$file
    for lib in $( ldd /bin/$file | awk '{print $3}' | grep -v fffe000 ) ; do
        install -d $CRAMFSDIR/${lib%/*}
        install $lib $CRAMFSDIR/$lib
    done
done

echo "Copy binaries from /usr/bin."
# Copy /usr/bin binaries over and any require libraries.
files_usrbin="find mawk"
for file in $files_usrbin ; do
    install /usr/bin/$file $CRAMFSDIR/bin/$file
    for lib in $( ldd /usr/bin/$file | awk '{print $3}' | grep -v fffe000 ); do
        install -d $CRAMFSDIR/${lib%/*}
        install $lib $CRAMFSDIR/$lib
    done
done

echo "Copy binaries from /sbin."
# Copy /sbin binaries over and any require libraries.
files_sbin="cryptsetup e2label modprobe pivot_root"
for file in $files_sbin ; do
    install /sbin/$file $CRAMFSDIR/sbin/$file
    for lib in $( ldd /sbin/$file | awk '{print $3}' | grep -v fffe000 ) ; do
        install -d $CRAMFSDIR/${lib%/*}
        install $lib $CRAMFSDIR/$lib
    done
done

# Add common links
ln -s bash /tmp/cramfs/bin/sh
ln -s mawk /tmp/cramfs/bin/awk

echo "Copy devices over."
# Copy devices over
cp -apL /dev/{console,hd,initrd,null,ram,scd,sd}* $CRAMFSDIR/dev/

echo "Copy modules over."
# Copy modules over
modules="aes-i586 dm-crypt sd_mod sr_mod ehci-hcd uhci-hcd ohci-hcd sl811-hcd usbhid usbkbd usb-storage vesafb fbcon ext2 unix"
for mod in $modules; do
  for ko in $( modprobe --set-version $VERSION --show-depends $mod | cut -b8- ) ; do
    install -d $CRAMFSDIR/${ko%/*}
    install $ko $CRAMFSDIR/$ko
  done
done

cp -apL /lib/modules/$VERSION/modules.* $CRAMFSDIR/lib/modules/$VERSION/

echo "Copy /etc files over."
# Copy required config files over
cp -apr /etc/modprobe.d $CRAMFSDIR/etc/
echo "Copy custom init over."
# Copy custom init file.  (see below)
cat <$CRAMFSDIR/sbin/init
#!/bin/bash

# Filename:      /sbin/init
# Dependencies:  awk, bash, cryptsetup, e2label, find, grep, modprobe
#                mount, pivot_root, sed, sleep and uname.
#
# This file generated by mkinitrd.dmcrypt-usb by Dave Vehrs.
set -e

# Set vars
unset pass part_boot part_rootfs major minor label
dm_name="device-mapper"
dm_dir="mapper"
dir="/dev/\$dm_dir"
control="\$dir/control"
count=0

# Mount /proc
/bin/mount -n -t proc none /proc

# Mount /dev/mapper on tmpfs
/bin/mount -o rw -n -t tmpfs none /dev/mapper

# Modules to load
CORE_MODULES="unix ide-core scsi_mod sd_mod sr_mod mbcache ext2"
DISPLAY_MODULES="vesafb fbcon"
CRYPT_MODULES="aes-i586 dm-mod dm-crypt"
USB_MODULES="ehci-hcd ohci-hcd uhci-hcd sl811-hcd usbcore usbhid usbkbd usb-storage"

# Load Modules
if [ -e /lib/modules/\$(/bin/uname -r) ] ; then
    echo "initrd: loading modules."
    for module in \$DISPLAY_MODULES \$CORE_MODULES \$CRYPT_MODULES \$USB_MODULES ; do
        /bin/find /lib/modules/\$(/bin/uname -r) -name \$module.ko -exec /sbin/modprobe \$module \;
    done
fi

# Test to be sure the procfs is mounted, if not exit.
if [ ! -e /proc/devices ] ; then
    echo "initrd: procfs not found: please create \$control manually."
    exit 1
fi

major=\$(/bin/sed -n 's/^ *\\([0-9]\+\\) \+misc$/\1/p' /proc/devices)
minor=\$(/bin/sed -n "s/^ *\\([0-9]\+\\) \+\$dm_name\\\$/\1/p" /proc/misc)

# Test to be sure dm_mod loaded
if [ -z "\$major" -o -z "\$minor" ] ; then
    echo "initrd: \$dm_name kernel module not loaded: can't create \$control."
    exit 1
fi

# Create new control device.
echo "initrd: creating \$control character device with major:\$major minor:\$minor."
/bin/mknod --mode=600 \$control c \$major \$minor

# Sleep to let kernel finish loading.  15 seconds is enough on most systems.
echo "initrd: sleeping for 15 seconds so kernel can finish detecting devices."
/bin/sleep 5
echo "initrd: sleeping for 10 more seconds..."
/bin/sleep 5
echo "initrd: sleeping for 5 more seconds..."
/bin/sleep 5
echo "initrd: awake...."

# Search for boot partition label.  When usb media is detected by the operating
# system seems to migrate a little depending on what port you connect to on the
# mainboard and what if any other devices are connected and where.  To
# compensate for that, we search for the label on our boot partition.
echo "initrd: searching for boot partition label."
for device in \$( /bin/grep sd[a-h]1 /proc/partitions | /bin/awk '{print \$4}' ) ; do
    label=\$( /sbin/e2label /dev/\$device 2>/dev/null )
    if [ ! -z "\$label" ] ; then
        if [ "\$label" == "$BOOT_LABEL" ] ; then
            part_boot="/dev/\$device"
        break
        fi
    fi
done

# Exit if boot partition not found.
if [ -z "\$part_boot" ] ; then
    echo "initrd: error -- boot partition label not found (\$part_boot)."
    exit 1
fi

# Assign rootfs variable from boot (i.e. if boot is on /dev/sda1, this will
# set part_rootfs to /dev/sda2).
part_rootfs=\$( echo \$part_boot | /bin/sed -e 's/1/2/' )

# Unmount /proc
/bin/umount /proc

# Prompt for password
echo -en "\\nplease enter password for rootfs filesystem: "
read -s pass
echo -e

# Attempt mounting
echo "initrd: attempting to mount rootfs."
echo \$pass | /sbin/cryptsetup create rootfs \$part_rootfs
/bin/mount -r -n -t ext2 /dev/mapper/rootfs /mnt

# Loop for bad password attempts
while [ \$? -ne 0  ] ; do
    # Remove old crypt mount.
    /sbin/cryptsetup remove rootfs

    # Test for max tries.
    if [ \$count -ge 5 ] ; then
        echo -e "\\ninitrd: too many bad guesses.  aborting."
        exit 1
    else
        count=\$(( \$count + 1 ))
    fi

    # Reprompt for password
    echo -e "\\ninitrd: error -- rootfs mount failed."
    echo -n "please re-enter password: "
    read -s pass
    echo

    # Reattempt mounting
    echo \$pass | /sbin/cryptsetup create rootfs \$part_rootfs
    /bin/mount -r -n -t ext2 /dev/mapper/rootfs /mnt
done

unset pass

echo "initrd: rootfs successfully mounted."

# Now that the encrypted media is readable, shift the root to it and continue
# the boot cycle by running its init.
cd /mnt
/sbin/pivot_root . initrd
exec /usr/sbin/chroot . /sbin/init
EOF
chown root:root $CRAMFSDIR/sbin/init
chmod 755 $CRAMFSDIR/sbin/init

# make cramfs file
if [ -z "$outfile_name" ] ; then
    mkcramfs $CRAMFSDIR ./initrd-$VERSION.img
else
    mkcramfs $CRAMFSDIR $outfile_name
fi

# Cleanup
if [ $keep_temp -eq 0 ] ; then
    rm -rf $CRAMFSDIR
fi

Set permissions, and links.

chown root.root /usr/local/sbin/mkinitrd.dmcrypt-usb
chmod 750 /usr/local/sbin/mkinitrd.dmcrypt-usb
ln -s /usr/local/sbin/mkinitrd.dmcrypt-usb /usr/sbin/mkinitrd

Next we need to install an equivs package to let the package system know that we installed this ourselves and not to install initrd-tools

cd /tmp
equivs-control initrd-tools

Edit the generated template so that it looks like:

Section: misc
Priority: optional
Standards-Version:

Package: initrd-tools

Build equivs package

equivs-build initrd-tools

Install the package

dpkg -i initrd-tools_1.0_all.deb

For more information about equivs, see the APT howto at: APT-Howto: Equivs

Remove unwanted locales

Be very careful configuring and running localepurge. It is very easy to delete too many locales. For more information about localepurge, see the APT howto at: APT-Howto: localepurge
```
apt-get install localepurge
localepurge
apt-get clean
```

Install kernel

Kernels prior to 2.6.10 had a bug in the dm_crypt modules that potentially could reveal data. Only use 2.6.10 or better.

apt-get install kernel-image-2.6.11-1-686
apt-get clean

Install size is approximately 184MB now. If you want to install a kernel built from source you can. After you install it, run /sbin/mkinitrd to build the /boot/initrd file. When you run /sbin/mkinitrd, it may print several FATAL errors regarding modules that it cannot find. If you built these modules into the kernel then you can ignore the error messages. If you omitted the modules, this is your warning to go build them as modules or into the kernel. Required modules: dm_crypt, aes, ide_core, scsi_mod, sd_mod, ehci-hcd, ohci-hcd, uhci-hcd, sl811-hcd, usb-storage, usb-hid, dm_mod, cramfs

Install optional packages

apt-get install vim irsii-text mutt fetchmail antiword screen
apt-get install exuberant-ctags less procmail
apt-get install python2.3 python2.3-pexpect python2.3-fuse
apt-get install xserver-common xserver-xfree86 xbase-clients xfree86-common
apt-get install ion3 -or- blackbox -or- fluxbox -or- icewm
apt-get install xterm
apt-get install memtest86+

Note: All this is approximately 300mb installed (with dependencies).

Install grub

apt-get install grub
grub-install /dev/sdd
mkdir /boot/grub
grub
 root (hd1,0)
 setup (hd1)
 quit

Create /boot/grub/menu.lst file

# default num
default         0

# timeout sec
timeout         5

# pretty colours
color green/black black/green

title   Debian GNU/Linux-2.6.11-1-686
root    (hd0,0)
kernel  /vmlinuz-2.6.11-1-686 root=/dev/ram0 init=/sbin/init vga=794
initrd  /initrd.img-2.6.11-1-686
savedefault
boot

title   Debian GNU/Linux-2.6.11-1-686 (Rescue/Single)
root    (hd0,0)
kernel  /vmlinuz-2.6.11-1-686 root=/dev/ram0 init=/sbin/init single
initrd  /initrd.img-2.6.11-1-686
boot

title   Memtest86+
root    (hd0,0)
kernel  /memtest86+.bin
boot

Add User accounts

Either:

Copy an existing /etc/group, /etc/passwd, and /etc/shadow file over from another system (this has to be done from outside the chroot directory).

Or:

Add users locally.
1. set root password
```
passwd root
```
2. add local user
```
useradd
passwd
```
3. repeat step 2 as necessary
Exit Jail
```
umount -a
umount /proc
exit
```

Unmount and remove crypt mapping

cd
umount /mnt/buildroot/
cryptsetup remove rootfs

Reboot to test media
```
shutdown -r now
```

MOUNTING ON ANOTHER LINUX SYSTEM

Make sure required modules are loaded.

modprobe dm_crypt
modprobe aes-i586  (or aes)
modprobe usb-storage

Insert USB key into port

Create device mapping and mount

cryptsetup create rootfs /dev/sdd2
mount /dev/mapper/rootfs /mnt/buildroot

documented on: 2007.01.12

Crucial's Gizmo! Thumb Drive Linux Tested

http://www.linuxhardware.org/article.pl?sid=03/09/18/0357222&mode=thread

posted by augustus on Thu Sep 18, '03 from the Pocket-Memory dept.

Many readers have requested reviews of useful gadgets for Linux and we're here to accommodate them. So it seems like floppies are quickly on their way out, there has to be something to fill the void for easy to use removable media. This is where the not-so-new thumb drives come in. Not familiar with thumb drives or want to know how they work with Linux, then read on. Today we review The Gizmo! USB Flash Drive from Crucial Technology.

The Device

A thumb drive is a small storage device that is a little larger than a key that contains a flash chip and a micro-controller. These devices range in size from about 16MB to 1GB. The great thing about most of these devices is that they require minimal drivers that come with all modern OSes. Even Linux has the base support for these drives in the standard kernel tree. They bring new meaning to Plug-and-Play and hopefully will usher in the end of the floppy disk. With the right BIOS, USB thumb drives can even be booted off of. This can be great for rescue devices or for a quick BIOS flash without a floppy.

Our thumb drive is manufactured by Crucial Technology and goes by the name of Gizmo!. It is a USB 1.1 device which can operate at a maximum of 12Mbps (megabits per second) or 1.5MBps (megabytes per second). The Gizmo! drive comes in 64MB, 128MB, and 256MB sizes. As shown in the photo above, the drive comes with a handy wrist strap and folded operating manual which will help you get the drive going under most versions of Microsoft Windows and MacOS 9.1 and up.

Getting It Up and Running

Getting the Gizmo! up and running was extremely easy and only required a kernel recompile under Gentoo. Most distributions that come with pre-compiled kernels won't even need this much work. All that is required for operation is the proper USB drivers for your motherboard, the USB mass storage driver, and VFAT filesystem support if you plan to use it with other OSes. For the USB mass storage driver to function, you will also need to enable SCSI support with SCSI disk support and SCSI generic support. Once we recompiled the kernel with these options, all that we needed to do was to add a line to our /etc/fstab file so that mounting the drive would be convenient. Here's the line we added:

/dev/sdb1     /mnt/usbdrive     auto     noauto,user     0     0

In this line, the drive is our second SCSI drive and we plan to mount it to the /mnt/usbdrive directory. We also have mount auto-detecting the filesystem type and we allow users to mount the device with default mount options. Now with a simple call to mount /dev/usbdrive, the drive can be mounted and ready to go.

Upon inserting the drive into a vacant USB port, you will see the following message in your logs or by typing dmesg:

hub.c: new USB device 00:1d.1-1, assigned address 2
scsi3 : SCSI emulation for USB Mass Storage devices
  Vendor: CRUCIAL   Model: USB DRIVE         Rev: 1.10
  Type:   Direct-Access                      ANSI SCSI revision: 02
Attached scsi removable disk sdb at scsi3, channel 0, id 0, lun 0
SCSI device sdb: 125952 512-byte hdwr sectors (64 MB)
sdb: Write Protect is off
 /dev/scsi/host3/bus0/target0/lun0: p1
WARNING: USB Mass Storage data integrity not assured
USB Mass Storage device found at 2

This message will tell you which SCSI device it is (sda, sdb, …) and how big the device is. As you can see from our output, we have a 64MB Gizmo! inserted as SCSI drive sdb. The line WARNING: USB Mass Storage data integrity not assured is simply stating that if you pull the plug on the drive without unmounting it, you could lose your data. This is important as Linux will cache data before writing to the disk. If you yank it without unmounting it, you could have data that has not been written yet.

Performance

The next question we had was about the performance of the drive. Being a USB 1.1 device we weren't expecting anything phenomenal, but we did want to make sure that we could perform normal tasks off of the drive without issue. In measuring driver performance we decided first to write a file of known size with an immediate unmount to write it and then to cat the same file to /dev/null and record the times. The file we used was a movie trailer that was exactly 34,266,862 bytes. To write the file it took an average of 50.803 seconds and to read the file it took an average of 53.357 seconds. The yields about 658 KB/s write speed and about 627 KB/s read speed. For a second opinion we turned to hdparm -t /dev/sdb which returned a read speed of 809.49 KB/s for a much smaller 4MB piece of data. Either way, that's not too slow for something that is designed to take the place of an incredibly slow floppy drive. At that speed we were even able to watch the video directly from the key drive without a glitch. The only time that the speed would really get annoying is if you bought one of the larger versions and planned on writing the entire drive at once on a regular basis. Around a four minute write for the 256MB drive would be a little time consuming.

Long Term Usage and Conclusions

One concern for many will be how well the drive holds up if carried around in a pocket with keys, cell phones, and other such bulky and potentially damaging items. The best way we found to test this abuse was by actually doing just that. I've been carrying this around in my pocket now for around four months on and off and it's still in one piece minus a small plastic clip that was attached to the wrist strap. The clip was a minor casualty as the rest of the drive has held up amazing well without barely a scratch. I've exposed it to many writes, reads, plugs, and unplugs and it still works like a champ. In fact, for the the past several articles, I have even worked off of this drive.

As far as long term usage and reliability is concerned we highly recommend this drive. The speed is so-so though so you may need to be patient if large writes are in your future for a portable device. The price of the Gizmo!s are only $33.99, $51.99, and $79.99 for the 64MB, 128MB, and 256MB drives respectively. Also, if you spend over $35 or more at Crucial, you'll get free 2-day shipping in the contiguous US. Not a bad deal for what you get. We see these drives as the future of quick and easy portable storage and Crucial has a great solution. The only thing that may hold you back would be faster USB 2.0 versions of these drives but at these prices you can probably just buy another one later. For a great product that works well with Linux, Crucial's Gizmo! drive takes home the Works with Linux Certification.

documented on: 2005.12.19

PNY Attache 64Mg USB pen drive

http://www.linuxquestions.org/hcl/showproduct.php/product/952/sort/2/cat/myprod/page/1

My GF bought this for me as a b-day present. My boxen have a number of USB ports, but until now, I've never used them. This pen drive (aka thumb drive) is a very handy USB stick wth 64Mg of storage, and it makes transferring relatively big files between boxes a piece of cake. Heck, there's nothing cooler than downloading the kernel once and copying to the thumb drive and loading it up onto a new machine. It even has a read-only lock on it, just like a floppy.

Note: this device lives at /dev/sda1 which took me a while to figure out.