Better USB Formatting

Out of the package USB sticks, USB flash memory, and other USB storage drives typically come formatted with the FAT file system, actually FAT32. The original File Allocation Table system format — first came an 8-bit format, then FAT12, then FAT16 — dates back to the late 1970s, designed to store files on the slow, small capacity floppy disks of the time. Due to the popularity of MS-DOS and early versions of Windows, FAT became so widely used that it is now considered the most transportable file system format between differing operating systems.

Lately, its limits get in the way. The most annoying limit is the largest file size allowed. Each FAT file is limited to 4 GiB (4,294,967,295 bytes) max. That interferes with modern video files and archives. (Compare other file systems for more info.)

Windows can only read its own file system formats, most commonly FAT variants and NTFS. Mac reads HFS+ and the new Apple File System (APFS or directly). Except for the new APFS, Linux reads and writes most commonly used file system formats and may one day add APFS to that list. Linux’s variety of support allows for greater storage portability trading off efficiency and effectiveness needed for the storage unit.

Various utilities exist for formatting file systems, some GUI (Graphic User Interface), others CLI (Command Line Interface). Use what is convenient, but typically CLI programs in a terminal shell give the most flexibility.

File System Type

This article uses a Linux system to do the work because Linux systems can read and write most filesystem types. Before starting, determine which file system is on your USB storage. Plug it in to your Linux system and start querying it. Use

$ sudo fdisk -l

on the command line to list all known file systems. Using sudo is required because device manipulation commands need system administrator access. “root” is the sysadmin account. Applying the sudo prefix to root commands is the safe way.

Note: Plugging in a USB stick to a Qubes system automatically attaches it to dom0 — the domain from which all other virtual machines derive. A little popup notifies when dom0 mounts the device and identifies its device name, such as /dev/sdb, and any partitions it finds, such as /dev/sdb1. When pulling the device from dom0 later, it tells you both device and partition names were detached.

But, you don’t get access on dom0. Such access could be a security problem. Maybe it’s an infected device. Mounting on dom0 could infect the whole system including all the VMs. Even the dom0 mounting option in the menu is grayed out. You’d have to force it from the command line.

Prove it: Plug a stick in, but don’t attach it to any VM. Open a dom0 terminal and run

$ sudo fdisk -l

That USB storage’s entry probably comes last in the list. No other indication shows that dom0 knows about it. It does not appear in dom0’s “df -h” list.

When dom0 sees the USB stick, attach it to the VM you want to use it by right-clicking on that VM’s entry in the Qubes VM Manager. If you’re unsure of the device’s security status, attach it to a disposable VM.

It still needs mounting on the VM to use it. Open the Files app in the mounting VM and look for the stick’s label name. It typically appears in the “Other Locations” list. Click on it to mount it. An eject icon will appear on the right if it’s already mounted. Other apps may mount the stick for its own purposes, such as e-mail attachment saving.

Don’t forget to unmount a USB stick from its VM before detaching it. Typically, open the VM’s Files app. Find its name in “Other Locations” and click on the eject icon.

If you do forget to unmount the stick before unplugging it, its device designation remains allocated until the next reboot.

An fdisk(8) report looks like this:

$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 989.6 MiB, 1037615104 bytes, 2026592 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xc3072e18

Device     Boot Start     End Sectors   Size Id Type
/dev/sdb1          32 2026591 2026560 989.5M  c W95 FAT32 (LBA)

The first lines show size and layout characteristics. Notice that the disk device name is /dev/sdb but the partition name includes a number, such as /dev/sdb1 in this example. Distinguishing between devicename, the whole thing, and partitionname, one part, is important.

After the device description lines comes the partition table. This example mounted on /dev/sdb1 — read it as from the root directory, in the device directory, the SCSI driver, disk “b”, partition “1”. It is not a bootable partition. It starts at sector 32, ends at sector 2,026,591 for a total of 2,026,560 sectors, giving a size of 2026560 * 512 / 1024^2 = 989.5M (M is MiB and G is GiB, but sometimes not — welcome to the real world), using type identifier “c”, which is the type of Windows 95 using FAT32 with Logical Block Addressing.

