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

[DrGER]

This follow-up post includes usage text to the QNX binary /mnt/ifs-root/usr/bin/vdev-logvolmgr, which is found on both MMI3G High and MMI3G Plus systems. This usage text was extracted from the MMI3G High QNX binary with strings(1) on a Solaris x86 system, edited lightly for readability here, and presented in two parts (given that the maximum size of a post on the forum is 30,000 characters). The second part, below, documents the LVM protocol command interface.

vdev-logvolmgr - Logical Volume Manager

This is a virtual device driver for managing logical volumes and data carriers,
as well as database packages and definitions.

To allow debugging and usage, the LVM comes with a terminal to access LVM
functions directly.  Starting the terminal won't start the LVM - you need
another instance of the LVM to use the terminal.

Options:
    -v  Increase verbosity level by one (max 5)
    -t  Start in LVM terminal mode. 
    -c  Force the LVM to use cp instead of qkcp. Specify this option in case
        qkcp is not available. Important: Copy progress information is not
        available without qkcp.
    -b  Bind packages strictly to file definitions that are on the same
        storage device. Use this option to prevent that packages on storage
        devices with corrupt file definitions are reported as 'GOOD',
        and prevent binding to other file definitions on other storage
        devices.
    -r  Force remount of storage device if a config.nfm cannot be located
        and the storage device is in read only mode. The LVM will remount
        the device to create a new package database.
    -l  Force real pathnames in acios_db.ini - resolve links to directly
        accessible locations. Use this when using acios_db.ini files previously
        generated by the LVM and the LVM isn't running while the generated
        acios_db.ini is used.
    -L  specify fully qualified path to vdev-fsys-dbc. The default is the
        current working directory.
    -m  Redirect process stdout to multicore (/hbsystem/multicore/p)
    -M  Redirect process stdout to given path, e.g.:

          -M /hbsystem/multicore/q

    -h  This option is not supported: 
        Enable high speed operation for compatible DVD devices. High speed mode
        will be enabled during mounting and disabled during dismounting. At the
        moment, only Fujitsu-Ten DV04 is supported (if mounted as */cd0*)
    -k  Automatically remove files that don't belong into the package database.
        Use this to allow the LVM to automatically remove file definitions that
        have lost their .conf files for whatever reason. This operation will
        be performed during a mount operation. Additionally, file definitions
        with broken configuration files will also be removed. Please keep in
        mind that the file will also be regarded as broken if the cipher key
        doesn't match when using scrambled configuration files, so IT IS VITAL
        that this option IS NOT used with rewritable installation media such
        as USB sticks or SD cards without write protection.
    -U  override O_NONBLOCK in open modes and unblock console I/O after one
        second, even if no data has arrived.
    -H  Skip header checks after copying a file to the package database. Do this
        when the file system cannot garuantee cache coherency after Direct-IO
        operations.
    -D  When activating a package, put an acios_db.ini file into the root of the
        given storage device. The file will be updated with every activation
        issued.
    -A  When activating a package, put an acios_db.ini file into the position
        specified by the ACTIVATE PACKAGE command. This only works if the
        given location already exists and is not implicitly created by the
        activation itself in the form of a symbolic link.
    -R  Force reclaim of space taken up by deleted files that were in use when
        a device is being remounted.
    -C  Set directory for checkpoint files. Checkpoint files are stored at the
        given directory. Make sure to specify the correct directory to prevent
        possible damage to other directories - The directory will  be destroyed
        after a successfull database activation.
        
        The default for this value is /HBpersistence/lvm.checkpoints
    
    -d  Specify this parameter if you want to remove checkpoints in the
        checkpoint directory from remaining installations that where never  
        finished. This will occur after each attempt to execute
        an ACTIVATE or DELETE PACKAGE command, as the LVM will assume that the
        installation has been completed and other checkpoint files are not  
        needed anymore.
    -K  Specify a cipher that will be used to decipher the configuration files.
        it is highly recommended to set this option. It must be specified in
        hexadecimal without prefixes. You may specify up to 40 bytes. It should
        differ between projects.
    -p  Specify a comma separated list of file definition types. Links to file  
        definitions of the given types will be put into the root directory of
        the storage device upon activation, e.g.:
    
        -p SDS,MAPSTYLE

        The files will keep their original extension, but the name of the file
        will be that of its type. Because of that, if multiple file definitions
        of the same type are activated, they must have different extensions.
        It is therefore not recommended to use this for multiple files.
    -P  Set a directory where the LVM can storage intermediate results from
        package checks. These files are maintained by the LVM during runtime,
        and will be removed with the file definitions. If the file definitions
        are not removed by the LVM, this directory may accumulate files
        with a integrity_check* prefix. The user application should clear
        that directory in that case. The files are also removed as soon as
        a storage device is initialized.
        Alternatively, a non-existent directory or device may be specified.
    -Q  Execute quick check after each package installation. All file
        definitions belonging to the package will be checked automatically
        according to the quick check information stored in the file definition
        configuration. 
    -I  Report INSTALLPKG progress information in percent instead of numbers  
        of files progcessed.
    -n  Set the size to be used when performing checks through the EXECUTE
        THOROUGH CHECK command. If the value is smaller than the size of the
        file, the application can repeat the test until all of the file
        has been checked. Use this to perform background checks. The
        default value is 50000000. Set to 0xffffffff if all of the file should
        be checked at once. Also see option -P for the checkpoints created
        by this function.
    -z  This option is not supported:
        Invalidate file descriptors before removing file definitions. This is
        just a workaround for applications that do not release the file
        descriptors during an update operation. Use with caution, and validate
        on a per-project basis.
    -a  Put the names of the activated packages into the acios_db.ini.
    -u  Disable automatic acios_db.ini update after activation and deactivation.
    -B  Set alternate name for acios_db.ini files generated by the LVM. Do not
        specify a path here - just supply a file name.
    -W  Specify if packages ('p') or filedefs ('f') should be only loaded
        when they are scrambled. 
    -i  Prevent the installation of unscrambled packages.
    -w  Specify a list of storage device where automatic repair should take
        place. Only storage devices specified here will be automatically  
        repaired. Should only be specified if option k is not specified.
    -j  Decompress files on the fly when installing a package.
    -J  Write compressed variant of file to acios_db.ini even if it has been
        instantiated to its decompressed variant during runtime.
    -g  Automatic discard of orphaned file definitions. Will be attempted after
        each successful package activation. This will also clear the checkpoint
        and file integrity check cache. Following installations and file
        checking operations will start over.
    -E  Abort package installations on the first error encountered. Do not skip
        the file.
    -Y  Specify the maximum time for a read recovery. The recovery may take
        longer if the underlying access operation takes too long.
    -f  Abort MOUNT operation on first IO-Error
        
        Warning: The -h option is for testing purposes only.
    
