Can’t setup SD mirroring

Update (main branch) and try again please.

1 Like

That has now worked! Thank you!

Now disabling SD mirroring no longer works:

2022-01-29_10:50:27_CET [openHABian] Setting up automated SD mirroring and backup... /opt/openhabian/functions/backup.bash: Zeile 493: ${${storageDir:1}//[\/]/\\x2d}.mount: Falsche Substitution.

:frowning: k, I have some questions now… And don’t get it… :slight_smile:

1.) doing the manual SD mirroring with option 54 works… (after I figured out, that one of my SD Cards is a bit smaller than the others, so A to B works, but b to a not)…
when I now try to setup 52 automatic mirroring i get folowing:

I am on openhabian 3.4.3 - Release build

2023-04-22_16:47:51_CEST [openHABian] Setting up automated SD mirroring and backup... Failed to stop storage.mount: Unit storage.mount not loaded.
Taking a raw partition copy, be prepared this may take long such as 20-30 minutes for a 16 GB SD card
FAILED (set random UUID)
OK

sudo lsblk look like this afterwards:

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0 298,1G  0 disk
└─sda1        8:1    0 298,1G  0 part /storage/usbDisk
sdc           8:32   1  29,7G  0 disk
├─sdc1        8:33   1   256M  0 part
└─sdc2        8:34   1  29,5G  0 part
mmcblk0     179:0    0  29,7G  0 disk
├─mmcblk0p1 179:1    0   256M  0 part /boot
└─mmcblk0p2 179:2    0  29,5G  0 part /
zram0       254:0    0   500M  0 disk [SWAP]
zram1       254:1    0   375M  0 disk /opt/zram/zram1
zram2       254:2    0   500M  0 disk /opt/zram/zram2

sudo blkid looks like this afterwards:

/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="AE82-4BC1" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="92802022-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="6d2ff93e-eacd-415c-96d5-4611ad21e05f" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="92802022-02"
/dev/sda1: LABEL="backupDisk" UUID="95a4a23b-0f64-45c4-842b-b3357533f8ad" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="7fac4522-01"
/dev/zram0: LABEL="zram-config0" UUID="27672d1a-98f5-46ed-bfb7-ed391134d3e0" TYPE="swap"
/dev/zram1: UUID="8ff0abd9-9d23-4b9f-9468-8e9170cae0b5" BLOCK_SIZE="4096" TYPE="ext4"
/dev/zram2: UUID="934402fa-9f1c-4185-9925-765978957890" BLOCK_SIZE="4096" TYPE="ext4"
/dev/sdc1: LABEL_FATBOOT="boot" LABEL="boot" UUID="AE82-4BC1" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="ecb911d3-01"
/dev/sdc2: LABEL="rootfs" UUID="6d2ff93e-eacd-415c-96d5-4611ad21e05f" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="ecb911d3-02"

there is a cmdline.txt.bak on the boot partition that still states the old PARTUUID of the original disk and a cmdline.txt stating PARTUUID=-02, where should be stated PARTUUID=ecb911d3-02, thanks to the random UUID, that according to output didn’t work.

As those things mentioned here to solve those issues are pretty old, one should assume, that the solutions from main branch did find their way in the releases…
If not… I have neither idea how to switch to main branch correctly, nor how to turn on debug=maximum

And just before someone tries to call me stupid… I know that switching to main means something to tell git to use another branch as source for /opt/openhabian, but I am not that fit with it git and the cmdline client that i can do it without risking messing up things i don’t want to mess up :slight_smile: with subversion I may be able to do it, even on a git repository as git servers understand requests from subversion clients, but I am pretty sure that will mess up things in the future :slight_smile:

update:
a retry did lead to the exact same result… the cmdline.txt does contain the -02 but not the new random number.

retried today doing a manual SDCard with the openhabian-config tool… Also this resulted in the

FAILED (set random UUID)
OK (dirty bit on fsck /dev/sdc2 is normal)

message.

and it created a new UUID:

/dev/sdc1: LABEL_FATBOOT="boot" LABEL="boot" UUID="AE82-4BC1" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="e5396616-01"
/dev/sdc2: LABEL="rootfs" UUID="6d2ff93e-eacd-415c-96d5-4611ad21e05f" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="e5396616-02"

Once setting the right name to cmdline.txt manually the copy works as it should… I have no idea, where the issue could be :frowning:

Thank you

I tried to setup sd mirroring using openhabian-config (menu entry 53) but “tune2fs /dev/sda2 -U random” failed:

openhabian@smarthome:~ $ sudo openhabian-config
[sudo] password for openhabian:
2023-08-23_19:11:42_CEST [openHABian] Checking for root privileges... OK
2023-08-23_19:11:43_CEST [openHABian] Loading configuration file '/etc/openhabian.conf'... OK
2023-08-23_19:11:43_CEST [openHABian] openHABian configuration tool version: [openHAB]{2023-08-17T19:14:50+02:00}(2ce226c)
2023-08-23_19:11:43_CEST [openHABian] Checking for changes in origin branch openHAB... OK
2023-08-23_19:11:46_CEST [openHABian] Switching to branch openHAB... OK
2023-08-23_19:11:46_CEST [openHABian] Checking openHAB Signing Key expiry.
2023-08-23_19:11:46_CEST [openHABian] Checking expiry date of apt keys... OK
2023-08-23_19:11:46_CEST [openHABian] Checking for updates of openhab_rules_tools for JS Scripting... No update available.
2023-08-23_19:11:52_CEST [openHABian] Adding slightly tuned bash configuration files to system... OK

$ install -m 755 /opt/openhabian/includes/SD/set-partuuid /usr/local/sbin
2023-08-23_19:12:04_CEST [openHABian] Setting up automated SD mirroring and backup...
$ apt-get install --yes -o DPkg::Lock::Timeout= gdisk
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
gdisk is already the newest version (1.0.6-1.1).
0 upgraded, 0 newly installed, 0 to remove and 13 not upgraded.
Failed to stop storage.mount: Unit storage.mount not loaded.
Checking that no-one is using this disk right now ... OK

Disk /dev/sda: 29.72 GiB, 31914983424 bytes, 62333952 sectors
Disk model: SDDR-B531
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: 0x842edbc3

Old situation:

Device     Boot  Start      End  Sectors  Size Id Type
/dev/sda1         8192   532479   524288  256M  c W95 FAT32 (LBA)
/dev/sda2       532480 29892607 29360128   14G 83 Linux

>>> Script header accepted.
>>> Script header accepted.
>>> Script header accepted.
>>> Script header accepted.
>>> Script header accepted.
>>> Created a new DOS disklabel with disk identifier 0xa097fcbe.
/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 GiB.
Partition #2 contains a ext4 signature.
/dev/sda3: Created a new partition 3 of type 'Linux' and of size 14.9 GiB.
/dev/sda4: Done.

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

Device     Boot    Start      End  Sectors  Size Id Type
/dev/sda1           8192   532479   524288  256M  c W95 FAT32 (LBA)
/dev/sda2         532480 29892607 29360128   14G 83 Linux
/dev/sda3       31116288 62333951 31217664 14.9G 83 Linux

The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

$ mke2fs -F -t ext4 /dev/sda3
mke2fs 1.46.2 (28-Feb-2021)
Creating filesystem with 3902208 4k blocks and 977280 inodes
Filesystem UUID: 0cd881cc-d215-4952-931c-0c8b689c9eff
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done


$ chmod 644 /etc/systemd/system/storage.mount

$ systemctl -q daemon-reload

$ systemctl enable --now storage.mount
Created symlink /etc/systemd/system/local-fs.target.wants/storage.mount → /etc/systemd/system/storage.mount.
Created symlink /etc/systemd/system/zram-config.service.wants/storage.mount → /etc/systemd/system/storage.mount.
Taking a raw partition copy, be prepared this may take long such as 20-30 minutes for a 16 GB SD card

$ dd if=/dev/mmcblk0p1 bs=1M of=/dev/sda1 status=progress
252706816 bytes (253 MB, 241 MiB) copied, 9 s, 28.0 MB/s
256+0 records in
256+0 records out
268435456 bytes (268 MB, 256 MiB) copied, 10.4225 s, 25.8 MB/s

$ dd if=/dev/mmcblk0p2 bs=1M of=/dev/sda2 status=progress
14991491072 bytes (15 GB, 14 GiB) copied, 459 s, 32.7 MB/s
14336+0 records in
14336+0 records out
15032385536 bytes (15 GB, 14 GiB) copied, 461.608 s, 32.6 MB/s

$ e2fsck -y /dev/sda2
e2fsck 1.46.2 (28-Feb-2021)
/dev/sda2: clean, 161126/917504 files, 1346760/3670016 blocks

$ tune2fs /dev/sda2 -U random
tune2fs 1.46.2 (28-Feb-2021)

This operation requires a freshly checked filesystem.

Please run e2fsck -f on the filesystem.

FAILED (set random UUID)

$ fsck -y -t ext4 /dev/sda2
fsck from util-linux 2.36.1
e2fsck 1.46.2 (28-Feb-2021)
/dev/sda2: clean, 161126/917504 files, 1346760/3670016 blocks

$ install -m 644 -t /etc/systemd/system /opt/openhabian/includes/SD/sdrawcopy.timer /opt/openhabian/includes/SD/sdrsync.timer

$ install -m 755 /opt/openhabian/includes/SD/mirror_SD /usr/local/sbin

$ systemctl -q daemon-reload

$ systemctl enable --now sdrawcopy.timer sdrsync.timer
Created symlink /etc/systemd/system/timers.target.wants/sdrawcopy.timer → /etc/systemd/system/sdrawcopy.timer.
Created symlink /etc/systemd/system/timers.target.wants/sdrsync.timer → /etc/systemd/system/sdrsync.timer.
OK
2023-08-23_19:20:27_CEST [openHABian] Checking for default openHABian username:password combination... OK
2023-08-23_19:20:27_CEST [openHABian] We hope you got what you came for! See you again soon ;)

As a result, booting from the mirrored sd card fails.
Is there an option “-f” missing in “e2fsck -y /dev/sda2”?

Does anybody have an idea how to fix it?

Hmm. the setup of SD-mirroring with the openhabian-config tool generally does everything right, including changing the partuuid of the dd partition…

If this fails this can lead to following “strange behaviour” especially if the (new) option in rasbian is activated to boot from the USB instead of from the internal SD Card.

If set-partuuid fails, then both partitions have the same uuid and it is somehow “luck” which partition gets mounted during the boot, eventually even none gets mounted.

If the sed on the cmdline.txt fails, the copy still tries to mount the partition from the original SD Card, instead of the copied one…

So u should check partUUID of original and of copy and the entrie in cmdline.txt on both boot partitons, if that makes sense…

In general I suspect that it is a rights problem and suggest to restor the original permissions with openhabian-config and then setup the Sd mirroring.

with blkid u can check the UUIDs of the orginal and the copied disk:

/dev/mmcblk0p1: LABEL_FATBOOT="bootfs" LABEL="bootfs" UUID="9E81-4F92" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="088703fc-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="cf2895ca-6dc2-4797-8040-f76ba1508f41" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="088703fc-02"
/dev/sdb1: LABEL_FATBOOT="bootfs" LABEL="bootfs" UUID="9E81-4F92" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="89ab8844-01"
/dev/sdb2: LABEL="rootfs" UUID="cf2895ca-6dc2-4797-8040-f76ba1508f41" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="89ab8844-02"

Those should be different as here.

Then check the cmdline.txt, of both boot partitons, if they state the correct UUID… In case of my example, the cmdline.txt of /dev/mmcblk0p1 should state “088703fc-02”
And the cmdline.txt of /dev/sdb2 should state “089ab8844-02”

If not, u could first of all correct it manually and seconfd of all u know what went wrong and where to search.

furthermore u should check the /etc/fstab of both root partitons, if they state the respective correct PARTUUID to mount…

In my case for the mmcblk0 device following would be correct:

proc            /proc           proc    defaults          0       0
PARTUUID=088703fc-01  /boot           vfat    defaults          0       2
PARTUUID=088703fc-02  /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

and for the card in the card reader at sdb it should be:

proc            /proc           proc    defaults          0       0
PARTUUID=89ab8844-01  /boot           vfat    defaults          0       2
PARTUUID=89ab8844-02  /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

I hope u get the concept… And read write permissions on those four files may prevent the correct changing of the PARTUUID

I have been running the same issues (OH 3.2.0) and PARTUUID is corrupted for the mirrored SD at both cmdline.txt and /etc/fstab (part before dash). To fix it, insert the card in a running system, check PARTUUID with blkid (usually sd cards are labelled as sda), then mount both sd partitions (e.g. sda1 for /boot and sda2 for /) and correct the files.