Help with sysupgrade/eMMC/SDHC dual boot system

Installing and Using OpenWrt
1

Hi,

I'm looking for some guidance with a Gateworks Newport Octeontx system that has 8Gb on-board eMMC and a 16Gb SDHC which should act as a recovery device.

The images are both OpenWRT but the recovery image does not have any of our our application s/w built into it but we want to use an extra partition it has to store logs if we can.

I'm having trouble controlling which storage device the system boots from and also which target sysupgrade writes to. It's as if the system tells me I'm on mmcblk0 when it's actually running from mmcblk1.
It's a bit tricky to explain but I've plenty of log output e.g. this is me running a sysupgrade from Luci:

Switching to ramdisk...
Performing system upgrade...
Writing full disk image to /dev/mmcblk0
18073+1 records in
18073+1 records out
Upgrade completed
Rebooting system...
umount: can't unmount /dev: Resource busy
umount: can't unmount /tmp: Resource busy
/sbin/reboot: line 2: can't create /sys/bus/i2c/devices/i2c-0/0-0020/powerdown: nonexistent directory
sysupgrade aborted with return code: 256

This seems to work ok but when I did it again I get this:
Switching to ramdisk...
Performing system upgrade...
Writing full disk image to /dev/mmcblk1
18320+1 records in
18320+1 records out
Upgrade completed
Rebooting system...
umount: can't unmount /dev: Resource busy
umount: can't unmount /tmp: Resource busy
/sbin/reboot: line 2: can't create /sys/bus/i2c/devices/i2c-0/0-0020/powerdown: nonexistent directory
sysupgrade aborted with return code: 256

Although it says it aborted above this works ok as the image has been fully written to the device. But I can't figure why it now chose /dev/mmcblk1 when this had booted off /dev/mmcblk0.

The two images are quite distinct -

root@:/# fdisk -l
Disk /dev/loop0: 860.51 MiB, 902299648 bytes, 1762304 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


Disk /dev/mmcblk1: 14.86 GiB, 15931539456 bytes, 31116288 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: 0x00000000

Device         Boot Start     End Sectors  Size Id Type
/dev/mmcblk1p1 *     2048   28671   26624   13M  1 FAT12
/dev/mmcblk1p2 *    32768   65535   32768   16M 83 Linux
/dev/mmcblk1p3 *    65536 1908735 1843200  900M 83 Linux


Disk /dev/mmcblk0: 7.29 GiB, 7818182656 bytes, 15269888 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: 0x00000000

Device         Boot   Start      End  Sectors  Size Id Type
/dev/mmcblk0p1 *       2048    28671    26624   13M  1 FAT12
/dev/mmcblk0p2 *      32768    65535    32768   16M 83 Linux
/dev/mmcblk0p3 *      65536  1023999   958464  468M 83 Linux
/dev/mmcblk0p4 *    1024000 26623999 25600000 12.2G 83 Linux

/dev/mmcblk0p4 is the partition to hold our logs but this would be /dev/mmcblk1p4 during normal operation when it's running off the eMMC.

I can only seem to control things when I remove the SDHC card and tftp the main image to eMMC. As soon as I add the SDHC the system seems to want to use that as its mmcblk0 all the time. Any ideas gratefully received - and please let me know if there's any more output I could post up that would be relevant.

thanks,
Stuart

2

You may need to add aliases on top of the device tree to persistently enumerate MMC devices.
I needed to do that for BPi-R2 where I was fighting a similar problem and that solved it:

3

Thanks for your suggestion Daniel. I think this would have worked although the setup is a bit different in my system. It turns out, my two filesystem partitions were being built with identical UUIDs and Disk Identifiers which was confusing the selection of which one was loaded during boot. The best solution would seem to be to generate a UUID for each build but I don't think OpenWRT does this out the box. Alternatively, change the 'Disk identifier' using something like:
printf '\x1\x1\x1\x1' | dd of=your_image.img bs=1 seek=440 count=4 conv=notrunc as long as you know where it lives. Another option which I have found to work is to mount the image as a loop device and directly update the UUID using tune2fs though this is quite involved.

Disk Identifiers updated below:

# fdisk -l
Disk /dev/loop0: 928.58 MiB, 973668352 bytes, 1901696 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


Disk /dev/mmcblk0: 7.1 GiB, 7616856064 bytes, 14876672 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: 0x01010101

Device         Boot Start     End Sectors  Size Id Type
/dev/mmcblk0p1 *     2048   28671   26624   13M  1 FAT12
/dev/mmcblk0p2 *    32768   65535   32768   16M 83 Linux
/dev/mmcblk0p3 *    65536 2047999 1982464  968M 83 Linux


Disk /dev/mmcblk1: 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: 0x02020202

Device         Boot   Start      End  Sectors  Size Id Type
/dev/mmcblk1p1 *       2048    28671    26624   13M  1 FAT12
/dev/mmcblk1p2 *      32768    65535    32768   16M 83 Linux
/dev/mmcblk1p3 *      65536  1023999   958464  468M 83 Linux
/dev/mmcblk1p4      1024000 62333951 61309952 29.2G 83 Linux