Reformat the entire fat16 drive, the USB should be right on unity sidebar (Or wherever you've tweaked it), right click it and re-format (Use ubuntu, ubuntu formats drives 1000 times the speed of windows, period.)
Re-partition it. (Use ubuntu software center to easily find multiple linux partitioners)
Attempt to put all the files back onto the USB now.
This is the quickest way I can think of to make a USB reformatted and afterword, partition.
I had the same problem when using an encrypted swap partition. Neither the general Swap FAQ, Puny Geek's solution to the "cryptswap1 is not ready yet or not present" message nor Braiam's answer to this question solved the problem for me - sometimes the swap was available, sometimes it wasn't. After many reboots and some poking around, I think I have found the underlying reason:
The path to the swap partition like /dev/sda3
is sometimes different, e.g. /dev/sdb3
. Since the file /etc/crypttab
by default seems to identify the swap partition through this path, sometimes it would find it (if that partition happens to get the same path at boot) or not (if the partition gets a different path assigned at boot).
Seems like I wasn't the only one with that problem becasue as described here, a better solution would be to bind the swap partition through it's drive ID instead of its /dev/sd*
path. This can be found by running
ls -l /dev/disk/by-id/
which lists the disk IDs for all partitions including the swap, which in my case was
ata-TOSHIBA_MQ01UBD100_73JATD5GT-part3 -> ../../sdb3
Double check in a program like Disk Utility that the -> ../../sdb*
part of this line is indeed the partition you intend to use for swapping, as this (as I said before) can sometimes change names. As always, keep this in mind:
Caution: fiddling with cryptsetup and disk devices is dangerous for
data and OS. I personally made a full backup on a separate disk and
then umplugged it to be sure it wouldn’t be involved in any mishap.
Then edit your /etc/crypttab
file by using the ID link instead of the "raw" path, in my case this line is
cryptswap1 /dev/disk/by-id/ata-TOSHIBA_MQ01UBD100_73JATD5GT-part3 /dev/urandom swap,cipher=aes-cbc-essiv:sha256
I think this method should be the default for new installations, as one apparently can never be sure of the /dev/sd*
paths... which I find somewhat worrying as I have the feeling that there are way more scripts and software out there which still rely on these paths (instead of IDs, labels or UUIDs) to stay the same across reboots.
TODO:
I haven't checked if resuming out of hibernation still works with this setup, as this seems to rely on a UUID (which my swap partition didn't have), as stated on this page: https://altinukshini.wordpress.com/2012/10/15/devmappercryptswap1-is-not-ready-yet-or-not-present/
Update:
Hibernation seems to work fine so far. Hope this solves these problems for others as well!
Best Answer
You have a problem with your
/etc/crypttab
file that's causing eveything to go south, and a problem with your swap partition.First off, you need to
mkswap
the partition that you want to use for your encrypted swap file. The cryptdisk utility expects your partition to be swap, so you should keep it as such:Now, note that this will change the partition's UUID. Get the new one with the following command, and make note of it:
Now, we need to deal with the larger problem at hand: your
/etc/crypttab
file. Replace it with the following:Reboot the system, and you should have a working swap!
You have your
cryptswap
set up currently to recreate the entire partition as an encrypted swap. This is Not Good™, because we need to preserve the UUID. By offsetting the swap by 1024 blocks, we preserve the critical filesystem info, including the UUID.