Getting back to original SD card size after recovery using mirrored SD

My openhab 3.3M5 instalation on a Pi2B running openhabian stopped responding. I was away from home, but when got to it, I took the mirrored SD card from its adapter, put it in the slot, and to my great relief, it started up and is working. (Thanks for making the SD Mirroring easy for a newbie to set up).

The original SD card was 16 GB. The mirrored is 64 GB. I would like to get back to running off a 16 GB SD card and using the larger card for mirroring.

But the documentation says "In case of failure of your primary SD card, replace the broken SD card in the internal slot with your backup card from the external reader. Get another SD card that matches the size of the backup (now in internal slot) card and use menu option 54 to copy your active backup card back to the new one.
".

If I do that, I will need a 128 GB card for mirroring as the docs say to use a card that is twice the size of the main card. I can imagine the next time this happens, I would need 256 GB, etc.

Am I missing something?

It seems like the only way back to 16 GB is to back up the openhab configuration, make a fresh 16 GB openhabian card, restore the back up and everything else I have set up (Mosquito, Wireguard, Frontail) and perhaps other things I will find out when I try it.

In addition to the main documentation at openHABian | openHAB, I also considered Raw copy SD (option 54) copies all 3 partitions if source is mirrored card (ie result of option 53) and Best way to upgrade to bullseye for openhabian - #2 by rlkoshak.

Thanks for any help. And regardless, as I said at the beginning, I’m glad I was able to follow the instructions and get the mirroring set up, and when I needed it, it worked perfectly.

No they do not. Read more carefully, this statement is in the installation context but does not apply to “raw copy”. For that it should work to have a card of at least equal size.
You could also try to do the raw copying to your old SD. May work or not.

Also you should be having a backup and restore that to your old or any other 16GB card.
Mirroring is not a replacement for a backup.

@mstormi Thanks for the helpful response. I do have a recent back up (manually created using openhabian-config 50). And with the mirrored disk, I could create a new one if I didn’t. I have tried before, unsuccessfully to set up Amanda. That is why I had the 64GB SD card in the external adapter. It seemed like I got close but was asked questions I didn’t know how to answer. I now know a little more about Linux and will try it again.

I inserted a new 16GB SD card in the external card adapter plugged into one of the Pi’s USB ports and executed 54 from the openhabian-config menu. I received a message on the screen (that I didn’t write down, but best as I remember said basically) that the disk was smaller than a partition, but was big enough physically so it might still work.

This is what I received on the ssh console:

blockdev: cannot open /dev/sda2: No such file or directory
raw device copy of /dev/mmcblk0p2 is larger than /dev/sda2... blockdev: cannot open /dev/sda3: No such file or directory
raw device copy of /dev/mmcblk0p3 is larger than /dev/sda3... FAILED (cannot duplicate internal SD card /dev/mmcblk0, it is larger than external /dev/sda)
Checking that no-one is using this disk right now ... OK

Disk /dev/sda: 14.9 GiB, 15978201088 bytes, 31207424 sectors
Disk model: Storage Device  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Old situation:

Device     Boot Start      End  Sectors  Size Id Type
/dev/sda1        8192 31207423 31199232 14.9G  c W95 FAT32 (LBA)

>>> Script header accepted.
>>> Script header accepted.
>>> Script header accepted.
>>> Script header accepted.
>>> Created a new DOS disklabel with disk identifier 0x3d95f40a.
/dev/sda1: Created a new partition 1 of type 'W95 FAT32 (LBA)' and of size 256 MiB.
Partition #1 contains a vfat signature.
/dev/sda2: Created a new partition 2 of type 'Linux' and of size 14.6 GiB.
/dev/sda3: Start sector 62521344 out of range.
Failed to add #3 partition: Numerical result out of range
Leaving.

Taking a raw partition copy, be prepared this may take long such as 20-30 minutes for a 16 GB SD card
FAILED (raw device copy of /dev/sda2)
FAILED (raw device copy of /dev/sda3)
FAILED (set random UUID)
mount: /storage/syncmount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.


sed: can't read /storage/syncmount/etc/fstab: No such file or directory
umount: /storage/syncmount: not mounted.
OK (dirty bit on fsck /dev/sda2 is normal)

It’s possible to shrink a partition, but this is not true for the mounted root partition.

There are quite some options to get around that problem. If you have another SD Card with (e.g.) Raspberry Pi OS. boot from this card and shrink the other partition. If using a Desktop version, you can do it with gparted, nice GUI and a no-brainer.

Now to copy the first two partitions from one SD Card to another, you’ll have to use dd, something like

sudo dd if=/dev/mmcblk0 of=/dev/sda bs=1M count=16644

any partition from sda must not be mounted at that time!

