Unblocking Nav Database Access Following Updates on MMI 3G/3G+ Systems

[DrGER]

As delivered from the factory, MMI 3G (High) and Plus systems navigation databases are activated with an FSC file specific to the database release stored in /mnt/efs-persist/FSC. When an end-user updates the navigation database without completing the SVM - Activation process with ODIS and information obtained from the purchased nav database activation document, further access to the navigation database will be blocked by the system. A work-around to unblock access to the navigation database following an update is to terminate system process vdev-logvolmgr shortly after it starts and creates regular file /mnt/lvm/acios_db.ini in the QNX filesystem, as described by Keldo in early 2016. This work-around essentially disables the normal navigation database activation process used by Harman-Becker on their MMI3G systems.

A common approach used by so-called "activator" SD card scripts is to start a background sub-shell at system startup that waits for the appearance of regular file /mnt/lvm/acios_db.ini and terminates process vdev-logvolmgr after a brief wait. The shell commands for the background sub-shell are included commonly in a (new) wrapper shell script that starts process mme-becker, as defined in mmelauncher.cfg.

Objections I have to this approach are that (1) it adds a new, unnecessary shell script (mme-becker.sh) to launch the background sub-shell and then start the actual mme-becker process; and (2) possible variations in mmelauncher.cfg files across generations (High / Plus), platforms, and regions implies that "sed" must be used to edit the file so that the new wrapper script is called (rather than calling mme-becker, directly). I believe this approach was used for the work-around because an early method of accessing internet data through the internal WLAN device used wrapper script mme-becker.sh to force the DHCP client to start on interface uap0 (due to required access to certain HDD mounts not available earlier in the QNX boot process).

A simpler approach to disabling the normal nav database activation process is to add the background sub-shell commands to an existing shell script that is called by system process srv-starter-QNX as defined by /etc/mmi3g-srv-starter.cfg, since the commands used by the sub-shell are stored in flash memory and available immediately. Inspection of /etc/mmi3g-srv-starter.cfg shows that shell script /usr/bin/manage_cd.sh is called relatively early in the boot process on both 3G High and Plus systems. The purpose of the script is to provide interface /dev/shmem/CD0_STARTED :

#!/bin/ksh
for i in 1 2 3 4
do
   mount -t udf -r -o format=udf:joliet:iso9660e:iso9660:audio,case=asis /dev/cd0 /fs/cd0
   mount_ret=$?
   if test $mount_ret -eq 0; then
      touch /dev/shmem/CD0_STARTED
      echo cd0 mounted after $i try
      break
   fi
done
if test $mount_ret -ne 0; then echo cd0 mount failed!; fi

Minimally, the commands for the background sub-shell can be appended to manage_cd.sh simply with:

mount -uw /mnt/efs-system
echo "(waitfor /mnt/lvm/acios_db.ini 180 && sleep 10 && slay vdev-logvolmgr) &" >> /mnt/efs-system/usr/bin/manage_cd.sh

Practically, installation of the "patch" should confirm that the patch has not been applied already:

mount -uw /mnt/efs-system
if test -z "$(grep 'acios_db.ini' /mnt/efs-system/usr/bin/manage_cd.sh)"
then
    echo "/usr/apps/benchmark/TimeLogger 'Starting NAVDB patch'" >> /mnt/efs-system/usr/bin/manage_cd.sh
    echo "(waitfor /mnt/lvm/acios_db.ini 180 && sleep 10 && slay vdev-logvolmgr) &" >> /mnt/efs-system/usr/bin/manage_cd.sh
else
    echo "NAVDB patch already applied !"
fi

Backing out of the "patch" is simple enough with "sed", but is not likely needed as long as access to the navigation database is needed (i.e., to use the Navigation functions of the MMI 3G system).

A ZIP archive of a MMI QNX shell script to patch manage_cd.sh (and to remove the old mme-becker.sh patch) is posted in my GitHub repository HERE. --g