I have a 16GB flash drive, which I converted to a bootable Kali (with persistence) drive awhile back.

As far as I know it's just a Kali live ISO as a ~2GB partition with the rest automatically mounting as storage for the live boot.

I'm trying to wipe it out back to the full storage size, but for some reason I can't ever see it as 16 with two partitions.

This was to be expected with Windows, as it only shows the 14.91 partition, yet even on Debian I'm only seeing that 14.92 msdos partition table (which is now unallocated) on both GParted and fdisk.

What's bizzare is when I view /dev/sdb with parted I see a 16GB device with no partitions, but I know the bootable partition is still here, because I can still boot from it.

Suffice to say I'm completely at a loss as to how I should go about getting this thing completely wiped so I can use all 16GB again.

To clarify, even if this is just a unit reporting discrepancy, that doesn't explain how I'm completely unable to see the partition I'm still very much booting from. How could it just be a unit issue if I'm still booting after I wipe the 14.91GB?

  • Not sure this is what you looking for, but dd if=/dev/null of=/dev/sdb shall do the trick. Be careful not to wipe something else. See the manual for modifiers, i.e. "bs" , otherwise dd might be quite slow
    – Sasha Che
    Dec 7, 2017 at 19:50
  • Can you please post the result of fdisk -l /dev/sdb? It's hard to answer a question with no data.
    – AlexP
    Dec 7, 2017 at 22:36

2 Answers 2


This sounds like a simple difference in units. The storage industry insists on using SI units (base 10, 10^3 scaling between prefixes) for device sizes, while most software shows sizes in IEC units (base 2, 2^10 scaling between prefixes).

As a result of this, one GB as reported by the device manufacturer is:

10 ^ 9 = 1 000 000 000 bytes

Whereas one GB (more correctly GiB for the IEC units) as reported by the OS is:

2 ^ 30 = 1 073 741 824 bytes

Which translates to a roughly 6% difference.

Now, multiplying this out with the values you list gives:

16 GB = 16 * 10 ^ 9 = 16 000 000 000 bytes


14.91 GiB = 14.91 * 2 ^ 30 = 16 009 490 595.84 bytes

Which is within the variance expected for rounding at that scale since converting from GB to GiB for the vendor's reported size gives:

16 000 000 000 / 2 ^ 30 = 14.901 161 193 847 656 GiB

Which rounds up to 14.91 GiB (and no, I have no idea why disk sizes reported by the OS are almost always rounded up regardless of which OS you are using).

  • Did you see my bottom edit? That doesn't explain why I can't see the bootable partition. Dec 7, 2017 at 20:55
  • @WorseDoughnut If you have wiped Kali from the drive, when you boot with the USB plugged in, what OS does the USB boot into? Are you sure it isn't falling back to another bootable partition elsewhere on your system?
    – bu5hman
    Dec 9, 2017 at 15:00

The flash drive probably never used more than one partition so there is no partition table. Using legacy mode booting results in the first 512 bytes of a storage medium being executed. After that is the file system. It likely follows the ISO 9660 standard.

When Gparted and some other tools are used to create ISO format USB drives they ALSO create a partition table. This is called a hybrid ISO and so will accurately reflect the existence of partitions.

As for why there is a discrepancy between the marked 16GBs is properly explained by Austin Hemmelgarns answer.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .