search

raspberrypi / rpi-imager

The home of Raspberry Pi Imager, a user-friendly tool for creating bootable media for Raspberry Pi devices.
https://www.raspberrypi.com/software
Other
1.66k stars 253 forks source link

Write error. Contents of SD are different from what was written on multiple SD cards. #364

Closed ghost closed 2 years ago

ghost commented 2 years ago

So like the title says I'm getting that error everytime I try to flash kali-linux-2022.1-raspberry-pi-armhf to my SD card. I'm running the latest version of the imager, and my OS is windows 10. Like stated earlier I have tried this with multiple SD cards and redownloading the Kali image multiple times with no variation. However a different Kali image worked on the SD card before this error happened, but while running it was unable to update due to a Kernel error and I had no choice at the time but to go nuclear with a new install. Thus where I am now with this error. If any more information is required I will try to respond as soon as possible.

lurch commented 2 years ago

Have you tried writing Raspberry Pi OS to your SD-card, just to check that there's not a problem with your SD cards and/or your SD card reader?

ghost commented 2 years ago

Have you tried writing Raspberry Pi OS to your SD-card, just to check that there's not a problem with your SD cards and/or your SD card reader?

Yes I have, other OS's like Raspberry Pi OS were successful in the flashing process so my verdict has come to the point that it's a problem with the Kali linux image itself. However kali seemed to work seamlessly before the 2022 update they pushed. So maybe it broke support temporially. Anyways as this is now (probably) considered an invalid issue I should probably close it.

maxnet commented 2 years ago

There is indeed something interesting with this image. It is 10021590357 bytes uncompressed.

That's not a "normal" disk image size. Disks are always meant to be a multiple of the sector size of 512 bytes big, and this size is not dividable by that.

Windows and Mac OS X will indeed fail when trying to write the last bytes of the image. They do not accept writes that are less than 512 bytes to raw disk devices. Does work for Linux users.

lurch commented 2 years ago

Are other disk-writing tools on Windows (e.g. Win32DiskImager or Etcher or Rufus) able to write that unusual-sized disk image? If they do, maybe they just pad it up to a multiple of 512 bytes using zeros?

maxnet commented 2 years ago

Are other disk-writing tools on Windows (e.g. Win32DiskImager or Etcher or Rufus) able to write that unusual-sized disk image? If they do, maybe they just pad it up to a multiple of 512 bytes using zeros?

Or maybe they silently fail to do their job as well, but nobody is missing the last 341 bytes in practice... We do are unique in the sense that we invalidate the partiton table if verification fails.

ghost commented 2 years ago

I'm not sure if any other etchers will work as I was running windows 10 on ARM and Balena refused to run. And anything like Rufus refused to acknowledge my SD cards existed so I gave up on trying to get the new image. Instead I built a custom Kali image using the previous release and manually updated the kernel as necessary. So the issue I previously had is resolved, however the image itself on the Kali page might need some updating.

maxnet commented 2 years ago

Here's a build that pads the last bytes: imager-1.7.1.exe

Only pads when using custom gz/xz/zstd image files. The existing behavior of instantly rejecting the image file as invalid, if we know the uncompressed file size in advance (which is the case with .zip files, images from repository and uncompressed images) and it is not a multiple of 512 bytes, remains unchanged.

Also notified Kali, and was told there already was an related issue about it open for 5 months (with losetup giving warnings about the image size being impossible for a block device as well, and truncating the image rather than padding), but so far nobody had the time to fix it.