Keep filesystem labels #101
Conversation
Previously, e2label was used, but that only works for ext partitions. Using lsblk allows showing the filesystem labels for all filesystems supported by the kernel.
Now labels are retrieved for all destination partitions, there is no longer any point in separately retrieving the destination root label, just use the previously retrieved label.
Instead of only setting FS labels on ext partitions when specified with the --label-partitions option and leave all other partitions unlabeled, this tries to copy the source filesystem labels to the destination where possible. Setting labels requires filesystem-specific commands or mkfs options, so not all filesystems are supported. For changing labels on existing partitions, only ext and fat partitions are supported. For mkfs a few more are supported, though these are probably not used in practice. This also refactors some of the code, introducing a `mkfs_label()` and `change_label()` function to prevent having to duplicate the filesystem-type checking code. This fixes billw2#100.
|
This allowed me to clone Ubuntu 21.10, which I was unable to do previously. Thanks! |
This makes it non-interactive and prevents the script from silently
hanging when parted finds something weird, e.g.:
$ sudo rpi-clone /dev/sda
Warning: The driver descriptor says the physical block size is 2048 bytes, but Linux says it is 512 bytes.
This just hangs, because parted is waiting for an answer:
$ sudo parted -m /dev/sda unit s print
Warning: The driver descriptor says the physical block size is 2048 bytes, but Linux says it is 512 bytes.
Ignore/Cancel?
matthijskooijman
force-pushed
the
keep-fs-labels
branch
from
145200d to
28740b4
Compare
|
I've added two more commits just now:
|
It seems that parted can force a partition scan (observed on a removable USB disk), which temporaly clears the filesystem labels from lsblk output. To prevent this, call udevadm settle to wait until all udev events are processed before continuing.
matthijskooijman
force-pushed
the
keep-fs-labels
branch
from
28740b4 to
0ca374d
Compare
|
I have used this code to make a bootable clone of Ubuntu 21.10 thank you. I did run into another problem however. If I leave the clone attached to the USB drive, the pi actually boots from the clone and not the original! When I try to do an incremental update: I verified that indeed the pi always boots from the sd card clone attached to the USB rather than the card attached directly to the pi's sd card slot. I also verified that my pi is set to boot from SD but it seems that doesn't know which SD to boot from: BOOT_ORDER=0x1 which means SD CARD: @eddiem5 ran into the same problem here: #106 but @robustini solution was to use an old version of rpi-clone which will not work as I need your code changes. Is there anyway around this so I can update my clone with incremental updates? |
I'm pretty sure that the rpi will boot from its internal SD when configured like this, the rpi boot code probably doesn't even know that your USB card reader is an SD card (it's just "mass storage"). What I suspect might be happening, is that the old and new root filesystems have kept the same (PART)UUID, and the initrd is started from the real SD card, which then looks for the root filesystem based on a UUID, finds both the original and the clone and then picks the wrong one. There is code to fix this by changing and updating the PARTUUID, but maybe your Ubuntu is using UUID (filesystem UUID) rather than PARTUUID (partition UUID), which is not supported yet. If so, #140 might be helpful for you. Also, I think that none of this is really related to this particular PR (I actually think things would have worked the same with an unpatched master), so if this probably persists, it might be better to open up a new issue rather than continuing this discussion here. |
|
I've resubmitted this PR in a more actively maintained fork: geerlingguy#16 |
This makes some changes to display and preserve all filesystem labels rather than just for ext filesystems.
Displaying of labels should be supported for any filesystem supported by the kernel (using
lsblk), while copying labels is supported for a limited set of filesystems (just ext and fat for existing filesystems, a few more for new filesystems).See the commit messages for some more details.