Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
I have just used dd to place the Kali Linux ISO file onto my USB. I then tried to install Kali Linux via the USB, but I couldn't since the install-image was corrupt. I booted back into my other Linux OS (antergos) and tried using dd again. My USB-Stick now says it's 32KB in size and fdisk can't detect it.
It is originally an 8GB USB 2.0 stick.
To override the MBR and Partition-table, I unsuccessfully tried:
dd if=/dev/zero of=/dev/sdx bs=512 count=1
Your usb stick has failed.
Some drives return different sizes when they fail, although I've only read about this with regard to "SSDs", which have more complex controllers.
To double-check the size of the drive as a whole, I would use lsblk or look in the kernel log dmesg. (The size of partitions within the device could be completely bogus depending on the partition table; you could contrive this without having a hardware failure).
If the size was OK, there are ways you could try to recover important data. But it doesn't sound like you need to - you still have access to the Kali ISO file.
Simple usb sticks aren't designed with any extra hardware diagnostics[*]. Once you know the hardware has failed, that's it. Either of the size of the drive as a whole going wrong, or the drive not returning the data you wrote to them (suggested by failure of fdisk), would be enough to indicate such failure.
[*] I think they're not even designed for uses where the maximum expected re-write cycles of flash storage becomes an issue. They're much more likely to just break, or be lost.
This can happen when the virtual disk geometry is wrongly detected. First try to reboot before proceeding.
Warning : I don't think this could be harmfull for your usb key but if you don't want to take any risk, please test formatting under Windows fisrt.
This guide assume you drive is /dev/sdb, please adapt to your need.
In a terminal, search the output of dmesg for such a line sd 5:0:0:0: [sdb] 62545920 512-byte logical blocks: (32.0 GB/29.8 GiB)
This tells you :
62545920512 bytes32.0 GB/29.8 GiBNow calculate the exact media size in byte : 62545920 * 512 = 32023511040 bytes = 30540 MiB (29.82GiB).
Then find a valid CHS combination leading to C * H * S = 62545920
Or if you are feeling lazy, with 512 byte block size, this should work : C=30540 (the size in MiB!), H=64 and S=32
Finally, run sudo fdisk -C 30540 -H 64 -S 32 and write a new partitaion table to fix.
Reboot if changes are not correctly detected.
I know this place is about unix, but when I have this problem I find a windows machine and I use diskpart (admin access needed). Because when fdisk fails, this just works; maybe it will help somebody.
I can't try the instructions right now, but it should be something like :
list disk, select disk i, clean, create partition primary, format fs=fat32 quick, active, assign, exit.
And your USB stick size is now OK (but of course, you have lost your data).
I'm also interested in an equivalent way to succeed this with linux.
NB: I'm not sure the wrong size indicates the dd has failed. Anyway, don't forget to append && sync to your dd command.
sync is a great point. Removing the usb stick without sync could lose data at the end & cause the Kali boot or install to fail. It might also cause fdisk error (or warning?) w.r.t. GPT partion tables, because they have a trailer at the end of the disk image as well as a header at the start like old-style MBR uses. I can't think of an interpretation where the size 32KB would appear, but linux "ISO" hybrid images are black magic, so I am not certain about that.
Nov 6 '16 at 14:00
sdx (e.g. sda, not sda1) with a size fo 32KB, would tell you the usb stick is failing and should never be trusted again :).
Nov 6 '16 at 14:15