Examples:
./vdev-logvolmgr -v -v -v -v -v     Start LVM with highest verbosity level.
./vdev-logvolmgr -t                 Start LVM in terminal mode.
./vdev-logvolmgr -v -v -v -c        Start LVM with medium verbosity and cp
    
There are no recommended settings, but the options d,C,K,l,r,b,n,k,Q,P should
considered for usage in a production environment. 
        
**** LVM location in the systems
The LVM creates per default mount points for handled devices under /mnt/lvm.
The communication interface (console) is created at /dev/lvm, and is used for
interaction with the LVM. Database file locations are provided with the
acios_db.ini IPC mechanism at /dev/lvm/acios_db.ini
        
**** LVM message format
LVM messages consist of 7-bit ASCII characters, padded to 8-Bit. Extended
character sets may be used as long as they don't interfere with ASCII control
codes, including CR, LF and NUL. Messages coming from the LVM may be protected 
with a simple integrating checksum mechanism:
checksum = 0
for each character in message
    add ascii value of character to checksum modulo 256
next    
    
The checksum delimiter '*' will be included into the the checksum. In this
example, a message is received by the user:
100 ABCDEF,*??
To confirm the checksum that is placed by the LVM into the positions marked
by ??, the user must calculate the checksum for the characters
100 ABCDEF,*
The checksum is given in uppercase hexadecimal notation without prefixes.  

