Minor issue - e2label

[bclaymiles]

I'm using f2fs on one of my pi's, and each time rpi-clone runs, it reports:

Editing /mnt/clone/etc/fstab PARTUUID to use ea0b56b4
e2label: Bad magic number in super-block while trying to open /dev/sda2

Which makes sense, since you can't add an extX label to an f2fs filesystem. I've tested the backups, they work fine, so this is a cosmetic error at worst.

[bclaymiles]

I should probably add - the script is invoked nightly as:
/usr/local/sbin/rpi-clone -u -v sda
So I'm not declaring that a label should be written. Likewise, the logic in the script appears to suggest that it should not be trying to write a label on a non ext filesystem, which is why this appears to be a bug. However, I'm not a coder, so my interpretation of what the script is doing may be faulty.

[matthijskooijman]

Seems the problem is that the code assumes the rootfs is ext. This is fixed as a side effect of my PR #16.

[aslak47]

I have been using rpi-clone for a system with btrfs. It works, but it complains about using e2label, and I cannot see that this is handled by PR #16.

[matthijskooijman]

@aslak47 Did you try this?

It's been a while since I wrote it, but IIRC the PR changes all uses of e2label to read labels from the source disk to use lsblk instead (so it will work with any filesystem that lsblk or maybe the kernel supports), and writing labels to filesystems is now done by a change_label function that checks the filesystem type and only calls e2label for ext filesystems (or fatlabel for fat filesystems).

So AFAICS, complaints about e2label should be gone with that label applied. However, that PR will not causes labels for filesystems other than ext or FAT to be copied, maybe that is what you mean when you say "not handled"?

[aslak47]

No, I did not try this.
With btrfs you cannot use e2label to set new label value. It should be done like this:
From a command line, use: "sudo btrfs filesystem label <mountpoint> <newlabel>" when the filesystem is mounted.
Else, if unmounted, use: "sudo btrfs filesystem label <device> <newlabel>"

[matthijskooijman]

Yes, so with btrfs no labels will be copied, but the clone should otherwise work with my PR applied (unlike without my PR applied). Also copying the btrfs labels should be easy to add on top of my PR (just add an extra case in the change_label function), but I have not much interest in this (and no way to test it). But if you try it and push a commit for it somewhere, I can add it to my PR.

[framps]

Also copying the btrfs labels should be easy to add on top of my PR (just add an extra case in the change_label function), but I have not much interest in this (and no way to test it).

I agree with you. If there is a need for btrfs label support somebody who runs a btrfs system should create a PR and execute the required tests.