This example’s physical disk capacity is 989.6 MiB, a binary measurement, but the byte count is over one billion, therefore 1GB. Beware.

Communication and Storage Measurements

Measurements of network transmission and disk drive capacities use decimal (SI) units, always in groups of 1,000s, because 10^3=1,000. Memory measurements use binary (IEC) units, always in groups of 1,024s because 2^10=1,024. The manufacturer lists an example stick as a 1GB capacity because it has 1,037,615,104 bytes capacity. That 1GB size is based on decimal SI units:

1KB = 1000^1, 1MB = 1000^2, 1GB = 1000^3

not on binary IEC units:

1KiB = 2^10, 1MiB = 2^20, 1GiB = 2^30

The Files GUI app also shows the device name. In a Qubes VM example, this stick is /dev/xvdi1:

$ sudo fdisk -l /dev/xvdi
Disk /dev/xvdi: 7.5 GiB, 8053063680 bytes, 15728640 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x020e6c95

Device     Boot Start     End Sectors  Size Id Type
/dev/xvdi1 *        0 8294399 8294400    4G  0 Empty
/dev/xvdi2        968   63923   62956 30.8M ef EFI (FAT-12/16/32)

This example shows an 8 GB stick with two partitions, the first one bootable with a 4G capacity but an empty type — a place holder. The second is an EFI partition with a 30.8M capacity. This stick was created by writing the Qubes R3.2 installation ISO file onto the 8 GB stick for installing Qubes onto a system. Notice that the combined partition sizes do not add up to 8G. Laying ISO files onto USB sticks can leave some capacity unused. In this case, nearly half the stick remains unallocated and even the 4G partition is empty. The unused space is available, but the ISO doesn’t use it.

Here’s another example of a 64 GB stick:

$ sudo fdisk -l /dev/xvdi
Disk /dev/xvdi: 60 GiB, 64424509440 bytes, 125829120 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000e93e7

Device     Boot Start       End   Sectors Size Id Type
/dev/xvdi1       2048 125829119 125827072  60G  7 HPFS/NTFS/exFAT

Only capable of 60 GiB storage, it’s formatted with NTFS to transfer files between Windows systems. After mounting it, df — the disk free command — shows this stick is empty:

$ df -h /dev/xvdi1
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvdi1       60G  136M   60G   1% /run/media/user/LexarNTFS

The used 136M belongs to NTFS file system internals. The “Mounted on” entry (mountpoint) is the path used to access the data on the partition.

Notice on the last two command lines:

  • fdisk uses the device name (/dev/xvdi)
  • df uses the partition name (/dev/xvdi1)
  • df also shows the mountpoint name (/run/media/user/LexarNTFS)

The manufacturer calls the following USB stick a 128 GB capacity using SI notation, but it holds only slightly more than 119 GiB using IEC notation.

$ sudo fdisk -l /dev/xvdi
Disk /dev/xvdi: 119.2 GiB, 128035323904 bytes, 250068992 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000da3ea

Device     Boot Start       End   Sectors   Size Id Type
/dev/xvdi1 *     2048 250068991 250066944 119.2G 83 Linux

Formatted for Linux, this could use any of the ext file system types. Windows cannot read this format. It would think the disk is unformatted and would ask to format it. Here’s what df sees:

$ df -h /dev/xvdi1
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvdi1      118G   60M  112G   1% /run/media/user/LexarExt

Notice the labels on this ext stick and the previous NTFS stick. Identifying the manufacturer name and the format type on the label helps to know what it uses whenever it’s plugged in.

Partitioning the USB Stick

Plug the stick in, mount it, check the partition type. Before reformatting a USB stick or drive, save any data you care about. Partitioning will destroy that data.

