Rock Pi 4 - Expanding EMMC after SD > EMMC copy

Troubleshooting
1 
root@rockpi2:~# cat /boot/dietpi/.version
G_DIETPI_VERSION_CORE=8
G_DIETPI_VERSION_SUB=20
G_DIETPI_VERSION_RC=1
G_GITBRANCH='master'
G_GITOWNER='MichaIng'
G_LIVE_PATCH_STATUS[0]='applied'
  • Distro version | bookworm
  • Kernel version | Linux rockpi2 5.15.93-rockchip64 #23.02.2 SMP PREEMPT Fri Feb 17 23:48:36 UTC 2023 aarch64 GNU/Linux
  • Architecture | arm64
  • SBC model | ROCK 4 (aarch64)
  • Power supply used | 2.5amp usb-c provided by Nebra (repurposed hotspot miner)
  • SD card used | Sandisk > EMMC (I’ve done this on another Rock Pi without the resize issue)

Steps to reproduce

Unsure exactly but here’s what I think happened…

flash dietpi for rockpi4 board to sandisk SD card

boot the rockpi from the SD and complete the dietpi basic install

use dd to copy the 16G SD contents to the 32G EMMC using these instructions

  • Here’s where there is a difference in how I did this on my 2 Rock Pi boards - On the first I let DD run from start to finish. On this one, I used ctl + c to interrupt it. I forgot that DD needed to copy the entire 16GB partition over to the EMMC and thought that something was wrong when it got to 8GB copied for an OS with only ~500mb of files - my mistake.

poweroff, remove the SD card, boot, everything runs just fine!

use the dietpi-drive_manager resize function (no obvious issue), and reboot

do lsblk and see this (28.9G)

mmcblk1      179:0    0 28.9G  0 disk 
└─mmcblk1p1  179:1    0 28.9G  0 part /

do 'fdisk -l` and get this (28.9G)

Disk /dev/mmcblk1: 28.91 GiB, 31037849600 bytes, 60620800 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: 0x97bfc449

Device         Boot Start      End  Sectors  Size Id Type
/dev/mmcblk1p1 *    32768 60620799 60588032 28.9G 83 Linux

do df -h and get this (16G)

Filesystem      Size  Used Avail Use% Mounted on
udev            919M     0  919M   0% /dev
tmpfs           199M  2.9M  196M   2% /run
/dev/mmcblk1p1   16G  546M   15G   4% /
tmpfs           991M     0  991M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           990M     0  990M   0% /tmp
tmpfs            50M  8.0K   50M   1% /var/log

At one point in my googling I found the path for the dietpi-drive_manager log file, but I’m unable to locate that again for sharing here.

Before I run fdisk to recreate the root partition, I wanted to ask if there is a best way to try to resolve this. My concern is that fdisk -l reports the start sector as 32768 and when I start to recreate the partition with fdisk the first sector is 2048. I’m afraid of wiping something out that might be required for booting off the EMMC…

Thanks for any insights/tips.

2

can you have a look pls @MichaIng

3

I meant to mention earlier that dietpi-drive_manager also sees this drive as 15.4GiB

Mount target: /                                                                                  │
│ Mount source: /dev/mmcblk1p1                                                                     │
│ Filesystem:   ext4                                                                               │
│ UUID:         21fbd909-5d4f-4ffe-8ad7-751b251a9f2a                                               │
│ Allocation:   Capacity: 15.4GiB | Used: 548.2MiB (3%)                                            │
│ Status:       Drive is online and ready for use                                                  │
│ Read only:    Disabled
4

The drive manager shows the filesystem size, just like df. lsblk and fdisk show the disk and partition sizes.

I guess the SD card was 16 GB size? Probably the new partition table after expanding it was not successfully reread/reported to the kernel so that the filesystem could not be extended til the new end. Just redo that step:

resize2fs /dev/mmcblk1p1

Btw, aborting dd can lead to data loss as the data may not be aligned to the start of the filesystem. So even if only 500 MiB are used, some of the data may be located at the end of the disk/last processed filesystem blocks. Shrinking the filesystem + partition first can be done, and aborting dd after it wrote the size of the partition + some safety marging is safe.

