locked Re: HamPi on a 128GB SD-Card

Marty Hartwell

Hi Jeff and all

A question for my ongoing education. Not exactly about copying

an image onto a new micro SD card, but one on the Pi doing

a SD copy backup of the disk in use. Like copying the image

on the first card, doesn't the Pi OS prepare the SD for the copy

by what ever means, it says all information will be erased, as a


Another question, I recently bought a SanDisk 64GB 10 rated Ultra

disk and trying to use it right out of the package my Pi nor two other

PC's would see the disk, so I returned it. So when you buy a new disk

has it been formatted as say FAT32 or is it not formatted at all just

seen as a media ready for use somehow. I have never been curious

enough to check before.

Marty kd8bj

On 7/7/20 8:54 AM, Jeff Palmer via groups.io wrote:

If you are using a disk image, then no.. the existing partitioning, or
filesystems don't matter. They literally get overwritten. If you've
seen cases where this doesn't seem to be the case, I assure you,
something else is going on. With a disk image, even the boot sectors
of a disk are overwritten.

I'm not trying to argue. But I am trying to clear up misinformation,
because it's become obvious in these threads that.. a little
misinformation leads to a LOT of confusion. So, I'd submit that if
you've "seen it matter" before, you investigate the root cause, as I
assure you, it's not the fault of a disk image "sometimes working,
sometimes not". a properly created disk image, which is also written
properly to a disk will *always* overwrite existing boot sectors,
partition maps, and existing filesystems. Any result *other* than
that, something else was at play. (human error, invalid disk image,
an error with the software writing the image, faulty disk, etc etc the
list goes on and on.)

On Tue, Jul 7, 2020 at 8:52 AM Mark Griffith via groups.io
<mdgriffith2003=yahoo.com@groups.io> wrote:
The existence of a partition or filesystem on an SD card *should not* make any difference when writing an image, but it sometimes does. That's why I say NOT to format the card before copying the image. In most cases, I would say it doesn't make a difference, but I have seen some where it has.

Also, I'm hoping all those that are using a giant SD card for the image know to use raspi-config to then expand the filesystem so all of the big SD card is used.


On Tuesday, July 7, 2020, 7:32:23 AM CDT, Jeff Palmer via groups.io <jeff=palmerit.net@groups.io> wrote:


Since etcher is writing a raw disk image, the existing filesystems,
partitions, or layouts shouldn't matter (or affect writing the image)

For what it's worth, I have HamPi running on a 128gb sd card. I used
etcher, and never had an issue. I hope that helps.

On Tue, Jul 7, 2020 at 1:16 AM thegadget techie <gadgetechie@gmail.com> wrote:
I did pick up a couple of SanDisk xPros. Seemed the issue may have been the factory format - I zapped the 2nd on w/ xFat (not FAT32) and no hitch w/ Etcher. So maybe that's the issue. Also on MacPro (yeah yeah I'm 25+ yrs *nix guy). I dd'd the 1st SDCard (wiped block 0 & 100) and the PI imager did all the magic - so long story short - not really sure of the issue - but both 128Gb's running like a charm. Now onto USB boot on Pi4....

Thanks all for replies.

On Sun, Jul 5, 2020 at 5:50 AM John Nicholas <stnick@iwichita.com> wrote:
Ditto on San Disc. I found that out with discs from my Infrared Imager at work.


On Jul 5, 2020, at 3:24 AM, Roger Reeves M0ROJ <m0roj@goldford.co.uk> wrote:

It’s all down to the quality of the SD card. A recommendation is the SanDisk Extreme Pro, whatever the size.

Roger M0ROJ

Jeff Palmer
Palmer IT Consulting, LLC.

Join RaspberryPi-4-HamRadio@groups.io to automatically receive all group messages.