$ sudo fdisk -l /dev/xvdi
Disk /dev/xvdi: 30.5 GiB, 32717537280 bytes, 63901440 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x78285dae

Device     Boot Start      End  Sectors  Size Id Type
/dev/xvdi1 *     2048 63901439 63899392 30.5G  c W95 FAT32 (LBA)

This 32 GB stick is formatted FAT and flagged as bootable.

$ df -h /dev/xvdi1
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvdi1       31G  1.4G   30G   5% /run/media/user/LIVE

It already contains data amounting to 1.4 GB. The label name “LIVE” becomes the mountpoint name. Transient file systems in Fedora Linux mount in a subdirectory named for the user and the disk label. This stick was previously used to boot a live version of Fedora for testing and installing. No data needs preserving.

Before partitioning and formatting, unmount the stick either with the Files app or with the umount command. Hardware queries of the stick, like fdisk, will still see the device.

On the command line, run cfdisk(8). The cfdisk app is a variation on fdisk using curses, a GUI-like software for cursor manipulation in a text terminal.

Launch cfdisk using the devicename without the number (/dev/xvdi), not the partitionname with the number:

$ sudo cfdisk /dev/xvdi

                           Disk: /dev/xvdi
          Size: 30.5 GiB, 32717537280 bytes, 63901440 sectors
                   Label: dos, identifier: 0x78285dae

    Device       Boot     Start        End   Sectors   Size  Id Type
>>  /dev/xvdi1   *         2048   63901439  63899392  30.5G   c W95 FAT32 (LBA) 


 ┌────────────────────────────────────────────────────────────────────────────┐
 │  Partition type: W95 FAT32 (LBA) (c)                                       │
 │      Attributes: 80                                                        │
 │      Filesystem: vfat                                                      │
 │Filesystem label: LIVE                                                      │
 │ Filesystem UUID: C111-F8D8                                                 │
 └────────────────────────────────────────────────────────────────────────────┘
     [Bootable]  [ Delete ]  [  Quit  ]  [  Type  ]  [  Help  ]  [  Write ]
     [  Dump  ]

                  Quit program without writing partition table

Note: vfat (Virtual FAT) is the FAT variation using long file names.

Although the /dev/xvdi1 partition was unmounted, the /dev/xvdi device is still known to the system. Use cfdisk to manipulate it.

Forget to umount it? cfdisk adds a line to its information list:

 ┌────────────────────────────────────────────────────────────────────────────┐
 │  Partition type: W95 FAT32 (LBA) (c)                                       │
 │      Attributes: 80                                                        │
 │      Filesystem: vfat                                                      │
 │Filesystem label: LIVE                                                      │
 │ Filesystem UUID: C111-F8D8                                                 │
 │      Mountpoint: /run/media/user/LIVE (mounted)                            │
 └────────────────────────────────────────────────────────────────────────────┘

Notice the “Mountpoint” line. If you see the “(mounted)” message, quit the program immediately. Unmount the partition on the command line:

$ umount /dev/xvdi1

Rerun cfdisk. The “Mountpoint” line will be gone. Never do partitioning operations on a partition. Do them on the whole device.

At the top, lines displayed contain similar info to what fdisk -l showed. The partition table displays below them. This example has only one partition. Double greater-than symbols (>>) point like arrowheads to the currently selected partition. This helps with disks having multiple partitions. Current partition settings appear in the info rectangle below the partition list. Under the rectangle comes a menu with bracketed selections. A highlight shows the current selection. Move the highlight with left-arrow or right-arrow keys. A description of the selected menu item shows at the bottom.

To delete partitions, select the partition with the up-arrow or down-arrow, move the highlight to “Delete” and press ENTER or press d. “Free space” will appear in the partition list. Delete all partitions if you have more than one. When done, the partition list will look like this:

    Device        Boot       Start         End    Sectors    Size   Id Type
>>  Free space                2048    63901439   63899392   30.5G

