2

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
  • @user1133275, added info (about Kali) as requested. – Sopalajo de Arrierez May 3 '15 at 20:25
  • @user1133275, added sudo -i info case, as requested, thanks you. – Sopalajo de Arrierez May 3 '15 at 20:39
  • @user1133275, the # just means "root execution" (it is the classic way to write it down); anyway, I have edited it to make it clearer. I don't know what you mean with "run sync after". What file do you mean is missing here? The only problem comes from the kali-1.1.0-rpi2.img file; the Ubuntu file is OK. And what is a PS1? – Sopalajo de Arrierez May 3 '15 at 20:45
  • Let us continue this discussion in chat. – Sopalajo de Arrierez May 3 '15 at 21:07
  • Please "sudo -i" then "PS1='> ' then "file *.img && md5sum *.img && du -h *.img && dd if=kali-1.1.0-rpi2.img of=/dev/sdb && sync && fdisk -l /dev/sdb && dd if=2015-04-06-ubuntu-trusty.img of=/dev/sdb && sync && fdisk -l /dev/sdb" and please rewrite your question as stackexchange tries to be more wiki like than forum like. – user1133275 May 4 '15 at 2:00
2

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.

  • Indeed, that was the problem: FireFox had lost the .xz extension of the .img file, I don't know why. It was not my first test, but the other downloads were directly .img files. Thanks you. – Sopalajo de Arrierez May 5 '15 at 15:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.