The .img file transferred to SD Card generates no valid partition table

Question

My RapsBerry Pi 2 B boots Ubuntu 14.04LTS fine in a 32GB SD HC Card, but it does not boot at all (nothing on screen) when trying with Kali Linux v1.1.0.

I tried transferring the .img file from Linux by doing:

sudo dd if=kali-1.1.0-rpi2.img of=/dev/sdb bs=512k

and from Windows by using Win32DiskImager. This is the result:

luis@Chomsky:~$ sudo fdisk -l
Disco /dev/sdb: 61.9 GB, 61924704256 bytes
64 cabezas, 32 sectores/pista, 59056 cilindros, 120946688 sectores en total
Unidades = sectores de 1 * 512 = 512 bytes
Tamaño de sector (lógico / físico): 512 bytes / 512 bytes
Tamaño E/S (mínimo/óptimo): 512 bytes / 512 bytes
Identificador del disco: 0x9b40c48c
El disco /dev/sdb no contiene una tabla de particiones válida

My Linux is in spanish, sorry, but the last line translates to: /dev/sdb has no valid partition table.
I have tested this with some 8GB SD Card, and a just unboxed 64GB SD XC Card, but results are the same.
I have tried too by firstly creating some valid ms-dos type partition table by using gparted, but it seems to be removed after the dd process.

If I try to create the Ubuntu image on the 64GB SD XC Card:

sudo dd if=2015-04-06-ubuntu-trusty.img of=/dev/sdb bs=512k

... the process goes all right:

Disco /dev/sdb: 61.9 GB, 61924704256 bytes
64 cabezas, 32 sectores/pista, 59056 cilindros, 120946688 sectores en total
Unidades = sectores de 1 * 512 = 512 bytes
Tamaño de sector (lógico / físico): 512 bytes / 512 bytes
Tamaño E/S (mínimo/óptimo): 512 bytes / 512 bytes
Identificador del disco: 0x00000000

Dispositivo Inicio    Comienzo      Fin      Bloques  Id  Sistema
/dev/sdb1   *        2048      133119       65536    c  W95 FAT32 (LBA)
/dev/sdb2          133120     3670015     1768448   83  Linux

Same for my 8GB SD Card.

It is hard to believe that the .img file available at a so widely used distro like Kali Linux could be damaged. What is going on here, and what could I check to solve this?

EDIT-01: Tested with two different computers (portables).

EDIT-02: Tested with both an internal SD card reader inside a portable computer and an external USB SD Card reader.

EDIT-03: Added info as requested:

$ ls -lah
total 460M
drwxrwxrwx 1 root root    0 May  3 02:10 .
drwxrwxrwx 1 root root    0 May  3 15:21 ..
-rwxrwxrwx 2 root root 460M May  3 02:12 kali-1.1.0-rpi2.img
$ du -h *.img
460M    kali-1.1.0-rpi2.img
$ md5sum *.img
c8b9bef871f5398bbdb6c7563368f5e4  kali-1.1.0-rpi2.img

EDIT-04: Added sudo -i case as requested:

$ sudo -i
# whoami
root
# dd if=kali-1.1.0-rpi2.img of=/dev/sdb bs=512k
918+1 records in
918+1 records out
481427164 bytes (481 MB) copied, 71.2568 s, 6.8 MB/s

EDIT05: Tested syncing after the dd command:

$ sudo -i
# whoami
root
# dd if=kali-1.1.0-rpi2.img of=/dev/sdb bs=512k
918+1 records in
918+1 records out
481427164 bytes (481 MB) copied, 71.2568 s, 6.8 MB/s
# sync

EDIT-06: Added file output info upon requestion:

$ file kali-1.1.0-rpi2.img
kali-1.1.0-rpi2.img: XZ compressed data
$ file 2015-04-06-ubuntu-trusty.img
2015-04-06-ubuntu-trusty.img: x86 boot sector

EDIT-07: Added du data about the Ubuntu image upon requestion:

du -h 2015-04-06-ubuntu-trusty.img
1,8G    2015-04-06-ubuntu-trusty.img

The problem, by the way, keeps happening for the Kali .img:

Disk /dev/sdb doesn't contain a valid partition table

Answer 1

That Kali .img appears to be compressed, something which isn't mentioned in their install instructions for the pi, and is sort of deceptive if true because of the suffix. Perhaps this is your first test ;)

$ file kali-1.1.0-rpi2.img
kali-1.1.0-rpi2.img: XZ compressed data
                     ^^^^^^^^^^^^^^^^^^

Or there could be something wrong with it that makes it appear that way. Try:

mv kali-1.1.0-rpi2.img kali-1.1.0-rpi2.img.xz
unxz kali-1.1.0-rpi2.img.xz

You may have to install xz if you don't have it already. If that works, then it really was compressed and hopefully the uncompressed .img works.