1 Like
5

That is the command I had found and tried (I’m pretty sure) and couldn’t find again. Here’s the output from it.

root@rockpi2:~# resize2fs /dev/mmcblk1p1
resize2fs 1.47.0 (5-Feb-2023)
Filesystem at /dev/mmcblk1p1 is mounted on /; on-line resizing required
old_desc_blocks = 2, new_desc_blocks = 4
Performing an on-line resize of /dev/mmcblk1p1 to 7573504 (4k) blocks.
resize2fs: Invalid argument While trying to add group #125

I think something similar was in the dietpi-drive_manager log output that I also couldn’t find again :grimacing:

6

Ah, that is the issue, whatever this error means. Here is a (very old) bug report with the same error, but on an LVM with a 64-bit kernel driving 32-bit userland: https://bugs.debian.org/451388

You are surely using a 64-bit userland, as we never shipped images with 32-bit OS for ROCK 4:

dpkg --print-architecture

(should return arm64.

Does the kernel report errors like on the Debian bug report?

dmesg -l 0,1,2,3

When you run an fsck on reboot, are there any errors erported?

> /forcefsck
reboot

And after reboot:

cat /run/initramfs/fsck.log
7

Yes, arm64 and the dpkg errors are identical between both my RockPi 4 boards. And YES, this was copied over from a 16gb microSD.

root@rockpi2:~# dpkg --print-architecture
arm64
root@rockpi2:~# dmesg -l 0,1,2,3
[    1.998529] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout!
[    3.565612] rk_gmac-dwmac fe300000.ethernet: cannot get clock clk_mac_speed
[    6.590622] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[    6.762825] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[    6.775481] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Mar 30 2021 01:12:21 version 7.45.98.118 (7d96287 CY) FWID 01-32059766

root@rockpi2:~# cat /run/initramfs/fsck.log 
Log of fsck -C -a -V -t ext4 /dev/mmcblk1p1 
Sun Aug  6 00:02:45 2023

fsck from util-linux 2.38.1
[/sbin/fsck.ext4 (1) -- /dev/mmcblk1p1] fsck.ext4 -a -C0 /dev/mmcblk1p1 
/dev/mmcblk1p1: clean, 19352/1004000 files, 208398/4096000 blocks

Sun Aug  6 00:02:45 2023

I don’t think this aligns with the old bug you found, but that discussion admittedly goes a bit beyond my understanding.

Thanks for the replies!

8

I’m mostly curious if it should be safe to boot from the SD card, re-create the primary partition on the EMMC, remove the SD card, and then reboot. There’s nothing on the EMMC that I mind losing as long as I’m not potentially messing up any deeper level boot files that could break it from working permenantly.

9

Well I’ve done it now! Got impatient and tried booting from the SD, re-running the dd command, and no the Rock Pi 4 won’t boot off the EMMC. It still boots just fine off the SD card, and when I compare the 2 drives (SD vs. EMMC) they look identical.

Here’s what I did:

From SD card

 `dd if=/dev/mmcblk0 of=/dev/mmcblk1 bs=1M status=progress`

 shut down, remove SD card, power on

From EMMC

 no SSH working, blue light does 2 flashes, pause, 2 flashes, indefinitely

From SD Card

 run `dietpi-drive_manager` and check/repair on EMMC drive

│ e2fsck 1.47.0 (5-Feb-2023)
│ ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
│ e2fsck: Group descriptors look bad... trying backup blocks...
│ Warning: skipping journal recovery because doing a read-only filesystem check.
│ Resize inode not valid.  Recreate? no
│
│ Pass 1: Checking inodes, blocks, and sizes
│ Inode 7, i_blocks is 7368, should be 7176.  Fix? no
│
│ Pass 2: Checking directory structure
│ Pass 3: Checking directory connectivity
│ Pass 4: Checking reference counts
│ Pass 5: Checking group summary information
│ Block bitmap differences:  -(229472--229488) -(229504--229556) -(229568--229587) -(229600--229626)
│ -(229632--229841) -(229856--229872) -(229888--230706) -(230784--230867) -(230880--230896) -(230912--230977)
│ -(231008--231024) -(231040--231072) -(231104--231136) -(231168--231184) -(231200--231216) -(231232--231280)
│ -(231296--231361) -(231392--231408) -(231424--231571) -(231584--231602) -(231616--231634) -(231648--231666)
│ -(231680--231747) -(231776--231795) -(231808--231824) -(231840--231861) -(231872--231891) -(231904--231923)
│ -(231936--232096) -(232128--232148) -(232160--232179) -(232192--232209) -(232224--232241) -(232256--232275)
│ -(232288--232311) -(232320--232338) -(232352--232377) -(232384--232401) -(232416--232432) -(232448--232480)
│ -(232512--232544) -(232576--232608) -(232640--232672) -(232704--232739) -(232768--232804) -(232832--232850)
│ -(232864--232880) -(232896--232928) -(232960--233281) -(233312--233335) -(233344--233381) -(233408--233442)
│ -(233472--234093) -(234112--234128) -(234144--234160) -(234176--234208) -(234240--234268) -(234272--234293)
│ -(234304--234340) -(234368--234403) -(234432--234459) -(234464--234494) -(234496--235376) -(235392--235440)
│ -(235456--235502) -(235520--235882) -(235904--235950) -(235968--236004) -(236032--236065) -(236096--236133)
│ -(236160--236195) -(236224--236259) -(236288--236322) -(236352--236387) -(236416--236461) -(236480--236501)
│ -(236512--236588) -(236608--236642) -(236672--236706) -(236736--236783) -(236800--236838) -(236864--236896)
│ -(236928--236954) -(236960--236978) -(236992--237041) -(237056--237077) -(237088--237106) -(237120--237137)
│ -(237152--237178) -(237184--237269) -(237280--237309) -(237312--237469) -(237472--237502) -(237504--237545)
│ -(237568--237676) -(237696--237735) -(237760--237776) -(237824--237975) -(238016--238062) -(238080--239696)
│ -(239712--239728) -(239744--239840) -(240128--240442) -(240448--240501) -(240512--240514) -240516 -240531
│ -(240536--240625) -(240640--240911) -(240928--240950) -(240960--241003) -(241152--241562) -(241664--244592)
│ -(249856--254934) -(256000--256982) +294916 +(294919--294920) +294922 +294924 +(294926--294928) +294931 +294935

e2fsck 1.47.0 (5-Feb-2023)                                                                                          │
│ ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap                                             │
│ e2fsck: Group descriptors look bad... trying backup blocks...                                                       │
│ /dev/mmcblk1p1: recovering journal                                                                                  │
│ e2fsck: unable to set superblock flags on /dev/mmcblk1p1                                                            │
│                                                                                                                     │
│                                                                                                                     │
│ /dev/mmcblk1p1: ***** FILE SYSTEM WAS MODIFIED *****                                                                │
│                                                                                                                     │
│ /dev/mmcblk1p1: ********** WARNING: Filesystem still has errors **********
10

Good news. I just did the same thing again and this time I was able to SSH into the RockPi 4 afterward.

DD copy SD > EMMC.
Shut Down
Remove SD
Boot
SSH works

I then ran the dietpi-drive_manager resize script and it rebooted and it actually work this time too!

root@rockpi2:~# df -Th
Filesystem     Type      Size  Used Avail Use% Mounted on
udev           devtmpfs  919M     0  919M   0% /dev
tmpfs          tmpfs     199M  2.9M  196M   2% /run
/dev/mmcblk1p1 ext4       29G  546M   27G   2% /
tmpfs          tmpfs     991M     0  991M   0% /dev/shm
tmpfs          tmpfs     5.0M     0  5.0M   0% /run/lock
tmpfs          tmpfs     990M     0  990M   0% /tmp
tmpfs          tmpfs      50M  8.0K   50M   1% /var/log
11

Looks like something went wrong the first time. Good that it worked now.