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

[Myron]

Never done this one with Linux before.  I know that there is less than 16Gb of data written to the Class 10 32Gb MicroSD card which is used as the primary system storage on a single board system-on-a-chip computer.  What I'm after is getting a 16 Gb Class 10 A1 MicroSD card and clone the entire system from the 32Gb card to the 16Gb card.

What I'm after is when I start the SOC computer from the replacement 16Gv Class 10 A1 MicroSD card, it will just start like there have been no changes, well, apart from there being 16Gb storage and not slower 32Gb storage.

This is relatively easy to do on Windows.  No clue how to do this with Linux.

[Reco]

Hi.

On Sat, Sep 18, 2021 at 12:35:13PM +0100, Myron wrote:
> This is relatively easy to do on Windows.

This is true only if you're using that sad excuse for a filesystem
called NTFS.

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

Reco

[The Wanderer]

Will this really be 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.

For hard-drive installs you're likely to have a GRUB installation, which
wouldn't be brought across by a measure like this. 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.

--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

[Reco]

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

[The Wanderer]

On 2021-09-18 at 08:34, Reco wrote:

> On Sat, Sep 18, 2021 at 08:01:34AM -0400, The Wanderer wrote:
>
>> On 2021-09-18 at 07:53, Reco wrote:

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

<snip>

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

No - I really don't know enough about this type of context to be able to
make that connection. I was mentioning GRUB as an example of the
non-filesystem-based boot configuration that's needed in the hard-drive
case; since this isn't the hard-drive case, if any such configuration is
needed, it would probably be something other than GRUB.

I'm used to seeing ISOLINUX for bootable CDs, and something (I've never
been sure what) for bootable USB drives, but have/had never learned what
was/is used for bootability on SD cards.

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

So this isn't really a concern in practice, and I've learned something
today. Good to know!

[Reco]

On Sat, Sep 18, 2021 at 08:39:41AM -0400, The Wanderer wrote:
> I'm used to seeing ISOLINUX for bootable CDs, and something (I've never
> been sure what) for bootable USB drives, but have/had never learned what
> was/is used for bootability on SD cards.

It's simple. First, you look at the processor's architecture.

GRUB is used on x86, modern POWER (think IBM p-Series) and ARM64 (but
you have to use a server hardware for that).
For x86 there's also syslinux, lilo, and direct UEFI kernel boot (aka EFIStub).
Older POWER (and PowerPCs) used kboot, but I have no personal experience
with them.
u-boot is ARM and ARM64, maybe RISC-V (no personal experience with that).
silo is for UltraSPARCs.

I even do not want to know what they're using on MIPS, HPPA or Itanium
for boot, but there's definitely something.


Next you look at the platform-specific detail.

For x86 the biggest (and only) choice you have is between BIOS and UEFI.
For ARM it's somewhat rough, but manageable if you happen to have an
appropriate datasheet. Theoretically, each SOC has its own, unique way of
booting. Practically acquiring right u-boot configuration and patches is
all it takes.

UltraSPARCs and modern POWERs are easy (you have no choice, that is),
but good luck on getting the hardware. It's costly, and barring that
Talos thing comes in the form of a typical rack-mount server.


And whatever you're using as a boot media does not matter at all, unless
you're doing something very exotic, like [1].

Reco

[1] https://github.com/raspberrypi/linux/issues/3178

[Andrew M.A. Cater]

On Sat, Sep 18, 2021 at 12:35:13PM +0100, Myron wrote:

You might find it easier to do a reinstall and then copy any data over -
it will be at least as quick as shrinking the first data disk and using
dd to copy the data from one SD card to the other.

If you have any particular software that you must have - get a listing of
what's on the first card and copy that list over as the list of packages you
install

dpkg --get-selections > myfile

dpkg --set-selections < myfile

will probably do it followed by an apt update.

Then it's just a question fo copying over personal files and config files
from the old SD card.

All the very best, as ever,

Andy Cater

[David Christensen]