**** General usage of the LVM       
The LVM maintains a database of files for use by other applications on entities
known in LVM-lingo as 'Storage Devices'. A storage device can be any device
that is accessible using standard Filesystem functions, as long as it contains
the structures needed by the LVM to actually store and maintain the database.
If the LVM encounters a storage device that is lacking these structures, the LVM
will try to initialize the storage device with the required settings. Data is
stored in the database in the form of "Definitions". A definition contains
information about the files stored in the database, like their supposed size
and checksums, and other user defined information that the LVM will parse and
present derived form - the checksum and size information will be used by the LVM
to verify that the file is in good shape.

Storage devices must be made accessible to the LVM by announcing their presence.
Only then the LVM will start to access the device. The announcement may be
performed by sending a MOUNT command to the LVM. See the command listing for
details. 

There are three main types of resources the LVM does handle:
1) Storage Devices
A storage devices is a device the LVM uses to store other resources
2) Packages
A package describes a list of file definitions that belong to each other
logically. Users are supposed to handle packages only - single file
definitions are handled by the LVM according to the specification inside
the package definition.
3) Files
A file is a user defined file that is described by a file definition. A file
definition contains additional information about a file that is normally not
stored inside a file system, such as checksums.

The LVM always tries to make packages complete. This is accomplished by trying
to find valid and working files that are referenced in the package description.
Please note that the resolver doesn't care if a file is on the same storage  
device as the packet definition. If the file is on the same storage device, it  
will be preferred, but files from other storage devices may be used by the 
package if no compatible and working file is found on the same storage device.
Make sure to get package details by using the DISPLAY PACKAGE command (details
below) to check if all the files that are currently referenced by the package
are on the same storage device as the package. Failing to do so may cause
inoperability as soon as a storage device has been removed, leading to an
incomplete and inoperable package.

Option -b may be used to deactivate this kind of behavior. If the option is
active, the LVM will bind packages to file definitions on the same storage  
device the package is residing on.

**** Special files created by the LVM
-------------------------------------------------------------------------------
"/mnt/lvm/acios_db.ini" (aka "/dev/lvm/acios_db.ini")
-------------------------------------------------------------------------------
This file is created dynamically and contains a list of the activated database
files. Whenever a packet is activated or deactivated, the content of the file
changes. Normally, all files specified in file definitions make it into this
file in the following form:
ANY:<path to file>
One exception for this rule are .iso files, which are traditionally not 
included in the acios_db.ini and are therefore made invisible by injecting  
them in the form of a comment:
#SDS:<path to file>
This provides and informal way to see which files are activated, even if there
is no other IPC mechanism to communicate a list of activated databases to
the highlevel application. The SDS tag stems from the assumption that all    
.iso files are SDS database files, which is not universally correct.
-------------------------------------------------------------------------------
"/dev/lvm" (aka "/mnt/lvm/comif/console") 
-------------------------------------------------------------------------------
This is the console device of the LVM. The user can sent commands into this  
device as specified by the command summary in this use file. 
-------------------------------------------------------------------------------
"/mnt/lvm/comif/sdh"
-------------------------------------------------------------------------------
This is the name of the solitary device handler, and other features that are
used for debugging and testing of the LVM. It provides a way to start an    
automatic installation of databases packages, and also implements an
automounter to automatically mount and use USB-Sticks, DVD-Media and other
sources to perform an installation.  
THIS INTERFACE IS CURRENTLY NOT SUPPORTED.
...

Arguments passed to the vdev-logvolmgr process are "-p SDS,MAPSTYLES -A -B acios_db.tmp -vvrml -f" on both MMI3G High and Plus systems (as confirmed by inspection of /mnt/ifs-root/etc/mmi3g-srv-starter.cfg).