and the rectangle below will look like this:

 ┌────────────────────────────────────────────────────────────────────────────┐
 │      Filesystem: vfat                                                      │
 │Filesystem label: LIVE                                                      │
 │ Filesystem UUID: C111-F8D8                                                 │
 └────────────────────────────────────────────────────────────────────────────┘

After deleting all partitions, the menu changes to show the “New” option. This option creates a new partition. Press ENTER when the “New” option is highlighted or press n to create a new partition. A prompt for the “Partition size” appears, suggesting to use all currently available free space. You don’t have to use all of it, especially if you want multiple partitions. If the size prompted is correct, press ENTER to use it.

If you set the “Partition size” number to a smaller value than prompted, remaining space is available for another partition. For example, I partitioned a 1 TB USB drive into two partitions, one 400 GB as NTFS to hold Windows backup, and a second using all remaining space as Linux to hold Linux backups.

Note: Windows only sees the NTFS partitions. Linux sees all partitions.

A partition may be Primary or Extended. Create up to four primary partitions when using the Master Boot Record (MBR) type of disk. Extended partitions create logical partitions rather than physical ones. An extended partition sets aside space for logical volumes to fill later. Generally, create Primary partitions.

Note: Using EFI or UEFI allows a GUID Partition Table (GPT) to have up to 128 partitions. Use gdisk(8), cgdisk(8), or sgdisk(8) for GPT.

After creating the Primary partition and using all the space, the partition table looks like this:

   Device        Boot       Start         End    Sectors    Size    Id Type
>> /dev/xvdi1                2048    63901439   63899392   30.5G    83 Linux

Notice the ID is 83 (a hexadecimal number) and the Type is Linux. Linux Type offers the ext family type by default, just as Windows defaults to FAT32.

Change the type by selecting the “Type” menu option or press t. A long list of partition types appears with one entry highlighted. Scroll through the list using up-arrow/down-arrow or PgUp/PgDn or even Home/End keys. Highlight the type to use and press ENTER.

For highly compatible file transporting with FAT, use FAT32 (type “c”), the LBA (Logical Block Addressing) variation. For any of the Linux ext file system types, use type 83. Use type 7 for Windows (HPFS/NTFS/exFAT).

To prepare the stick for an OS installation ISO, you may have to select the type according to that OS’s specifications, typically FAT. Most often laying an ISO on a stick overwrites the partitioning with whatever is in the ISO file.

Mark the MBR for booting by selecting the “Bootable” option in the menu or press b. This option is a toggle so, if it’s off, b turns it on and another b turns it off again.

When all partitions and types are done and the bootable flag is set, write it to the stick. Up until this step nothing changed on the stick. Everything happened in memory. Quit the program or use the ESC key at any time and nothing changes. That’s how to start over if you change your mind.

Don’t write until you’re sure!

Write is destructive. Pressing w does not select it in the menu. You must move the highlight over and press ENTER when “Write” is highlighted. When pressed, just to be safe, an “Are you sure” prompt appears. It makes you type out “yes” or “no”. When it’s finished, you can quit.

Encrypt the Entire Partition

USB drives are portable. Could someone just swipe it? If so, your data is now out there.

Want secure data stored on the USB drive? Encrypt the whole partition with a good passphrase. Every file stored on that partition will be available only to someone who knows the passphrase.

LUKS (Linux Unified Key Setup) encrypts the entire partition before formatting so all data ever written automatically encrypts on the way to it and automatically decrypts on the way to you. Mounting that partition requires the passphrase. Don’t have it? Can’t mount it. Therefore, the passphrase better be good.

Note: For LUKS support on Windows, Bruce Schneier had suggestions (or direct) a couple years ago that may not be relevant now. Better to investigate LibreCrypt,which shows relatively recent updating.

Wipe the unmounted disk partition preparing for LUKS:

$ sudo sh -c "pv /dev/zero >/dev/partitionname"

