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 Mon, Sep 27, 2021 at 07:28:09PM +0100, Myron wrote:
> On Mon, 27 Sept 2021 at 15:30, Reco <recoverym4n@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