Backup your data. I would take a raw binary image of the entire 32 GB
MicroSD card as well.


My guess is that you should resize the contents of the 32 GB MicroSD
card to fit onto the 16 GB MicroSD card, and then clone.


But, the devil is in the details and it would be helpful if we had more
information...


What is the make and model of your "single board system-on-a-chip
computer" (SBC)? What CPU, memory, or other options does it have? What
is the technical support URL?


Is the SBC connected to a keyboard, mouse, and monitor, to a serial
console, or to some other console? Can you SSH into it?


How did you create a working Debian (?) GNU/Linux instance on the 32 GB
MicroSD card? If you followed some instructions, what is the URL?


On the 32 GB MicroSD card Debian instance, please login as root, run the
following commands, and reply with the complete console session --
prompts, commands entered, output obtained:

# /bin/bash -l

# export PS1='\n\D{%Y-%m-%d %H:%M:%S} \u@\h \w\n\$ '

# cat /etc/debian_version ; uname -a

# egrep 'vendor_id|model name' /proc/cpuinfo | head -n 2

# grep MemTotal /proc/meminfo

# fdisk -l


David

[Andrei POPESCU]

Do you have another Linux (capable) system to work with? In this case
try GParted, possibly from a live Linux if all your other systems are
Windows:

https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/11.0.0-live+nonfree/amd64/iso-hybrid/

If all you have to work with is the Linux system itself you need to do
an "online resize" of the filesystem(s) and then adjust the partition
table to match[1].

Before starting the operation make sure you are shrinking to the correct
size, because many SD cards are slightly smaller than advertised. If in
doubt shrink more, copy and then grow (online grow is mostly the same as
shrink -- in reverse order -- and will be much faster as there is no
data to move around).

Please post the full output of:

fdisk -l
lsblk -f

(use sudo or root as needed)

with both SD cards plugged in case you need assistance with the manual
method.

[1] yes, the partition and the filesystem within it can be adjusted
independently, even for NTFS. The graphical tools (GParted included)
just show this to be one operation.

Hope this helps,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser

[Myron]

This is on a Lemaker BananaPro SoC board running on Armbian. There is one partition on it and it's EXT4 that takes up the entire 32Gb MicroSD card.  Not NTFS.  There are some more replies on this thread I need to read after I send this, but this SoC card boots off this MicroSD card and the entire root filesystem is on it.  The MicroSD card is the boot and system drive.

[Myron]

It's Armbian Focal on a Lemaker BananaPro AllWinner ARM A20 SoC device. Boots off the card and is also the root filesystem.  No other physical storage is attached to.

[Myron]

Hello David.  As requested . . . .

2021-09-27 13:49:50 root@loki ~

# cat /etc/debian_version ; uname -a

bullseye/sid
Linux loki 5.10.60-sunxi #21.08.2 SMP Tue Sep 14 16:28:44 UTC 2021 armv7l armv7l armv7l GNU/Linux

2021-09-27 13:50:06 root@loki ~

# egrep 'vendor_id|model name' /proc/cpuinfo | head -n 2

model name      : ARMv7 Processor rev 4 (v7l)
model name      : ARMv7 Processor rev 4 (v7l)

2021-09-27 13:50:53 root@loki ~
# fdisk -l
Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram1: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram2: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram3: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/mmcblk0: 29.74 GiB, 31914983424 bytes, 62333952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe069b87e

Device         Boot Start      End  Sectors  Size Id Type
/dev/mmcblk0p1       8192 61702143 61693952 29.4G 83 Linux


Disk /dev/zram0: 483.64 MiB, 507117568 bytes, 123808 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/zram1: 50 MiB, 52428800 bytes, 12800 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

[Myron]

Hello Andei.  As requested.  What I've got running Armbian Linux on is . . .

https://linux-sunxi.org/LeMaker_Banana_Pro

root@loki:~# fdisk -l

