openHABIAN SD mirroring 'FAILED (e2fsck)'

I am using the openHABIAN config menu option 53 to (try to) set up SD disk mirroring; on the one hand it looks like the data has been copied to the SD card; but on the other hand I see a ‘FAILED (e2fck)’ message in the console. Is this a real error, and if so, how to solve it?

I am on OH 4.2M latest, and the respective latest openHABIAN config tool. The target is a 64GB SD card.

Can’t tell from that output. Try booting from the mirror to find out .

The more interesting error is at the top though. Sounds like your mirror target is smaller than the origin.
The rest might be just a consequence.

PS no screnshots please next time

Actually that is NOT the case. Both SDs are 64GB…

Why not?

but not exactly same size else you wouldn’t see that

forum rules. cannot search or quote

Ok. Problem is that my console app does not support text copy, so screenshot is the only way to do it.

If anything I think that the source OS is on a smaller SD partition than the mirror target SD. Both are 64GB physically but I think the source has actually two partitions of 32GB (one with the OH file system, and the other empty). So I would have expected the SD mirror application could easily mirror from the 32GB partition to the larger target SD.

well use debugmode maximum in openhabian.conf to get to see what exactly happens.
Then again that won’t change a thing about how it’s meant and implemented.
Standard openHABian does not have such a second partition so it’s built to compare disks. Please read the docs on supported hw and modifying os before raising expectations like this.

Please note that I am not ‘raising expectations’ just asking a question. Nevertheless my hw is a fully standard RPi4 and running fully compliant sw; the docs do not say anything about the partitioning of the SD card. However I guess your comment means that a split partition SD card is not supported. => Perhaps such sentence should be added to the docs? => Do you want me to write a PR?

Well. There is a tricky and sensitive but huge fundamental issue behind this apparently simple foreground question we ever keep hitting with implementing and documenting my/our work.
The ‘default anything’ approach you are after doesn’t work. That would mean to allow for and support everything in the first place and document ‘X or Y is not supported’ and ‘you may not do this or that’ or even implement code checks to prevent execution and raise an error msg when users try doing invalid stuff.

There’s just too many ideas users come up with and believe to be allowed/supported or anyway ‘standard’ (implying it’s ‘natural’ it would need to work) to think of and check/document against, let alone the amount of work that would mean for us.
We’re ever struggling with user expectations (no matter if im- or explicit) like these.
To my knowledge you’re the first to attempt this split SD approach, and I really wonder how you came to retroactively modify partitioning after initial install. Sounds weird, and you cannot
expect a developer to foresee anyone will ever attempt this and cater for.

openHABian design philosophy, from implementation to docs, is to state the context you may use it in. And then we document how to use the available features.
Once one properly thinks about it, that also implies:
If something is not explicitly mentioned in the docs, it’s not supported and not supposed to work.
If something doesn’t work the way you expected it to, it’s not supposed to (short of bugs of course).
If we were to strictly interpret this like in a legal matter, you have not met the prerequisites and sorta violated the docs section I’ve referenced that also says something like ‘don’t mess with the OS part of openHABian or if you do, at least don’t ask for help in doing so’.

I guess that this thread is probably not going anywhere. But for the avoidance of doubt let me set the record straight:

  1. I am NOT asking for support. I am asking a question on this forum.
  2. I have NOT messed with the software.
  3. Insofar as you may choose to call it ‘messing’, the ONLY difference is that my main SD card is partioned and formatted as a 32GB card (so it is visible to Linux as a 32GB card. The fact that it has a second empty and unformatted partition behind – which is therefore not visible to Linux – is IMHO NOT a ‘violation’ of anything.

… but anyway, as I said before, I guess this thread is going nowhere…

… and … BTW … my old original SD was 32GB, which I cloned to a 64GB SD … so it leaves the second half of the SD unused; it is to all intents and purposes a 32 GB SD…

So, just for the avoidance of doubt, I just checked it using two IDENTICAL factory pure SD cards from the same manufacturer and with the same size (see fdisk below). i.e. My test system is now absolutely 100% fully compliant to the OH openHABIAN stipulations. And it still produces a ‘FAILED’ error. Just so you know.

openhabian@openhabian:~ $ sudo fdisk -l

Disk /dev/mmcblk0: 59.48 GiB, 63864569856 bytes, 124735488 sectors
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: 0x05aa9a3c

Device         Boot  Start       End   Sectors  Size Id Type
/dev/mmcblk0p1        8192    532479    524288  256M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      532480 124735487 124203008 59.2G 83 Linux

Disk /dev/sda: 59.48 GiB, 63864569856 bytes, 124735488 sectors
Disk model: MassStorageClass
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: 0x4537fef1

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

openhabian@openhabian:~ $ sudo openhabian-config

2024-06-16_10:02:53_BST [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 (e2fsck)

There we go. That’s the likely explanation how your cloning caused the problem.
When you properly install openHABian from image, it repartitions the card.
So without later intervention, it’s safe to assume that disk size == partition size.
That’s where your clone move fooled openHABian code. Without, it would have worked properly.
So without that intervention or if you had mentioned that in the first place, we would not have needed this thread. There’s even a huge warning in the docs not to attempt DIY mirroring.
Sorry for restating but I find ‘messing’ is quite an appropriate term. It’s what caused the need to spend time to analyze, yours and mine.

Well, might be cosmetic or not. Without any proper fullsize debug log to analyse I cannot seriously comment on that other than that when properly setup, the mirroring feature is working for a lot of people.
If I were you I’d reinstall latest openHABian to another SD, using the full size for a single partition, then import my old config (see also initialconfig option in docs). That’s just a matter of minutes.

As I understood, that‘s what Andrew just did with two identical new cards.

1 Like

@mstormi I think you are being offensive.

Also see this…

Attached below is the log file…

mirror-error.txt (49.0 KB)

Also here is the result of running the e2fsck command

openhabian@openhabian:~ $ sudo e2fsck /dev/sda1
[sudo] password for openhabian: 
e2fsck 1.46.2 (28-Feb-2021)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sda1

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
    e2fsck -b 32768 <device>

/dev/sda1 contains a vfat file system labelled 'bootfs'

As I was not making much progress in this thread, let me attempt to answer my own question so that others may potentially benefit…

The openHABIAN SD mirroring and SD copy menu command scripts first make a block-by-block copy between OH source SD card and the target SD card and then they run the ‘fsck’ utility to check that the target SD card file system is Ok. The ‘FAILED (e2fsck)’ message indicates that the target SD card file system was not Ok i.e. corrupted.

Note: if the ‘FAILED (e2fsck)’ occurs, it probably means that the actual block-by-block copy had already finished.

There could be two causes of the problem:

  1. The source SD card is corrupt, and copied verbatim to the target card.
  2. The copy process caused a corruption of the target card.

Note: I encountered the error both on used SD cards, and on brand new cards, so cause 1. and 2. seem equally likely.

The solution is to run the Linux ‘fsck’ utility to check and repair the target SD card. You may need to also run the Linux ‘e2fsck’ utility. This will fix the target.

And if the cause had been 1. above, then the source SD card may also be corrupted; in which case the solution is to shut down the system, swap the source and target SD cards, reboot, and then run the Linux ‘fsck’ / ‘e2fsck’ utilities again on the respective swapped SD card.