0

Everybody knows - by raspi-config we can expand the image to the borders of the ext4 partition of the SD-card, but shrinking is impossible.

This will generate copy problems, using a second SD-card to copy to, with labeled same size, but in reality the usable space is a bit smaller (e.g. 8Gb SD-Card 1, 7,2 GB space usable; 8GB SD-Card 2, 7,1 GB space usable)

This means, even when the used space of the larger SD Card is (much) smaller than the available space of the fresh second SD-Card, win32DiskManager will not work as it can only copy physical blocks 1:1 ...

To overcome this situation shrinking the ext4 content of SD-card 1 is a Must to succeed

How to manage this situation technically?

My idea (e.g. with the below constraints):

SD-Card 1, labeled 8 GB, real space is 7.2 GB, Raspian Image is expanded to its boarders

fresh SD-Card 2, (labeled 8GB, real space is 7.1 GB, FAT32 - empty)

Additional Linux PC (e.g. Virtual Box VM running your Linux Guest on your Host windows 10 system)

Steps:

  1. Prepare the second (smaller) SD-card with a fresh Raspian image, boot and expand it by raspi-config to the SD-card borders.

  2. Mount the two SD-cards into your running virtual Linux system

  3. By File Archiving (not Partition Archiving!) "fsarchiver savedir ..." prepare a file archive from all files of the ext4 partition of the 1. (larger) SD-Card

  4. Delete all files in the ext4 partition of the second SD-Card (e.g. by "rm -r *")

  5. Use "fsarchiver restdir" to restore the archived ext4 files from the 1. SD-Card ext4 partition into the corresponding ext4 partition on the 2nd SD-card. As you are not copying the partition - but files, the slightly smaller ext4 partition of SD-Card 2 will now contain all ext4 files of the 1. SD-Card. The nautilus explorer confirms this!!!

  6. Unmount your 2nd SD-Card put into your Raspberry and boot ...!

I have tried this- no chance the boot fails! This method will only work when the second SD-card provides exactly the same ext4 space as the 1 SD-Card.

I am confused now, because I had assumed that copying files (and not partitions) could resolve the win32DiskManager Block Copy issue.

What is my error, please?

Your expert explanation is pretty much appreciated.

Thanks in advance

Karl
  • 3
  • 3
  • It depends on what you want - we COULD try to debug what you did (which seems overly complex) or provide links to any of the other solutions which worked, BUT I suggest you just use the `SD Card Copier` in Raspbian to duplicate the card - this works to smaller or larger SD Cards. – Milliways Feb 15 '19 at 06:12
  • Incidentally it is quite simple to shrink a partition (this needs to be done on a Linux machine). This can be done manually or with tools like `gparted`. It can even be done on the Pi (but not to the active partition). – Milliways Feb 15 '19 at 06:15
  • Thanks for your answers: As I know (have experienced) - as soon as block of the by raspi-config expanded space have been used, gparted will fail to finish and end with indicating an error! Same vaild for SD Card Copier ??? Have you tried already? Thanks – Karl Feb 15 '19 at 06:38
  • `sd card copier` (or piclone) works as long as the destination card is big enough to hold the content of the current card – Jaromanda X Feb 15 '19 at 07:43
  • You can NOT use gparted (or indeed any other tool) to manage the currently mounted partition but it can be used to modify an image. (It is possible to modify the partition table, reboot and resize the partition - this is what the resize option of raspi-config does). I regularly use `SD Card Copier` - even copying a 16GiB card to 8GiB (after deleting excess files). – Milliways Feb 15 '19 at 09:40
  • Using an archive file to copy from one card to another sounds overly complicated and uses up space on one of the cards. A better approach would be to use `rsync -a --delete / /mnt/new/card` to copy the files over, of course you'd need to fine tune the command to exclude things like `/boot`, `/sys` and `/proc`. – Roger Jones Feb 15 '19 at 11:14
  • gparted only on unmounted partitions is a nobrainer! But even is the partition is unmounted, gparted would only shrink FREE space when the free space was never used in your file management before. As soon as your have written files into the free space (even after file deletion) the free space can't be shrinked any more by gparded. In one sentence - gparted can only shrink by UNUSED blocks which were never stroed in any file allocation table before! I also agree, SD Card copier faces the same problem as Win32Manager, desitination SD-Card real space must be equal or bigger. – Karl Feb 15 '19 at 14:16
  • Finally I have found a description how shrinking SD-cards can be done http://www.aoakley.com/articles/2015-10-09-resizing-sd-images.php . I can confirm it works very well. I have seen other recommendations - similar "complicated" - but following same strategy doing the math on sector and block calculation... Question remains, why does the above proceeding (fsarchive ...) does not work - for the reason of curiosity ....! Thanks. – Karl Feb 15 '19 at 17:43

1 Answers1

0

I also make copies the way you describe and stumbled also about the problem you have: a copied SD Card does not boot. I found that the problem was the master boot record (MBR), the very first sector with 512 bytes on the storage. If it does not fit exactly to what Raspbian expects then it will not boot. Here is what you need to do to create the MBR with a Linux machine provided the unmounted SD Card is attached as /dev/sdb. You can look at the MBR with:

pc ~$ sudo hd -n 512 /dev/sdb

To create the MBR do:

pc ~$ sudo -Es
pc ~# dd if=/dev/zero of=/dev/sdb bs=512 count=1
pc ~# /bin/echo -ne '\x28\xe4\x3e\x4d' | dd of=/dev/sdb bs=1 seek=440
pc ~# /bin/echo -ne '\x55\xaa' | dd of=/dev/sdb bs=1 seek=510
pc ~# exit
pc ~$

Be aware that this will overwrite your existing partition table without warning and you
loose ALL data on the SD Card!

Based on this I have made a tested Howto prepare a SD card from a tar archive on a Linux machine but only using Linux commands.

Ingo
  • 40,606
  • 15
  • 76
  • 189
  • Big relief - somebody confirms, you Ingo, thanks a lot!!! I have also assumed, something is going wrong with the MBR. BUT: In my understanding in my described proceedings the MBR is never touched when using fsarchive operations. So what damages or misaligns the MBR links? As I had described- the second SD-Card was copied on with a working (fresh) image by win32manager- at this time the MBR should be fine. Deletion of ext4 content and copying ext4 files from SD-Card 1 by fsarchive neither will damage the MBR. In my understanding the MBR is always independent from all partition (file) content – Karl Feb 16 '19 at 05:02
  • Upps - I should have read your link first, before answering ...! Great Thread!!! Is the cmdline.txt file the problem in fat32 which contains this identification link to the partition - id (examplarily " .... root=PARTUUID=010e6c2c-02 ... " )? Would mean, it is not a MBR problem but identification problem to the partition? – Karl Feb 16 '19 at 05:15
  • @Karl with the hexdump (**hd**) program you can always monitor what is changing the MBR. Addressing the issue with PARTUUID there is another problem when using partitioner. Look at [Is it possible to use partition UUID for root-parameter in cmdline.txt?](https://raspberrypi.stackexchange.com/q/78291/79866) and at [Can't boot after adding a third partition to sd card](https://raspberrypi.stackexchange.com/a/78245/79866). If my answer help you it would be nice if you could accept it by ticking the tick on the left side on my answer. – Ingo Feb 16 '19 at 12:10