error message when uncompressing disk image - could you provide MD5 or other checksum so we can make sure download was successful?
burned image filesystem seems to have some problems (via e2fsck)
I provide example of how I burned image using a raspberry pi / linux / command line tools
Thank you for providing the Kraken and the great instructions! I’m using the disk image: krakensdr_pi5_30_October_2024.img-005.xz
to setup my raspberry pi 5. I was attempting to put the image on an SD card via my other existing linux system (a different raspberry pi) and I attempted to uncompress the above (using unxz) and ran into this error message: xz: krakensdr_pi5_30_October_2024.img-005.xz: Unexpected end of input
I ultimately got it burned onto my sd card using this command: nohup unxz -c krakensdr_pi5_30_October_2024.img-005.xz | nohup sudo dd of=/dev/sdc bs=4M status=progress &
This seemed to ignore the unexpected end of input, and using the above I’m able to see the 2 partitions and mount them and see their contents so it appears to have worked.
Pushing this further, my SD card is bigger than the image size, so I used parted to expand the second linux partition (sdc2 in my case) to fill the entire disk: sudo parted -s -a opt /dev/sdc "resizepart 2 100%"
I then ran e2fsck (prereq for running resize2fs) and it found many problems with the directory structure, so I exited and reran with -y option - it seemed to be able to work through them: sudo e2fsck -y -f /dev/sdc2
I then was able to resize the file system to fill the partition with: sudo resize2fs /dev/sdc2
example problem found/fixed with e2fsck: '..' in /home/krakenrf/miniforge3/pkgs/plotly-5.22.0-pyhd8ed1ab_0/site-packages/plotly/validators/bar/legendgrouptitle (305658) is / (2), should be /home/krakenrf/miniforge3/pkgs/plotly-5.22.0-pyhd8ed1ab_0/site-packages/plotly/validators/bar (301810). Fix? yes
Unattached inode 33494 Connect to /lost+found? yes
Hmm I’m not sure why you’re getting these errors. We generally recommend burning the SD card via Balena Etcher on a Windows PC, and this software throws no errors.
Thank you for the response. I’m not familiar with that software but I suspect
its not decrypting the file first, it’s decrypting and piping it to the disk so it ignores the error because it occurs at the very end of the process
once written, its not trying to expand the partition to fill the disk so it’s not checking the filesystem integrity
Could you consider providing checksums for these large files so I/we can rule out download mishaps when using them? That’s pretty standard with large file downloads.
Edit: if we want we could try repeating this process with Balena Etcher and then checking the filesystem integrity before using it in a pi. I can do that if you want.
It might be something to do with the way the image is resized to fit on a smaller SD card before uploading. But thus far the process has been fine and caused no issues with the recommended install process.
We’ll look at uploading hashes somewhere, but for now here is one for the latest pi5 image.
certutil -hashfile krakensdr_pi5_30_October_2024.img-005.xz SHA256
SHA256 hash of krakensdr_pi5_30_October_2024.img-005.xz:
1b49dc525c8fbc5f91b8e17307d2ae3023aab0b70a29695d79d45c5f14aa82ca
Thank you for sending the hash code! That proved that the problem I had was an incomplete download but/and I’m amazed any of what I did worked at all given that (i.e. I was able to mount it and see the files etc.)
I was able to burn the image to my SD card as above, I didn’t try to resize it this time (wanting to move forward with actual RF stuff) so I just added a separate partition using up the remaining SD card space and mounted that.
Hmm very strange. I don’t see how it’s possible for a download to get corrupted in such a way. If something actually corrupted due to problems with your HDD, I would expect the compressed file to just have garbage. Anyway, glad to hear it’s working now.