Foresee NCEMASLG-64G 64 GB eMMC module unreadable

[lucho]

Thanks! I just wrote the image to a slow microSD card and to the eMMC module (in the latter case, using "dd", without trying to read it again from the module), moved both the microSD card and the eMMC module to the RockPro64, and turned it on. It booted OK, I managed to log in and it turned out that the it had booted from the eMMC module, not the microSD card. So far, so good. Just in case, I read the eMMC module with "sudo dd if=/dev/mmcblk1 of=/dev/null bs=1M" and it did read the (almost) entire module successfully, with 157 MB/s. So you're right that it must have been a timing issue. I just learned that the eMMC still supports the serial interface of the original MMC and SD cards, and that's how the Hardkernel microSD-to-eMMC adapter works. But because of the very high reading speed of this eMMC, the timings must have been be "at the edge" with it, which leads to occasional errors. Fortunately, this occurs only on reading and not on writing when it's slower so the timings are not "at the edge" – a "blessing in disguise".

Now the question is how to resize the image to the full 64 GB size of the eMMC card. I tried the "/usr/local/sbin/resize_rootfs.sh" script but it turned out that it can resize non-mounted partitions only:

Code:

rock64@rockpro64:/usr/local/sbin$ sudo ./resize_rootfs.sh
Resizing /dev/mmcblk0 (sd/emmc -- /dev/mmcblk0p7)...
+ sgdisk -e /dev/mmcblk0
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
+ echo ,+,,,
+ sfdisk /dev/mmcblk0 -N7 --force
Checking that no-one is using this disk right now ... FAILED

This disk is currently in use - repartitioning is probably a bad idea.
Umount all file systems, and swapoff all swap partitions on this disk.
Use the --no-reread flag to suppress this check.

Disk /dev/mmcblk0: 3.7 GiB, 3949985792 bytes, 7714816 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: gpt
Disk identifier: B2791BBA-7718-4413-BA41-9137CCF92DD2

Old situation:

Device          Start     End Sectors  Size Type
/dev/mmcblk0p1     64    8063    8000  3.9M Linux filesystem
/dev/mmcblk0p2   8064    8191     128   64K Linux filesystem
/dev/mmcblk0p3   8192   16383    8192    4M Linux filesystem
/dev/mmcblk0p4  16384   24575    8192    4M Linux filesystem
/dev/mmcblk0p5  24576   32767    8192    4M Linux filesystem
/dev/mmcblk0p6  32768  262143  229376  112M Microsoft basic data
/dev/mmcblk0p7 262144 7714782 7452639  3.6G Linux filesystem

/dev/mmcblk0p7:
New situation:
Disklabel type: gpt
Disk identifier: B2791BBA-7718-4413-BA41-9137CCF92DD2

Device          Start     End Sectors  Size Type
/dev/mmcblk0p1     64    8063    8000  3.9M Linux filesystem
/dev/mmcblk0p2   8064    8191     128   64K Linux filesystem
/dev/mmcblk0p3   8192   16383    8192    4M Linux filesystem
/dev/mmcblk0p4  16384   24575    8192    4M Linux filesystem
/dev/mmcblk0p5  24576   32767    8192    4M Linux filesystem
/dev/mmcblk0p6  32768  262143  229376  112M Microsoft basic data
/dev/mmcblk0p7 262144 7714782 7452639  3.6G Linux filesystem

The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Device or resource busy
The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).
Syncing disks.
+ partprobe /dev/mmcblk0
+ resize2fs /dev/mmcblk0p7
resize2fs 1.44.1 (24-Mar-2018)
The filesystem is already 931579 (4k) blocks long.  Nothing to do!

So, in fact, it did nothing. How should I do the resizing then? (This may now be off-topic but I can start a new topic if needed.)