There is several gigabytes of eMMC memory prepasted on the bpi-m5 that I would like to train amanda's database to use as its a heck of a lot faster & longer lasting than the 128G u-sd it is booting from.  What is the procedure to mount it and make it usable as r/w memory?

lsblk should show you 2 mmcblk devices; 1 is SD-card, the other is on-board eMMC. Which is which number can vary depending on what kernel and DTB.

 

If you only see 1, you should change operating system maybe.

that would be "mmcblk1                         179:0    0  14.6G  0 disk"  So should be usable if placed in /etc/fstab?

whole output of lsblk in bulky:

root@amanda:/# lsblk
NAME                            MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda                               8:0    0 931.5G  0 disk 
├─sda1                            8:1    0  48.8G  0 part /buildbot
├─sda2                            8:2    0   785G  0 part /hold
└─sda3                            8:3    0  97.7G  0 part [SWAP]
sdb                               8:16   0   3.6T  0 disk 
└─sdb1                            8:17   0   3.3T  0 part 
  └─myvg-striped_logical_volume 251:0    0    15T  0 lvm  /mnt
sdc                               8:32   0   3.6T  0 disk 
└─sdc1                            8:33   0   3.3T  0 part 
  └─myvg-striped_logical_volume 251:0    0    15T  0 lvm  /mnt
sdd                               8:48   0   3.7T  0 disk 
└─sdd1                            8:49   0   3.3T  0 part 
  └─myvg-striped_logical_volume 251:0    0    15T  0 lvm  /mnt
sde                               8:64   0   3.7T  0 disk 
└─sde1                            8:65   0   3.3T  0 part 
  └─myvg-striped_logical_volume 251:0    0    15T  0 lvm  /mnt
sdf                               8:80   0   3.6T  0 disk 
└─sdf1                            8:81   0   3.3T  0 part 
  └─myvg-striped_logical_volume 251:0    0    15T  0 lvm  /mnt
mmcblk1                         179:0    0  14.6G  0 disk 
mmcblk1boot0                    179:32   0     4M  1 disk 
mmcblk1boot1                    179:64   0     4M  1 disk 
mmcblk0                         179:96   0 119.1G  0 disk 
└─mmcblk0p1                     179:97   0 117.9G  0 part /var/log.hdd
                                                          /
zram0                           250:0    0   1.8G  0 disk [SWAP]
zram1                           250:1    0    50M  0 disk /var/log
zram2                           250:2    0     0B  0 disk 
root@amanda:/# 

but what are the next 2 4meg boot0 & boot1 used for?  uboot pointers? or??

 

Thank you eselarm

mmcblk1boot0 mmcblk1boot0 are for booting via other boot methods, not used for U-Boot in Linux/Armbian. Don't use them I would say, otherwisie the ROM in the BPI might leave you with a bricked board.

You can make a partition on mmcblk1, format it and mount it. Same as with other disks.

humm mounted it w/o formatting, ran df didn't show, and didn't reboot, had to power it down & took double the normal time to reboot.

on reboot looks ok mmcblk0 appears to be the 128G u-sd card as / and

mmcblk1                         179:32   0  14.6G  0 disk 
mmcblk1boot0                    179:64   0     4M  1 disk 
mmcblk1boot1                    179:96   0     4M  1 disk 

appears to be the eMMC chip, however inspecting it with fdisk does not show the sub parts, only

root@amanda:~# fdisk /dev/mmcblk1

Welcome to fdisk (util-linux 2.39.3).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table.
Created a new DOS (MBR) disklabel with disk identifier 0x75f202df.

Command (m for help): p
Disk /dev/mmcblk1: 14.56 GiB, 15634268160 bytes, 30535680 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: 0x75f202df
is it safe to format to ext4?

 

Thank you eselarm

I never used Ext4 directly on a whole block device. Linux in general assumes partitions.  Advice is to use partitions. So create one first wit fdisk.

won;t that blow away those 2 4meg boot0 and boot1 locations that lsblk see's?

What are they used for?

 

Thank you eselarm

 

My best guess is that you have an Android install on your eMMC (Android uses those two boot partitions as part of how it installs new versions, while still keeping the old).  How Android formats a disk is generally somewhat custom and often the partitions aren't readable by mainline uboot / mainline linux.  (It should be a GPT partition table, but for some reason I haven't dug into, isn't recognized by mainline).  I deal with these things on Android TV Boxes all the time.  You should be able to just format the entire emmc for your use as what is on their isn't useful to you.  However, I'm not familiar with this specific board and what the specifics of its booting process is.  So there is a chance that something on the eMMC is required for a successful boot.

Android? heard of it, never used it. Don't even have an operational hell-fone, chip expired years ago.

root@amanda:~# uname -a
Linux amanda 6.12.32-current-meson64 #1 SMP PREEMPT Wed Jun  4 12:43:54 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux
This thing is being put together to run amanda, the backup program from ancient unix history, used at CERN and numerous large medical facility's.  Runs fine on wintel hdwe but has now been recompiled for arm64's. I'll put a gpt table on it and format it to ext4 & hope it reboots.  Thanks a bunch, Steeman.

back to the 15TiB lvm, what can I put in /etc/fstab to make it mount automatically on boot, with RH's public version of gfs2 for a file system

It mounts just fine from the cli with a pretty simple "mount -t gfs2 /dm-0" as root of course. giving a df report of:

/dev/mapper/myvg-striped_logical_volume 16104789168 1057496 16103731672   1% /dm-0

 

Thanks a bunch. gene1934

finally must have hit the target on the automount vs /etc/fstab, for future reference, I added:

/dev/mapper/myvg-striped_logical_volume /dm-0 gfs2 defaults 0 1

to /etc/fstab & rebooted twice to be sure.