Additional build information extracted from the QNX binary:

NAME=vdev-logvolmgr
DATE=2008/09/10_11-23-08_UTC
HOST=OEHHOBRUEGGMANN
USER=OBrueggmann 
PLABEL=PL_qnx_vdev-logvolmgr_08373A
QNX_VERSION=632
QNX_LABEL=RL_qnx_os_632_PSP3_08204A
GCC_VERSION=3.4.4
CPU=sh

[DrGER]

This is the second part of the post on usage information for the MMI3G QNX vdev-logvolmgr binary describing the LVM protocol command interface:

**** Commands received through /dev/lvm (Protocol Version 1.0.0):
-------------------------------------------------------------------------------
MOUNT STORAGE DEVICE AS <storage name> FROM <device> TO <mountpoint> [add_opt]
-------------------------------------------------------------------------------
Create a new storage device handle named <storage name>, that is using the 
device specified at <device> to create the mountpoint at <mountpoint>. 
Additional options may be passed to the MOUNT command to modify the behavior
of the command:  
LINK - Only create a symbolic link from <device> to <mountpoint>. This should  
be used if the device in question is already mounted. If LINK is NOT given,
the LVM will always attempt to mount the given device as if it contains
a qnx4 file system.
READ - Treat the storage device as read only. This changes the behaviour of the
LVM so that it will try to remount devices as readable in case the user wants
to install or copy something to a storage device. If LINK is specified, nothing
special will happen as soon as the mount command is executed. The LVM
will try to make sure it is able to write to the disk whenever a user
requests it, regardless of the LINK statement.
REPAIR - In case this option is specified, the LVM will attempt to remount
read only storage devices to repair file data bases. In case a the storage
device isn't specified as RAW, remounting will occur as soon as the LVM
fails to load a config.nfm - in that case, the LVM will try to generate a
new package database on the storage device using a built-in default config.nfm.
The -r option may be specified on the command line to force this behavior even
if the caller doesn't specify this option. File system checks will not occur on
devices that have been mounted as read only.
RAW - By passing this option, the LVM will treat the storage device as a device
that contains user defined data only, and will not search for a package database
when mounting it.
The outcome is undefined if other parameters are given.
-------------------------------------------------------------------------------
DISMOUNT STORAGE DEVICE <storage name> 
-------------------------------------------------------------------------------
Dismounts the storage device specified by <storage name>. The caller should
only attempt to dismount storage devices that have been mounted before.
-------------------------------------------------------------------------------
DISPLAY RESOURCES
-------------------------------------------------------------------------------
Shows a list of resources currently maintained by the LVM. The list sent as a
type 30x response (see below), and holds the following comma seperated data
(in order of appearance):
name of the resource
type of the resource (LVM_TPE_PACKAGE, LVM_TPE_STORAGE, LVM_TPE_FILEDEF)
residence of the resource (storage device it's residing on)
location of the resource (current system path)
version information
condition (2 = GOOD, 3 = BAD, etc.. tbd.)
size of the resource
free space in the resource (set to zero for everything but LVM_TPE_STORAGE).
file type of the resource (as specified in the file definition) 
user flags (TODO)
copy protection flag (TODO) 
-------------------------------------------------------------------------------
INSTALL PACKAGE <package name> [FROM STORAGE DEVICE <storage source>] TO
 STORAGE DEVICE <storage target>
-------------------------------------------------------------------------------
Installs a package that is residing on <storage source> to <storage target>.
If the optional source storage device is not given, the first package that
is matching the name <package name> will be used to attempt the installation.
It's recommended to always specify the source storage device.
Note: The LVM currently does not check for storage space constrains. Please
make sure that there is enough space to install the requested file definitions.
The information provided by the DISPLAY RESOURCES and DISPLAY PACKAGES commands
may be used to determine if there is enough space to install a package.
-------------------------------------------------------------------------------
REPLACE PACKAGE <package name> ON STORAGE DEVICE <storage target> WITH PACKAGE
 <new package name> ON STORAGE DEVICE <storage source>
-------------------------------------------------------------------------------
Installs a new package, but deletes another package in the process. Use this
function if you plan to do an incremental update and there is a package
on the storage device that may share some file definitions with the new
package you're planning to install. Files that belong to the old package only
will be deleted, files belonging to both the old and the new package will
remain on the storage device. Additionally, all files of the new package will
be installed in case they are not yet on the specified target storage device.
Note: Additional notes of the INSTALL command also apply here.
-------------------------------------------------------------------------------
REMOVE PACKAGE <package name> FROM <storage name>
-------------------------------------------------------------------------------
Removes a package from a storage device. Also all file definitions that are
referenced by the package will be removed from the same storage device,
as long as they are not currently referenced by another package.
-------------------------------------------------------------------------------
ACTIVATE PACKAGE <pkgname> ON STORAGE DEVICE <storage name> AT <activation point>
-------------------------------------------------------------------------------
Activate package <pkgname> residing on the storage device <storage name>  
into the device tree. A package can only be activated once. The result of
attempting to activate a package more than once is not defined.
-------------------------------------------------------------------------------
DISCARD ORPHANED FILE DEFINITIONS ON STORAGE DEVICE <storage name> 
-------------------------------------------------------------------------------
Removes file definitions that are not referenced by a package from a storage
device. May be used to clean up a storage device with broken packet
definitions.
-------------------------------------------------------------------------------
INITIALISE STORAGE DEVICE <storage name>
-------------------------------------------------------------------------------
Recreates structures on the storage device. ALL data on the storage device,
starting from the path given in the mount command, will be deleted. 
-------------------------------------------------------------------------------
EXECUTE QUICK CHECK OF PACKAGE <package name> ON STORAGE DEVICE <storage name>
-------------------------------------------------------------------------------
Checks the given package by executing a quick check. The file definition in the
must contain quick check information. 
-------------------------------------------------------------------------------
EXECUTE THOROUGH CHECK OF PACKAGE <package name> ON STORAGE DEVICE
<storage name>
-------------------------------------------------------------------------------
Checks the given package by executing a thorough check. The file definition
in the must contain either a crc or md5 field. Md5 is preferred, while CRC32
is for testing only.
Please consult the description for Options -n and -P regarding the thorough
check, which may be used as a background check by specifying chunks that
should be checked. As soon as all chunks are checked, the LVM will decide if
the file is OK for use or not.
-------------------------------------------------------------------------------
DELETE FILE DEFINITION <fdef name> FROM STORAGE DEVICE <storage name>
-------------------------------------------------------------------------------
Removes a file definition regardless of its state, as long the the storage
device specified is fully operable. Use this to delete individual file
definitions in case they are not referenced by a package on the same storage
device and they take up space needed by a new installation.
-------------------------------------------------------------------------------
DISPLAY PACKAGE <package name> [ON STORAGE DEVICE <storage name>]
-------------------------------------------------------------------------------
Shows information about a package. If no <storage name> is given, the first
packet matching the name will be used to display the information. The command
outputs information about the referenced file definitions and version
information of the package.
The Data sent is in a KEY=VALUE format. Multiple sending of a KEY with the same
name indicates that there is more than one item of type KEY in the package.
Example:
301 SEQ00,FILEDEF=XAC_ECE_12_0_2,/fs/cd0/pkgdb/XAC_ECE_12_0_2/XAC.DB,CD0
301 SEQ01,FILEDEF=GDB_ECE_12_0_2,/fs/cd0/pkgdb/GDB_ECE_12_0_2/GDB.GDB,CD0
301 SEQ02,FILEDEF=LIT_ECE_12_0_2,/fs/cd0/pkgdb/LIT_ECE_12_0_2/LIT.DB,CD0
301 SEQ03,FILEDEF=SPEECH_2000_12_0_2,/fs/cd0/pkgdb/SPEECH21202/SPEECH.DB,CD0
FILEDEF keys contain the name of the File Definition as referenced by the
package, and if a file definition with the required name exists in the system
and is known to the LVM, the path to the file(s) in the file definition, aswell
as the name of the storage device the file is on.
If the file definitions hasn't been found in the system, the fields will contain
the string ##INVALID##.
301 SEQ04, MARKET=ECE 
MARKET informs the client about the market the package is intended for.
301 SEQ05, VERSION=12.3.2
VERSION informs the user about the version of the package.
301 SEQ05, CUSTOMER=ExampleCustomer
CUSTOMER informs the user about the customer the package is intended for. 
301 SEQ06, TYPE=base
TYPE informs the user about the type of the package.
301 SEQ07, SET=daisychain,2,1,<NEXTPACKAGENAME>
SET informs the user about the type of set, if there is any.
-------------------------------------------------------------------------------
SET KEY <keyname> TO VALUE <value>
-------------------------------------------------------------------------------
Set a configuration key to the given value.
-------------------------------------------------------------------------------
+++ABORT
-------------------------------------------------------------------------------
Abort the current operation. This command must be sent as a complete string,
or abortion will not occur. The operation may be finished before the abortion
comes into effect.

**** Messages send by the LVM

The LVM generates messages (terminated by LF) if it receives messages. There
are certain types of messages, prefixed by a three digit number and a 
whitespace. The data following the whitespace must be interpreted depending  
on the message prefix.

------------------------------------------------------------------------------- 
200 RESULT <errcode>,<errcodetxt>,<errreason>,<errdesc>
-------------------------------------------------------------------------------
!!NOTE: The error codes have been changed. Please refer to the error code in
the supplemental information!!
The result of a user-triggered operation; "errcode" can be 1 or 0 depending on
if an error occured or not. "errcodetxt" is either "ERROR" or "OK".
"errreason" is a decimal value assuming the value of an extended error code,
and gives the caller a possible explaination as to why the error occured:
   0     No error occured, or the error condition is not known
   1     Not enough memory to perform the requested operation
   2     There is an error in the command syntax
   3     Internal failure
   4     A resource referenced by the command does not exist.
   5     The resource already exists
"errdesc" assumes any text, and may contain more detailed error information
for human users. It's not intended to be checked by a machine.
-------------------------------------------------------------------------------
201 <event>
-------------------------------------------------------------------------------
This is an asynchronious event and informs the user about a changing condition
in response to a command. At the moment, there is only one event defined:
-------------------------------------------------------------------------------
201 CONFIGURATION CHANGED,<info>
-------------------------------------------------------------------------------
This happens whenever the internal configuration, dependencies or conditions
change. After receiving that message, the users should re-read the
resource list by sending a DISPLAY RESOURCE command, and, if interested in
packet relationships, a DISPLAY PACKAGE command for every package the client is
interested in.
This message will also be generated if a user on another LVM connection caused
a configuration change. In that case, the <info> field will be filled and set  
to "REMOTE". Please note that the comma will NOT appear in the message
if there is no additional info to be sent.
-------------------------------------------------------------------------------
203 START PROCESS <process>, STEPS <numsteps>
-------------------------------------------------------------------------------
A new process named <process> has been started. The process is going to need
<numsteps> to complete. Processes are run nested, meaning that one process
may result in a nother process being spawned.
-------------------------------------------------------------------------------
204 END PROCESS <process>
-------------------------------------------------------------------------------
A process named <process> has been completed.
-------------------------------------------------------------------------------
202 PROCESS PROGRESS <process>,<curstep> of <steps> 
-------------------------------------------------------------------------------
Status update on a currently running process named <process>. Step <curstep>
of <steps> is currently being processed.
-------------------------------------------------------------------------------
205 LVM PROTOCOL VERSION <version>
-------------------------------------------------------------------------------
Always sent after establishing a connection the the LVM, this message informs
the user about the protocol specification currently used by the client. The
version is tranferred in the form of MA.MI.CH, where MA is the major number of
the protocol specification, MI is the minor version and CH is a change index
in the protocol handling that should not affect the compatibility between two
components.
Added functions or added return data justifies a change in the MI field,
changes that affect the order of return data or removal/renaming of instructions
requires a change in the MA field. Additional data should be ignored as long   
as the MA field doesn't change.
-------------------------------------------------------------------------------
206 <topic>
-------------------------------------------------------------------------------
This message may be sent by the LVM to indicate the topic of the upcoming
process, and may be used by the user to find out what exactly is currently  
being handled by the LVM.
-------------------------------------------------------------------------------
210 <percent>,<bytetotal>,<bytedone>,<timetotal>,<timedone>,<datarate>
-------------------------------------------------------------------------------
This message may be sent by the LVM during an INSTALL operation. It indicates  
the overall progress in percent with regard to the file size of the all the
file definitions being transferred.
If a value is not supported by the current LVM, there will be no characters
between the commas.
This message may also be generated during REPLACE operations, as REPLACE
operations will invoke an INSTALL operation internally.
-------------------------------------------------------------------------------
3XX SEQ<seqno>,<anydata> 
-------------------------------------------------------------------------------
This message is sent in response to DISPLAY commands. "anydata" contains
command specific data. The caller is supposed to know the format of the 
response. D data is transferred in a comma seperated list, or in a
KEY=VALUE fashion, depending on the command. The <seqno> assumes the value  
of the current line in the output stream. This type of message is only send  
if a process sent a request command before. X may take a value from 00-99.

[DrGER]

--RESERVED--

[BriefObsessions]

Signed up to the forums just to say thanks @DrGER. Installed your activator on an RNS850.

[DrGER]

Signed up to the forums just to say thanks @DrGER. Installed your activator on an RNS850.

Thanks for the feedback, @BriefObsessions. I believe that the fellow who described this work-around first in early 2016, Keldo GLIANA, is Australian. Note that the technique doesn't "activate" the database, since it doesn't even try to configure a proper FSC file for the VIN/database. Still, it's good to know that the method also works with an RNS-850, which means that the QNX OS is functionally equivalent to Harman/Becker MMI3G. --g

[DontSay]

Hello,

I have this problem, FSC not found with basic internet activator. Found this thread, tried to use this patch, but still i cannot use my navi, white screen.




Log

[INFO] Start: Thu Jan 01 00:02:00 UTC 1970; Timestamp: 20100203_042440; MU: MMI3G

[INFO] MMI3G Nav Database Unblocker: navunblocker-v221225

[ACTI] Appending patch to /usr/bin/manage_cd.sh ...
mv: Moving /mnt/efs-system/usr/bin/manage_cd.sh to /mnt/efs-system/usr/bin/manage_cd.sh-ORIG
cp: Copying /mnt/efs-system/usr/bin/manage_cd.sh-ORIG to /mnt/efs-system/usr/bin/manage_cd.sh

[ACTI] Copy FSC and acios_db.ini files to /mnt/sdcard10t12/var
cp: Copying /mnt/efs-persist/FSC/00040003.fsc to /mnt/sdcard10t12/var/00040003.fsc
cp: Copying /mnt/efs-persist/navi/db/acios_db.ini to /mnt/sdcard10t12/var/acios_db.ini

[INFO] End: Thu Jan 01 00:02:01 UTC 1970; Timestamp: 20100203_042441
press any key

[DrGER]

...
I have this problem, FSC not found with basic internet activator. Found this thread, tried to use this patch, but still i cannot use my navi, white screen.
...

You have MMI3G High (HNav). You might be interested in this solution, instead: https://www.a5oc.com/threads/upgradi...imedia.180005/
But, sometimes we see that the NAV needs to recalibrate itself after an update. --g

[DanielHamilton]

Just want to confirm this worked on an MMI 3GH -> 3G+ retrofit in an '11 A4. I now have the latest FW and nav updates working on the 3G+, no activation issues. DrGER, many thinks. You're a wizard.