PI SDcard images

marty,

I had the same problem when I thought I could just duplicate one micro-sd card to another : It would not fit (a difference of 70 MB).

The reason is most likely the number of sectors that are reserved by the cards internal controller (you can't see or touch them), so it can swap in new sectors for ones that get worn out.

Regards, Rudy Wieser

That makes sense.

I have ordered a 64GB card in case I ever need to make a new card from the 32GB backup image. Not sure what else to do, it is a hassle.

Cheers,

The former, the same applies to hard disks too and sometimes causes problems when replacing drives in a RAID setup.

marty,

As far as I know DD can be told to only copy upto a certain size.

Though the problems are than to :

I think I remember having seen a few posts about it, but can't remember what the outcome was.

Regards, Rudy Wieser

Not sure about SD cards but when I hit this with 2TB disc drives the spread in sizes was only a few megabytes.

Fix the tool that expands the partition in the first place to round the size down to a multiple of 16Mb instead of using it all.

You don't have to have exactly matching sd cards or larger ones like 64 GB. See the top answer here

It is indeed a hassle, unless you automate the process.

Ahem,

I mentioned a difference of 70 MB. The OP supplied sizes with a difference of almost 96 MB.

I think you mean 'toolS', with an "s" on the end. Though in most cases there is no need for that. And why throw away storage space ?

Just here, in the case of the RPi, it would have been nice to have a bit of 'slack space'.

Regards, Rudy Wieser

OK - that makes it harder and more wasteful to find a size that fits all.

Yeah OK toolS - and because it's a small price to pay for convenience (even 256 megs wouldn't be much in 64 gigs or more), storage space is dirt cheap these days - hassle is expensive and irritating.

Ahem,

I don't think there is any such size, as its fully upto the manufacturer of the micro-SD card to pick the number of replacement sectors - which get subtracted from the total size of the thumbdrive.

The problem is that all those tools get made by different people/companies. You would need to convince *all of them* to make such a change. There is little chance to that.

As far as I can tell it would only be a possible convenience in regard to a RPi micro-SD card (and similar), and only to people who use the default instal. To all others it would be wasting space for no reason whatsoever.

People who do a manual install (creating/defining their own partitions) its no problem to not to have the last partition extend upto the end of the storage space.

Having said that and thinking back to a number of "noobs" installs I sure would have liked to have had a choice in it.

Regards, Rudy Wieser

On Sat, 11 Jun 2022 13:24:03 +1000, marty snipped-for-privacy@invalid.net declaimed the following:

Unless those cards are all from the same production batch, it IS possible that they are slightly different internally. Controllers reserving different amounts of "allocation units" for wear leveling. Possibly some bad-block remapping even at the factory floor.

With a good light, and a good magnifier, you might be able to read the production code off the card -- if the code differs, anything goes.

There may also be an effect from how the FAT partition was sized vs the EXT# partition(s)

I used the script pishrink.sh mentioned on that web page and it worked! gparted doesn't like the resulting SD card (error: can't have partition outside disk space) but it boots in the PI.

Cheers,

Use the gparted tool.

Just knock off 0.1GB from whatever size card you are using.

---druck

Don't use that script it is wrong, and will cause problems with various disk tools of which gparted is only one.

There is a way to fix a card which has been butchered in that way using the command line parted (not *g*parted) tool to delete the partition table entry and recreate it so it doesn't go over the end of the card.

But its much easier to go back to the original larger card, and resize it properly with gparted before copying.

---druck

And add partition at the end of the card. And make it start from the same sector on all cards. The end sector will be different, but it does not matter. And mark it as some other FS (for example ff). And than automatic expand will expand it to that place.

gparted will do that for you. I have a project at work where I do just that to image it across multiple Raspberry Pis: use gparted to shrink the image size to the minimum needed to create the image, and to expand into the full space of a new SD card once the image is dd'd onto it.

I've not automated this, but once I have the partition size minimized, I use fdisk to get the last block of the last partition. Multiplying that by 2048 gets the image size in MB; pass that to dd as the "count" parameter, with "bs=1048576" to set the block size.

No need for using fdisk there, gparted shows the numbers of blocks in partitions. Just check the last block of the last partition, add one and multiply with block size (usually 512).

Scott,

gparted knows enough of the different filesystems to be able to do that ? Hmmmm... Maybe I should take a look at it.

Although I like the idea of shrinking the backups to whats actually used, it also means I need to keep an un-shrunken (plain DD) backup with gparted on it to be able to do that ...

Thanks for the info.

Regards, Rudy Wieser

The only common filesystem I can think of that gparted might not handle is ExFAT...and a quick search indicates that v1.2 and up support ExFAT. It even supports NTFS.