root@loki:~# lsblk -f
NAME        FSTYPE LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINT
mmcblk0
└─mmcblk0p1 ext4         dffd2ee5-5480-480b-9853-7884f8ba5e47     23G    18% /
zram0                                                                        [SWAP]
zram1                                                           21.7M    48% /var/log
root@loki:~#

[Reco]

Hi.

Please do not top-post.

On Mon, Sep 27, 2021 at 01:36:59PM +0100, Myron wrote:
> This is on a Lemaker BananaPro SoC board running on Armbian.

I.e. - not Debian, but Debian derivative.
In this particular case it actually matters.

> There is one partition on it and it's EXT4 that takes up the entire 32Gb MicroSD card.

1) Locate u-boot install script on a source filesystem, usually it is
/usr/lib/u-boot/platform_install.sh.
Read it, understand it. It's a fancy wrapper to dd(1).

2) Proceed with copying filesystem contents as outlined in previous
e-mail.

3) Run /usr/lib/u-boot/platform_install.sh on a target SD card.

Reco

[Myron]

Oops.  I didn't fully answer all the questions,

On Sat, 18 Sept 2021 at 20:20, David Christensen <dpch...@holgerdanske.com> wrote:

On 9/18/21 4:35 AM, Myron wrote:
> Never done this one with Linux before.  I know that there is less than 16Gb
> of data written to the Class 10 32Gb MicroSD card which is used as the
> primary system storage on a single board system-on-a-chip computer.  What
> I'm after is getting a 16 Gb Class 10 A1 MicroSD card and clone the entire
> system from the 32Gb card to the 16Gb card.
>
> What I'm after is when I start the SOC computer from the replacement 16Gv
> Class 10 A1 MicroSD card, it will just start like there have been no
> changes, well, apart from there being 16Gb storage and not slower 32Gb
> storage.
>
> This is relatively easy to do on Windows.  No clue how to do this with
> Linux.
>


Backup your data.  I would take a raw binary image of the entire 32 GB
MicroSD card as well.

Done that.  Sector-by-sector back-up.

My guess is that you should resize the contents of the 32 GB MicroSD
card to fit onto the 16 GB MicroSD card, and then clone.

Yes. This is how I would like to do this. Is it possible to do this while the SBC is online?  It resized the image online on first install from about a 4Gb partition to a 32Gb partition. It was a pre-built image. Download, write image to SD card, insert card in SBC, turn on and follow instructions.

 

But, the devil is in the details and it would be helpful if we had more
information...


What is the make and model of your "single board system-on-a-chip
computer" (SBC)?  What CPU, memory, or other options does it have?  What
is the technical support URL?

 

http://www.lemaker.org/product-bananapro-index.html

I followed the Armbian link as it's the only up-to-date and supported distro on offer.

Is the SBC connected to a keyboard, mouse, and monitor, to a serial
console, or to some other console?  Can you SSH into it?

Yep. I can SSH into it.  I have a USB to 3v3 TTL RS232 board and can connect to the serial debug port and also the ability to connect USB keyboard and mouse and a HDMI monitor.

 

How did you create a working Debian (?) GNU/Linux instance on the 32 GB
MicroSD card?  If you followed some instructions, what is the URL?

 

From here: https://www.armbian.com/banana-pi-pro/

Followed instructions when the USB to 3v3 TTL RS232 board arrived as it appears this is how to start and complete the initial start-up otherwise the SBC appears to be dead.If it's in the instructions then I missed that and nearly threw the SBC in the trash.  Glad I didn't as it appears to be quite reliable.

 

On the 32 GB MicroSD card Debian instance, please login as root, run the
following commands, and reply with the complete console session --
prompts, commands entered, output obtained:

# /bin/bash -l
# export PS1='\n\D{%Y-%m-%d %H:%M:%S} \u@\h \w\n\$ '
# cat /etc/debian_version ; uname -a
# egrep 'vendor_id|model name' /proc/cpuinfo | head -n 2
# grep MemTotal /proc/meminfo
# fdisk -l

