Re: How do I clone a Debian Distro from a 32Gb Class 10 MicroSD card to a 16Gb Class 10 A1 MicroSD card?
Hi.
On Thu, Sep 30, 2021 at 04:26:18PM +0100, Myron wrote:
> Armbian's website was not clear which one was "Debian" and which
> one was "Ubuntu".
Well, Armbian is a separate distribution which is not Debian and not
Ubuntu. Whichever distribution they choose to "base" their userland
hardly matters in this context.
> > If you're using dump/restore for this - there are none. Just make sure
> > you keep filesystem's UUID the same.
> > If, for instance, you'd use tar(1) or cp(1) to copy files - some
> > filesystem-specific extended attributes would be lost.
> > It would not render the OS unbootable (or unusable), but it would lead
> > to some funny breakage (like /bin/ping is working for root only).
>
> Here is where my mistake is costing me a little. Where and how do I get
> dump and restore?
apt install dump
Simple as that.
Again, it's totally possible to use any sufficiently modern x86 Linux
distribution for this task you have. And a SD card reader, of course.
> Yes, I have the USB-TTL cable ready and waiting. So far it's got me out of
> a few I've-locked-myself-out-again situations leaving the only option to
> use the USB-TTL.
>
> There is something I'm reading about using resize2fs and fdisk to shrink
> the file system and partition, but I don't exactly understand the erasure
> and re-creation of the partition using fdisk.
That's the exact reason I tend to use LVM whenever possible. Enlarging a
conventional partition has it's share of quirks, but reducing the
partition is the definition of pain.
> Does it mean that if I remove the partition and then re-create the
> partition from the same starting block as the old partition, that the data
> on the MicroSD card will not actually be erased, but will be encapsulated
> by the new smaller partition?
Haha. You won't be able to do that, Red Hat took care of it back in 3.2
kernel days. You cannot cannot change a partition layout on a block
device which has any filesystem mounted (or swap is used), the kernel
won't permit you to do that. Red Hat deserved and deserves whatever
things IBM is doing to them now, let's leave it at this.
Moreover, even if was possible, you'd need to shrink the filesystem
first, or you will damage it. And shrinking a mounted ext4 is impossible.
> Does that make any sense?
Back in good old days of 2.6 kernel that was the way of doing it, more
or less. But no more.
> I know. It's not advisable to resize a live root partition.
It's plain and downright impossible, unless you're using LVM. And even
then it's filesystem-specific, which excludes ext4 for instance. Sorry
to bring you the bad news.
> Maybe create a live boot Linux CD or USB with Gparted on it and do it
> that way?
On SBC itself? Convincing u-boot to perform a boot from CDROM is
something that they designate Adult Only Entertainment :) And we're
trying to keep this list PG-13 clean here :)
Being serious, I do not even know where to begin patching u-boot for
this - you'll need ISO9660/UDF support, more-or-less complete SCSI
command set implementation and a good chunk of code they deliberately
keep at xorriso, and I'm sure I'm missing something here.
Or have you mean a bystander PC? Given a card reader all one actually
needs is dump/restore, parted and dd. A live distribution surely has all
this, but it's an overkill.
Much more realistic way of doing this is simply boot the needed "rescue"
kernel, devicetree and initrd via TFTP. Most variants of u-boot I've
encountered so far have the ability to boot over the network. I'm pretty
sure that Armbian does not disable that (although I do not have that
exact SBC that you have).
Obviously it requires TFTP server, dnsmasq will do just fine.
Reco
Reply to: