[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How do I clone a Debian Distro from a 32Gb Class 10 MicroSD card to a 16Gb Class 10 A1 MicroSD card?



On Thu, Sep 30, 2021 at 09:51:20PM +0300, Reco wrote:
> 	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.
> 
> 

You have two cards: one slow one, one faster one which is smaller.

If you've not got too much invested and you have a blank card:

Go and get the two parts of a filesystem for SD card you'll need from
https://deb.debian.org/debian/dists/stable/main/installer-armhf/current/images/netboot/SD-card-images/

https://deb.debian.org/debian/dists/stable/main/installer-armhf/current/images/netboot/SD-card-images/firmware.BananaPro.img.gz and

https://deb.debian.org/debian/dists/stable/main/installer-armhf/current/images/netboot/SD-card-images/partition.img.gz

Then follow:

https://wiki.debian.org/InstallingDebianOn/Allwinner

Look down the page for the zcat line

So something like 

zcat firmware.BananaPro.img.gz partition.img.gz > image.img

then use dd to write image.img to the SD card.

At some future stage, you can mount the Armbian SD card to copy off any
files you need.

It's honestly going to be a lot faster than messing around with trying
to work out how to resize SD card filessytems if you're not sure.

If it works, you've not lost data at all on the armbian install that you
have now.

Hope this helps, with every good wish as ever,

Andy Cater

z

> > > 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: