@Keith-i : I've been taking a closer look at some of the start-up processes in our QNX systems recently, which got me to thinking about the so-called "activator" scripts that patch (hack?) the system to terminate process vdev-logvolmgr after it creates file /lvm/acios_db.ini at system start up. The current method is to piggy-back on the launch of mme-becker from the mmelauncher process by launching shell script mme-becker.sh, instead (as defined in the mmelauncher.cfg file) and include the background sub-shell commands (waitfor /lvm/acios_db.ini 180 && sleep 10 && slay vdev-logvolmgr) in the new shell script before it starts the actual mme-becker QNX binary. I think I determined why whoever discovered the magic to unblocking nav database access (possibly Keldo in 2014/15?) put the sub-shell stuff here (answer: someone else was already using mme-becker.sh to start the DHCP client on device uap0 for internet tethering on the WiFi device, but that's a different story).
I think the shell bits that terminate the vdev-logvolmgr process can go anywhere early enough in the start up process. Inspection of the system log (from sloginfo) on our 3G+ system show the vdev-logvolmgr process starting about 165 seconds into the boot process, followed by its termination (from signal 15) 10 seconds later. The trick, then, is to identify shell scripts launched by the QNX system services process (srv-starter-QNX) that are equivalent on both 3G High & 3G Plus systems, and replace that script with a new script that includes our nav database unblocking code just before it exits:
Code:
(waitfor /lvm/acios_db.ini 180 && sleep 10 && slay vdev-logvolmgr) &
I see that /mnt/efs-system/usr/bin/manage_cd.sh appears on both systems; its 3G High startup config is:
Code:
<Process>
<Number>37</Number>
<Name>/usr/bin/manage_cd.sh</Name>
<Args/>
<ResArgs/>
<Prio>10</Prio>
<StartParam>BACKGROUND</StartParam>
<OnTerminate>KEEP_INTERFACE</OnTerminate>
<Shutdown>IGNORE</Shutdown>
<ProvidesInterface>50</ProvidesInterface>
<RequiresInterface>3</RequiresInterface>
<RequiresInterface>4</RequiresInterface>
<RequiresEnvironment/>
</Process>
and on 3G Plus systems:
Code:
<Process>
<Number>37</Number>
<Name>/usr/bin/manage_cd.sh</Name>
<Args/>
<ResArgs/>
<Prio>10</Prio>
<Partition>System</Partition>
<StartParam>BACKGROUND</StartParam>
<OnTerminate>IGNORE_ALL</OnTerminate>
<Shutdown>IGNORE</Shutdown>
<KeepInterface>true</KeepInterface>
<MaxProcessRestarts>0</MaxProcessRestarts>
<FinalAction>IGNORE</FinalAction>
<VariantCode>-1</VariantCode>
<VariantMask>-1</VariantMask>
<ProvidesInterface>45</ProvidesInterface>
<RequiresInterface>3</RequiresInterface>
<RequiresInterface>19</RequiresInterface>
<RequiresEnvironment/>
</Process>
I think the differences between the two are minor -- the result is the same in both cases; it's worth taking a look at putting the nav database "unblocker" here, instead of burying it inside of a bogus mme-becker.sh script.
I don't have access to a 3G High system here (I managed to extract the ifs-root.ifs file of the NAR 3G High software update to examine the mmi3g-srv-starter.cfg file); it would be useful to confirm that the manage_cd.sh script is the same (or mostly) on the two systems to simplify installation of a practical work-around to the "blocked nav datatbase" problem. I plan to have a go at this on our 3G+ system in the next few days and report back.
But to answer your immediate question, you could rework the mmi3ginfo run.sh script to install the mme-becker.sh and mmelauncher.cfg files directly; something like this:
Code:
mount -uw /mnt/efs-system
cp -v ${SDVAR}/mme-becker.sh /mnt/efs-system/sbin/mme-becker.sh
mv -v /mnt/efs-system/etc/mmelauncher.cfg /mnt/efs-system/etc/mmelauncher.cfg-ORIG
cp -v ${SDVAR}/mmelauncher.cfg /mnt/efs-system/etc/mmelauncher.cfg
ls -o /mnt/efs-system/sbin/
ls -o /mnt/efs-system/etc/
Copy the mm-becker.sh and mmelauncher.cfg files to the var folder of the SD card, and inspect the log files for error messages before restarting your MMI system. --g
