Whats going on here. I expected the same size image for all three cards.
Are SD-cards all slightly different sizes or is dd doing something funny dependent on the data on the cards?
marty,
Whats going on here. I expected the same size image for all three cards.
Are SD-cards all slightly different sizes or is dd doing something funny
dependent on the data on the cards?
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
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.
Whats going on here. I expected the same size image for all three cards.
Are SD-cards all slightly different sizes or is dd doing something funny dependent on the data on the cards?
1) find some way to shrink the (last) partition (of a new installation)
so at the end there is some unused space (200 MB ?)
2) find out how to (automatically, scripted) obtain the "certain size" (mentioned above).
I think I remember having seen a few posts about it, but can't remember
what the outcome was.
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.
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.
Ahem,
Not sure about SD cards but when I hit this with 2TB disc
drives the spread in sizes was only a few megabytes.
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 ?
I mentioned a difference of 70 MB. The OP supplied sizes with
a difference of almost 96 MB.
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
Hi folks,
I have three PIs running with identical SanDisk Ultra 32GB SD-cards but
each containing different OS versions and data.
Whats going on here. I expected the same size image for all three cards.
Are SD-cards all slightly different sizes or is dd doing something funny >dependent on the data on the cards?
marty <marty@invalid.net> wrote:
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.
You don't have to have exactly matching sd cards or larger ones like 64 GB. See the top answer here https://askubuntu.com/questions/1174487/re-size-the-img-for-smaller-sd-card-how-to-shrink-a-bootable-sd-card-image
which was the first hit for "linux shrink image file".
It is indeed a hassle, unless you automate the process.
Hi folks,
I have three PIs running with identical SanDisk Ultra 32GB SD-cards but
each containing different OS versions and data.
When I dd them to a backup image on my Linux desktop:
sudo dd if=/dev/sde of=pibed-backup.bin bs=512 status=progress
32008593920 bytes (32 GB, 30 GiB) copied, 1728 s, 18.5 MB/s
62521344+0 records in
62521344+0 records out
32010928128 bytes (32 GB, 30 GiB) copied, 1728.62 s, 18.5 MB/s
I get 3 different size images for the three SD-cards:
marty@light:~/Desktop/downloads$ ls -l pi*
-rw-r--r-- 1 root root 31981568000 Jun 5 17:58 pi-backup.bin
-rw-r--r-- 1 root root 32010928128 Jun 10 17:14 pibed-backup.bin
-rw-r--r-- 1 root root 31914983424 May 21 05:55 pihole-backup.bin
Whats going on here. I expected the same size image for all three cards.
Are SD-cards all slightly different sizes or is dd doing something funny dependent on the data on the cards?
Cheers,
marty,
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.
As far as I know DD can be told to only copy upto a certain size.
Though the problems are than to :
1) find some way to shrink the (last) partition (of a new installation) so
at the end there is some unused space (200 MB ?)
2) find out how to (automatically, scripted) obtain the "certain size" (mentioned above).
On 11/6/22 20:09, A. Dumas wrote:
marty <marty@invalid.net> wrote: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.
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.
You don't have to have exactly matching sd cards or larger ones like
64 GB.
See the top answer here
https://askubuntu.com/questions/1174487/re-size-the-img-for-smaller-sd-card-how-to-shrink-a-bootable-sd-card-image
which was the first hit for "linux shrink image file".
It is indeed a hassle, unless you automate the process.
On 11/06/2022 08:04, R.Wieser wrote:
marty,
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.
As far as I know DD can be told to only copy upto a certain size.
Though the problems are than to :
1) find some way to shrink the (last) partition (of a new installation) so >> at the end there is some unused space (200 MB ?)
Use the gparted tool.
2) find out how to (automatically, scripted) obtain the "certain size"
(mentioned above).
Just knock off 0.1GB from whatever size card you are using.
---druck
As far as I know DD can be told to only copy upto a certain size.
Though the problems are than to :
1) find some way to shrink the (last) partition (of a new installation) so
at the end there is some unused space (200 MB ?)
2) find out how to (automatically, scripted) obtain the "certain size" (mentioned above).
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.
R.Wieser <address@not.available> wrote:
As far as I know DD can be told to only copy upto a certain size.
Though the problems are than to :
1) find some way to shrink the (last) partition (of a new installation) so >> at the end there is some unused space (200 MB ?)
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.
2) find out how to (automatically, scripted) obtain the "certain size"
(mentioned above).
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.
gparted knows enough of the different filesystems to be able to do that ? Hmmmm... Maybe I should take a look at it.
Scott,
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.
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 ...
| Sysop: | Xerxes |
|---|---|
| Location: | Azle, Texas |
| Users: | 118 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 64:39:57 |
| Calls: | 3,014 |
| Calls today: | 1 |
| Files: | 154 |
| U/L today: |
0 files (0K bytes) |
| D/L today: |
0 files (0K bytes) |
| Messages: | 293,190 |
| Posted today: | 0 |