You’ll have to calculate the count value (use fdisk to get the amount of sectors for the new card, divide by 2048 (if bloccksize is 512 Bytes) to get count. Be aware that the shrinked partion must fit to the “new” SD Card and there is a first partition which is 256 MBytes in size. the first 8192 Blocks (4 MBytes) are reserved.
The dd command will copy in raw mode.
Another option would be to copy the partitions separately, so two commands:

sudo dd if=/dev/mmcblk0p0 of=/dev/sda1 bs=1M
sudo dd if=/dev/mmcblk0p1 of=/dev/sda2 bs=1M

This way you don’t need to calculate count, but you’ll have to partition the SD Card first to the correct sizes.

thanks for the suggestions.

I have another 16 GB SD card, and could load Raspberry Pi OS on it and boot it. I’m not sure what you mean by “shrink the other partition”. Which other? The remainder of the new SD card, or the 2nd part of the former mirrored SD card, i.e. mmcblk0p2, which is 29.6 GB (from lsblck) on the mirrored card.

If I understood correctly, I could use the gparted app on my Windows laptop to shrink the partition of mmcblk0p2 on the mirrored SD card. And that size would be the size of the card less the 256 MB needed for the boot partition.

openhabian@openhab:~ $ df  /dev/sda
Filesystem     1K-blocks    Used Available Use% Mounted on
devtmpfs         1825936 1825936         0 100% /dev

Maybe it would be obvious if I tried, but I am reluctant to start on something where I could mess it up without fully understanding what I’m doing.

I got an SD card matching the size of the original (64 GB) and ran openhabian 54, with this result:

openhabian@openhab:~ $ sudo openhabian-config
[sudo] password for openhabian: 
2022-09-04_07:58:23_MDT [openHABian] Checking for root privileges... OK
2022-09-04_07:58:23_MDT [openHABian] Loading configuration file '/etc/openhabian.conf'... OK
2022-09-04_07:58:24_MDT [openHABian] openHABian configuration tool version: [main]{2022-08-24T11:37:05+02:00}(4a11e45)
2022-09-04_07:58:24_MDT [openHABian] Checking for changes in origin branch main... OK
2022-09-04_07:58:26_MDT [openHABian] Switching to branch main... OK
2022-09-04_07:58:26_MDT [openHABian] Adding slightly tuned bash configuration files to system... OK
blockdev: ioctl error on BLKGETSIZE64: Inappropriate ioctl for device
raw device copy of /dev/mmcblk0p2 is larger than /dev/sda2... blockdev: ioctl error on BLKGETSIZE64: Inappropriate ioctl for device
raw device copy of /dev/mmcblk0p3 is larger than /dev/sda3... Checking that no-one is using this disk right now ... OK

Disk /dev/sda: 58.2 GiB, 62534975488 bytes, 122138624 sectors
Disk model: Storage Device  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xa806fd8a

Old situation:

Device     Boot Start       End   Sectors  Size Id Type
/dev/sda1       32768 122138623 122105856 58.2G  7 HPFS/NTFS/exFAT

>>> Script header accepted.
>>> Script header accepted.
>>> Script header accepted.
>>> Script header accepted.
>>> Created a new DOS disklabel with disk identifier 0xcf2e0df8.
/dev/sda1: Created a new partition 1 of type 'W95 FAT32 (LBA)' and of size 256 MiB.
/dev/sda2: Created a new partition 2 of type 'Linux' and of size 29.6 GiB.
/dev/sda3: Created a new partition 3 of type 'Linux' and of size 28.4 GiB.
/dev/sda4: Done.

New situation:
Disklabel type: dos
Disk identifier: 0xcf2e0df8

Device     Boot    Start       End  Sectors  Size Id Type
/dev/sda1           8192    532480   524289  256M  c W95 FAT32 (LBA)
/dev/sda2         540672  62521343 61980672 29.6G 83 Linux
/dev/sda3       62521344 122138623 59617280 28.4G 83 Linux

The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
Taking a raw partition copy, be prepared this may take long such as 20-30 minutes for a 16 GB SD card
FAILED (raw device copy of /dev/sda2)
FAILED (raw device copy of /dev/sda3)
FAILED (set random UUID)
mount: /storage/syncmount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.
sed: can't read /storage/syncmount/etc/fstab: No such file or directory
umount: /storage/syncmount: not mounted.
OK (dirty bit on fsck /dev/sda2 is normal)
2022-09-04_08:15:48_MDT [openHABian] Checking for default openHABian username:password combination... FAILED
2022-09-04_08:15:50_MDT [openHABian] We hope you got what you came for! See you again soon ;)
openhabian@openhab:~ $ 

I put it in the main slot on the Pi and it didn’t boot up (or at least it didn’t allow me to ssh to it), which is not surprising given the error messages above.

I was running into to some unexpected behavior (like when I tried to use the openhab-cli console command, I would enter user “openhab” and the response was “null”.

I’m sure I could have tried to troubleshoot that, but I decided to see how difficult it would be to start with a clean openhab and restore from a back up (openhabian 5x). I went that route and at least so far, it went smoother than I imagined it would.