[[[

root@loki:~# /bin/bash -l
Here lie dragons. Careful where you tread!
root@loki:~# export PS1='\n\D{%Y-%m-%d %H:%M:%S} \u@\h \w\n\$ '

2021-09-27 20:19:28 root@loki ~

# cat /etc/debian_version ; uname -a

bullseye/sid
Linux loki 5.10.60-sunxi #21.08.2 SMP Tue Sep 14 16:28:44 UTC 2021 armv7l armv7l armv7l GNU/Linux

2021-09-27 20:19:42 root@loki ~

# egrep 'vendor_id|model name' /proc/cpuinfo | head -n 2

model name      : ARMv7 Processor rev 4 (v7l)
model name      : ARMv7 Processor rev 4 (v7l)

2021-09-27 20:19:50 root@loki ~
# grep MemTotal /proc/meminfo
MemTotal:         990484 kB

2021-09-27 20:19:59 root@loki ~

Disk /dev/zram0: 483.65 MiB, 507129856 bytes, 123811 sectors

Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/zram1: 50 MiB, 52428800 bytes, 12800 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

2021-09-27 20:20:09 root@loki ~
#

]]]

 

Actually, here is a lot more technical information about this SBC:  Output from 'sudo armbianmonitor -u' = http://ix.io/3A1l

David

I'm guessing if the file system can be expanded online then it should be possible to shrink a partition online?

Any help that I'll be able to understand would be very much welcome.

Myron

[Myron]

Rico, I now realise I started with Ubuntu thinking that Focal was another release od Debian and now gone doen the route of getting that Linux distro operating nicely for me and really don't want to change things over to Buster.  Armbian's website was not clear which one was "Debian" and which one was "Ubuntu".

On Tue, 28 Sept 2021 at 16:25, Reco <recov...@enotuniq.net> wrote:

On Mon, Sep 27, 2021 at 07:28:09PM +0100, Myron wrote:

> On Mon, 27 Sept 2021 at 15:30, Reco <recov...@enotuniq.net> wrote:
> > On Mon, Sep 27, 2021 at 01:36:59PM +0100, Myron wrote:
> > > This is on a Lemaker BananaPro SoC board running on Armbian.
> >
> > I.e. - not Debian, but Debian derivative.
> > In this particular case it actually matters.
>

> Noob question. Why would it matter?

In this case, it's the way Armbian builds, installs and maintains the
bootloader. Specifically, u-boot.
I'm not saying they're doing it wrong way, but it does differ from the
way Debian handles u-boot. Same can be said about Armbian kernel, but in
this case it does not matter.

So, I referred to /usr/lib/u-boot/platform_install.sh , because it's the
Armbian-specific file. If you were using Debian, I'd have to refer to
other ways of installing u-boot.

 

... u-boot is something I may look at in the future. I am absolutely a newbie to the topic of u-boot.

> > 2) Proceed with copying filesystem contents as outlined in previous
> > e-mail.
>

> This I shall try and do when I get the other card.  Hopefully I can shrink
> the partition to under 15Gb, clone the partition from the 32Gb card to a
> 16Gb card, buut off the 16Gb card and expand the partition to the full
> capacity of the 16Gb card.
>
> Can it be so simple and if not, how many gotyas are there?

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? 

> I've found the script, but may been help understanding some of it.

In simple terms:

1) Your root filesystem UUID is
UUID=dffd2ee5-5480-480b-9853-7884f8ba5e47, parition ID is e069b87e-01
(uuidpart in /proc/cmdline)

2) Since it's a single partition, this corresponds to /dev/mmcblk0p1.
The device itself therefore is /dev/mmcblk0, as long as you're using SBC
MMC slot, that it.

Yes, I am using only the SBC's MMC slot.

 

3) So, what the script is actually trying to do is:

a) Overwrite with zeroes first 1024 kilobytes of mmcblk0 starting with
first kilobyte (i.e. - excluding one).