Because redirection does not work under sudo operation, the pv(1) command line must run in a sudo‘d subshell. The pv command (pipe view) using /dev/zero writes binary zero bytes over the entire partition. It shows the progress report that an equivalent dd(1) or cat(1) will not show. Writing stops when it runs out of partition space. Here’s the finished command output for a 1G USB2 stick partitioned for ext:

$ time sudo sh -c "pv /dev/zero >/dev/xvdi1"
951MiB 0:06:07 [2.42MiB/s] [================================> ] 99% ETA 0:00:00
pv: write failed: No space left on device

real 6m30.854s
user 0m0.171s
sys 0m2.669s

The difference between the example 6m07s it took to write the data and the ~6m31s real time reported was the time it took to flush the last data to the device.

Using /dev/urandom, or worse, /dev/random, instead of /dev/zero is possible, but the system may lack entropy to produce quality pseudorandom numbers. Using /dev/random is worse only because it produces greater quality pseudorandom numbers at the sacrifice of time, waiting as long as needed for the missing entropy to come along. Moving the mouse around aimlessly to generate entropy is just annoying. Writing zero bytes is sufficient for all but the highest possible security.

Use cryptsetup(8) to prepare LUKS:

$ sudo cryptsetup luksFormat /dev/PARTITIONNAME

When prompted, type “YES” (all caps). Anything else will quit with an error code 22. Give a good passphrase. Twice. (See my Passwords article.)

When finished, you may want to use the cryptsetup luksDump option to see what the header info looks like. Here’s an example:

$ sudo cryptsetup luksDump /dev/xvdi1
LUKS header information for /dev/xvdi1

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha256
Payload offset: 4096
MK bits:        256
MK digest:      15 ee 68 b0 7b 67 9e 62 e1 35 6c 2b 15 d9 e2 10 ac 82 c0 2c 
MK salt:        9b 6b d5 08 78 16 5e 6b 54 26 6b ed 24 d4 5e a5 
                96 0c 03 30 17 71 19 e7 27 39 b6 14 d5 36 c7 bb 
MK iterations:  138250
UUID:           801946f4-3318-4102-87fb-5f220f16366c

Key Slot 0: ENABLED
        Iterations:             1187933
        Salt:                   1a 12 a2 26 79 e1 83 88 c2 a7 2a 56 67 f8 fa 5a 
                                68 a3 08 7a fb 73 95 44 c0 c7 41 13 83 f7 af 3d 
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Then, map (mount) the device onto /dev/mapper:

$ sudo cryptsetup open /dev/partitionname mapname

where mapname is any name you choose that will become the /dev/mapper/mapname reference for other commands. Here’s an example:

$ sudo cryptsetup open /dev/xvdi1 TestExt
Enter passphrase for /dev/xvdi1:

$ ls -oh /dev/mapper/
total 0
crw------- 1 root 10, 236 Feb 15 19:52 control
brw-rw---- 1 root 251, 0 Feb 15 19:52 dmroot
lrwxrwxrwx 1 root 7 Feb 17 10:11 TestExt -> ../dm-1

$ ls -oh /dev/dm-1
brw-rw---- 1 root 251, 1 Feb 17 10:11 /dev/dm-1

After giving the passphrase, checking /dev/mapper shows that the mapname, TextExt, is a symbolic link in /dev/mapper, actually using the devicename dm-1. Listing /dev/dm-1 shows the block device.

When formatting the LUKS partition (see next section), use the mapname instead of the devicename.

Format the Partitions

After partitioning, format. When creating more than one partition, format each separately for the file system types used. If the partition is already formatted and mounted, to find out what type is on it, the Linux mount(8) command will show the format type name.

Any user can run mount to query the mounts, but only root can mount a device, not counting automounting. For example, my dual partitioned 1 TB backup drive, not using LUKS, attached to my Fedora Linux system by USB shows two mountpoints:

$ mount
[...]

/dev/sdb1 on /run/media/user/BACKUP-NTFS type fuseblk
(rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,
allow_other,blksize=4096,uhelper=udisks2)

/dev/sdb2 on /run/media/user/BACKUP-EXT3 type ext3
(rw,nosuid,nodev,relatime,seclabel,data=ordered,uhelper=udisks2)

[...]

In this example, /dev/sdb1 sees two partitions mounted, one of type fuseblk (a Filesystem in USErspace block device), which is how mount sees an NTFS partition, and /dev/sdb2 is ext3 type.

Another approach to see the file system uses the file(1) command:

$ sudo file -sL /dev/sdb*

/dev/sdb: DOS/MBR boot sector; partition 1 : ID=0x7, start-CHS
(0x0,32,33), end-CHS (0x222,17,19), startsector 2048, 838860800
sectors; partition 2 : ID=0x83, start-CHS (0x222,17,20), end-CHS
(0x362,77,63), startsector 838862848, 1114662320 sectors

/dev/sdb1: DOS/MBR boot sector, code offset 0x52+2, OEM-ID "NTFS
", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63,
heads 255, hidden sectors 2048, dos < 4.0 BootSector (0x80), FAT
(1Y bit by descriptor); NTFS, sectors/track 63, sectors 838860799,
$MFT start cluster 4, $MFTMirror start cluster 52428799,
bytes/RecordSegment 2^(-1*246), clusters/index block 1, serial
number 01a4b5f624f070163

/dev/sdb2: Linux rev 1.0 ext3 filesystem data,
UUID=24ce4998-2485-4621-bc63-af3bcc6036b4, volume name
"BACKUP-EXT3" (needs journal recovery) (errors) (large files)

Because the -s option reads the device, not the mountpoint, root must run it, so it needs a sudo. The -L option follows symbolic links. This shows the primary device (the /dev/sdb line) to reveal facts about the boot sector and it shows the two mounted partitions. With this command, the first partition correctly identifies as NTFS. The quoted name shows the full eight-character ID. The second partition is ext3.

Apply the following instructions according to the different file system types.

FAT Partitions:

(Skip this step if using LUKS.) Zero out the FAT boot sector (512 bytes) to maintain compatibility with certain data requirements where partitionname states which partition to zero out, such as xvdi1 or sdb1:

$ sudo dd if=/dev/zero of=/dev/partitionname bs=512 count=1

If using LUKS, use /dev/mapper/mapname, not /dev/partitionname.

Format the FAT partition using the -F 32 option specifies the FAT size (older 12 and 16 settings exist if you insist), the usblabel is the volume name that cannot exceed 11 characters:

$ sudo mkfs.fat -F 32 -n usblabel /dev/partitionname

NTFS Partitions:

If using LUKS, use /dev/mapper/mapname, not /dev/partitionname.

Format an NTFS partition:

$ sudo mkfs.ntfs -Q -L usblabel /dev/partitionname

Linux Partitions:

If using LUKS, use /dev/mapper/mapname, not /dev/partitionname.

Format the ext3 partition:

$ sudo mkfs.ext3 -L usblabel /dev/partitionname

For a LUKS example:

$ time sudo mkfs.ext3 -L TestEXT3 /dev/mapper/TestExt 
mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 243328 4k blocks and 60928 inodes
Filesystem UUID: 5fc1dccd-527d-41b5-86e0-70f00dce4a0c
Superblock backups stored on blocks: 
32768, 98304, 163840, 229376

Allocating group tables: done 
Writing inode tables: done 
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done


real 0m14.079s
user 0m0.017s
sys 0m0.151s

Reduce excess writing to USB sticks:

$ sudo tune2fs -c0 -i0 /dev/partitionname

For a LUKS example:

$ sudo tune2fs -c0 -i0 /dev/mapper/TestExt 
tune2fs 1.42.13 (17-May-2015)
Setting maximal mount count to -1
Setting interval between checks to 0 seconds

This command kills fsck(8) actions on the USB stick.

Using mkfs.ext2 is the older Linux file system that does not use a journal for file safety. Use, mkfs.ext3 or mkfs.ext4 to create a journal that enhances file consistency.

Be careful: The journal causes more writes to the device. Too many writes to a USB memory stick can burn it out. They only have so many Write/Erase cycles. Reads are not as limited as writes. While using ext2 to avoid extra writes is a good argument for a longer USB memory stick lifetime, people too often accidentally pull USB sticks out before umount. The journal helps protect file damage. Keep separate copies of important data stored on USB sticks because they last about 10 years, maybe more, according to use.

When formatting finishes, if using LUKS, use the mapname only, not the partitionname. Close it with the command:

$ sudo cryptsetup luksClose mapname

All Done

On Linux systems, when the formatting is finished, pull the USB stick. Remember, the stick is already unmounted, so pulling it out leaves no filesystem information behind.

Note: On Qubes, detach the device from dom0 before pulling it. Qubes typically requires a few steps for security to remove a block device. If you remount it to check it, don’t forget to unmount it before detaching it. Qubes takes great care about attaching and detaching block devices to and from VMs. Plugging a USB stick in delivers the device to dom0, but dom0 doesn’t mount it.

A popup appears announcing that the Qubes VM Manager attached a new device to dom0. One popup shows the devicename (/dev/sdb), and others give the partitionnames (/dev/sdb1, /dev/sdb2, …).

In the VM Manager, right click on the Application VM (AppVM) you want to use the block device on and a menu appears. Hover over the Attach/Detach menu item and a submenu will show the block devices currently available. Next to each device is a green plus sign (attach) or a red minus sign (detach) with the device’s capacity and label. Pick the block device and attach it.

A small disk icon will appear on the AppVM’s line in the VM Manager. That device now appears in any application that can refer to files, such as saving an e-mail attachment or in the Files manager. Other apps cannot see it until it’s mounted. Mount it in the AppVM’s Files manager, use it in your apps, and then unmount it in the Files manager.

After unmounting it, use the VM Manager to detach it. The little disk icon will disappear. Then, either pull the stick from your USB socket or attach it to a different AppVM if that’s safe.

Checking LUKS

Mounting a LUKS stick on Linux systems will prompt for the password.

Note: On Qubes, simply attaching it to an Application VM (AppVM) will not prompt for the password. Password prompting happens when you try to mount it, such as selecting it in the Files app. Selecting it will prompt for the password, then mount it.

The two filesystem type checking commands don’t show a LUKS type before the partitioning commands run. They work when mounted after it’s formatted:

$ mount | egrep mapper
/dev/mapper/dmroot on / type ext4 (rw,noatime,data=ordered)
/dev/mapper/luks-3e30affb-adbb-47b0-8676-771fb9718561 on
/run/media/user/TestEXT3 type ext3
(rw,nosuid,nodev,relatime,data=ordered,uhelper=udisks2)

$ sudo file -sL /dev/dm-1
/dev/dm-1: Linux rev 1.0 ext3 filesystem data,
UUID=5fc1dccd-527d-41b5-86e0-70f00dce4a0c, volume name "TestEXT3"
(needs journal recovery) (large files)

The file command’s “needs journal recovery” error means that the filesystem needs a cleanup operation. Run e2fsck(8) as follows:

$ time sudo e2fsck -y /dev/dm-1
e2fsck 1.42.13 (17-May-2015)
TestEXT3: clean, 11/60928 files, 8236/243328 blocks

real 0m0.254s
user 0m0.008s
sys 0m0.044s

Checking the file system again will show it’s clean:

$ sudo file -sL /dev/dm-1
 /dev/dm-1: Linux rev 1.0 ext3 filesystem data,
 UUID=5fc1dccd-527d-41b5-86e0-70f00dce4a0c, volume name "TestEXT3"
 (large files)

 

Leave a Comment