On Sat, Sep 18, 2021 at 08:01:34AM -0400, The Wanderer wrote: > On 2021-09-18 at 07:53, Reco wrote: > >> No clue how to do this with Linux. > > > > 1) Plug-in source card, use dump(8) to backup the contents of its > > filesystem. > > 2) Plug-in target card, create appropriate partition(s) on it. > > 3) Make the needed amount of filesystems on a target SD card. > > For ext4 you'll want to use -U option of mkfs to clone filesystem UUIDs > > (i.e. UUID on the target card must be the same compared to the source > > one). > > 4) Use restore(8) to recreate filesystem(s) contents on a target card. > > 5) Unmount filesystems made on a target card. > > Will this really be enough?
OP specified that it's a >> single board system-on-a-chip computer So it is usually enough. > I'd expect that you'd also need to bring across the bootability > configuration, which - depending on how it's set up on that particular > device - might well require additional steps. If it's a really broken SBC, like, for instance Ordroid N2 or Exynos 5422 (aka Odroid XU4) - then yes, you'll have to also write about 1Mb of non-free blobs at the start of the card, and without overwriting any partition contents. > For hard-drive installs you're likely to have a GRUB installation, which > wouldn't be brought across by a measure like this. I doubt that GRUB will come into play in this scenario. You probably meant u-boot. GRUB does not have ARM port at all, unless it's an ARM64 server we're talking about here. And even then it'll be GRUB-EFI, which merely requires copying grub.aarch64 to EFI FAT fs. > For a SD-card-based install I'm not sure, but I'd be a bit surprised > to learn that no such non-filesystem-based configuration is necessary. A canonical example - Raspberry Pi. You just have to clone partition UUIDs, and fill first partition with Broadcom blobs. That's it, nothing more complex is required. RPi have their share of deficiencies and simply are broken by design in some regards, but the their boot process is as straightforward as possible. Reco