b) Dump
/usr/lib/linux-u-boot-current-bananapipro_21.08.2_armhf/u-boot-sunxi-with-spl.bin
to the same mmcblk0, starting at 8192 byte at the beginning of the
device.

I.e., after you finish the cloning the filesystem's contents all you
need to do is to execute both commands from write_uboot_platform(),
replacing "$2" with /dev/mmcblk0 (or /dev/sd? if you're using an USB
card reader), and $1 with
/usr/lib/linux-u-boot-current-bananapipro_21.08.2_armhf.
And you do not have to use armhf dd for this, x86 dd will do the job
just as well.

It may take more than one try (it is for me at least), but failed
attempts to boot should not damage the hardware (at least it works this
way for me). Just have that USB-TTL cable ready, u-boot is a pain to
troubleshoot if you do not have an access to UART.

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.

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?

Does that make any sense?

This is how the MMC card is set-up right now.

Disk /dev/mmcblk0: 29.74 GiB, 31914983424 bytes, 62333952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe069b87e

Device         Boot Start      End  Sectors  Size Id Type
/dev/mmcblk0p1       8192 61702143 61693952 29.4G 83 Linux

I know. It's not advisable to resize a live root partition.  Maybe create a live boot Linux CD or USB with Gparted on it and do it that way?  It would be a lot simpler if I can just resize the file system, which seems to be the simple part using resize2fs.  It's the shrinking the partition bit I'm not sure about.

Myron

[Reco]

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

[Andrew M.A. Cater]

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

[Andrei POPESCU]

On Jo, 30 sep 21, 21:51:20, Reco wrote:
>
> On Thu, Sep 30, 2021 at 04:26:18PM +0100, Myron wrote:
>
> > 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.

[citation needed]

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

https://linuxconfig.org/how-to-resize-ext4-root-partition-live-without-umount

Disclaimer: I did not test the procedure myself.

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser

[Andrei POPESCU]

On Jo, 30 sep 21, 16:26:18, Myron wrote:
>
> I know. It's not advisable to resize a live root partition. Maybe create a
> live boot Linux CD or USB with Gparted on it and do it that way? It would
> be a lot simpler if I can just resize the file system, which seems to be
> the simple part using resize2fs. It's the shrinking the partition bit I'm
> not sure about.

Using *another* system running a live Linux with GParted is probably the
easiest way, provided you have a supported SD card reader with at least
one slot:

1. Boot another computer with a live distro that has GParted on it.

2. Optional: if you have enough storage I would strongly suggest you
take an image of the bigger SD card as backup in case something goes
wrong.

3. Use GParted to resize the partition as needed.

3b. In case you can't connect both SD cards at the same time take
another image of the bigger SD card.

4. Use `dd` or similar to clone the bigger SD card or the image taken
in step 3b. to the smaller card.

5. Open the smaller SD card in GParted and grow the partition to the
size available.

Disclaimer: steps above are untested.

`dd` might error out when copying the image to the smaller SD card (out
of space), but this is expected. As long as you resized the partition
properly all data should be there.

If in doubt just resize the partition to be definitely smaller than the
small SD card (by a GB or so).

[Andrei POPESCU]

On Vi, 01 oct 21, 09:23:52, Andrei POPESCU wrote:
> On Jo, 30 sep 21, 21:51:20, Reco wrote:
> >
> > On Thu, Sep 30, 2021 at 04:26:18PM +0100, Myron wrote:
> >
> > > 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.
>
> [citation needed]

Apologies, I should have checked it before challenging that. From
resize2fs(8):

If the filesystem is mounted, it can be used to expand the size of
the mounted filesystem, assuming the kernel and the file system
supports on-line resizing.

so ext4 indeed doesn't support online shrinking.

According to Wikipedia it seems very few file systems do (notable
exceptions btrfs and (!) NTFS).

https://en.wikipedia.org/wiki/Comparison_of_file_systems#Resize_capabilities

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

> https://linuxconfig.org/how-to-resize-ext4-root-partition-live-without-umount

This however implies growing should be possible.