[bsd107]

I don't think anyone has received a E90 LCI w/iDrive with only 8GB of space for music. Everyone who has ever posted on this (including me) has had 12-13GB available for music.

For me, this space isn't very useful, as the codec support on the hard drive is much more limited than the codecs available for use through the 6NF USB port.... (specially, WMA Lossless and PCM WAV are supported through the 6NF USB, but only lossy codecs are supported on the hard drive)

[bsd107]

Allocating 500MB for Contacts is rediculous - given that you have to enter all of your contacts through iDrive. I.e. no way to copy names/phonenumbers/addresses from your cell phone via Bluetooth.....

[bsd107]

Reading the details in the "E90 CIC info.pdf" document reminds me once again why I love this car so much....

[bsd107]

In "E90 CIC info.pdf" it discusses how the "Almanac data" remembers where you car is located, so that when you start the car again the GPS remembers where you are and doesn't have to wait for the GPS receiver to boot up and synch with satellites.

Unfortunately, what I have found is that certain portions of the Nav system take at least 30 seconds to complete booting. Specifically, I cannot access the Address Book for at least 30 seconds while the NAV is booting. What is strange is that I can pull up an address from Previous Destinations and select that as a destination almost immediately. But the Address Book seems to be the last thing that finished booting. It seems like it verifies addresses before it displays them, although I don't understand the purpose for this...

The Speech recognition system also seems to be a system you have to wait 30-60 seconds after starting the car before it starts functioning.

Overall, I don't think the E90 LCI iDrive NAV takes any longer to boot up and get functioning than other recent cars with factory nav systems (Honda, Lexus). But, it seems like the delay could be further reduced with updates to the programming (i.e. let the Address Book function right away).

[SoYank]

Originally Posted by bsd107

I've been using a Sony 16GB USB thumb drive for six months now with no problems.

It could be an issue with my particular thumbdrive. It did work when it only had a bit over 8GB of files but stopped when I put 12.5GB. Maybe I should try it again.

[Technic]

Originally Posted by sbux

06-08 E90 CIC PDF is needed too here. Please post if you have it .... Thanks....

There was no CIC between 06-08... that was a CCC. I think that the document is somewhere here in the forum...

[Kilgore Trout]

Originally Posted by SoYank

It could be an issue with my particular thumbdrive. It did work when it only had a bit over 8GB of files but stopped when I put 12.5GB. Maybe I should try it again.

I have a 32GB drive in mine. Works great. No problems whatsoever.

[Professor///M]

Originally Posted by bsd107

Allocating 500MB for Contacts is rediculous - given that you have to enter all of your contacts through iDrive. I.e. no way to copy names/phonenumbers/addresses from your cell phone via Bluetooth.....

You can copy your names of bluetooth contacts & addresses into iDrive with very little hassle into the "my contacts" section.

Just click on "options" when you have the name selected, then edit, then there will be a top and bottom prompt to store in the vehicle.


Works great with the iPhone.

[David1]

Originally Posted by Technic

8GB

I already have just under 8gb on mine and shows I can still add an addition 3.9xxxxgb available so mine is 12GB for music.

[oilcrankinject]

Lets get back on topic guys......


I am sorry for the long read but I think this may help us figuire out the file structure on the HDDs.

Although we'll discuss different types of archives below, here's a quick summary of the file extensions associated with the different utilities:

Extension Utility
.tar pax or tar
.cpio pax or cpio
.gz gzip or gunzip
.tar.gz or .tgz tar -z
.z or .F melt

No matter how robust a filesystem is designed to be, there will always be situations in the real world where disk corruption will occur. Hardware will fail eventually, power will be interrupted, and so on.

The QNX 4 filesystem has been designed to tolerate such catastrophes. It is based on the principal that the integrity of the filesystem as a whole should be consistent at all times. While most data is held in the buffer cache and written after only a short delay, critical filesystem data is written immediately. Updates to directories, inodes, extent blocks, and the bitmap are forced to disk to ensure that the filesystem structure on disk is never corrupt (i.e. the data on disk should never be internally inconsistent).

If a crash occurs, you can such utilities as fdisk, dinit, chkfsys, and spatch to detect and repair any damage that happened to files that were open for writing at the time of the crash. In many cases, you can completely restore the filesystem.

Sometimes the damage may be more severe. For example, it's possible that a hard disk will develop a bad block in the middle of a file, or worse, in the middle of a directory or some other critical block.

Again, the utilities we've provided can help you determine the extent of such damage. You can often rebuild the filesystem in such a way as to avoid the damaged areas. In this case, some data will be lost, but with some effort, you can recover a large portion of the affected data.

Backup strategies
Your backup strategy will consist of making one or more backups on a periodic or triggered basis. For each backup you incorporate in your strategy, you have to choose:

the storage media and location of the backup data
how to archive, and optionally, compress your data
the contents, and frequency or trigger condition of the backup
automated versus manual backup
local versus remote control of the backup
Often, a comprehensive backup strategy incorporates some backups on the local side (i.e. controlled and stored on the same machine that the data is located on), and others that copy data to a remote machine. For example, you might automatically back up a developer's data to a second hard drive partition on a daily basis and have a central server automatically back up the developer's data to a central location on a weekly basis.

Choosing backup storage media and location
Early in the process of determining your backup strategy, you're likely to choose the location of your data backups and the media to store the backups on, because these choices are the primary factors that affect the hardware and media costs associated with the system. To make the best choice, first take a close look at what you need to back up, and how often you need to do it. This information determines the storage capacity, transfer bandwidth, and the degree to which multiple users can share the resource.

Your choices of backup media vary, depending on whether you create backup copies of your data on a local machine or on a remote machine by transferring the data via a network:

Local backups offer the advantage of speed and potentially greater control by the end user, but are limited to backup technologies and media types that Neutrino supports directly.
Remote backups often allow use of company-wide backup facilities and open up additional storage options, but are limited by the need to transfer data across a network and by the fact that the facilities are often shared, restricting your access for storing or retrieving your backups.
Here's a summary of some of the backup media you might consider, and their availability for local or remote backups:

Media Local/Neutrino Remote
Floppy Yes Yes
LS-120 Yes Yes
Tape No Yes
CD Yes Yes
DVD No Yes
Hard disk Yes Yes
Flash device Yes Yes
USB mass-storage device Yes Yes

Choosing a backup format
When backing up your data, you need to decide whether to back up each file and directory separately, or in an archive with a collection of other files. You also need to decide whether or not to compress your data to reduce the storage requirements for your backups.

The time lost to compression and decompression may be offset to a degree by the reduced time it takes to write or read the compressed data to media or to transfer it through a network. To reduce the expense of compression, you may choose to compress the backup copies of your data as a background task after the data has been copied -- possibly days or weeks after -- to reduce the storage requirements of older backups while keeping newer backups as accessible as possible.

Controlling your backup
You should back up often enough so that you can recover data that's still current or can be made current with minimal work. In a software development group, this may range from a day to a week. Each day of out-of-date backup will generally cost you a day of redevelopment. If you're saving financial or point-of-sale data, then daily or even twice-daily backups are common. It's a good idea to maintain off-site storage.

Archiving your data
You can store backups of each of your files separately, or you can store them in an archive with other files that you're backing up. Files stored in an archive can be more readily identified as belonging to a certain time or machine (by naming the archive), more easily transferred in bulk to other systems (transfer of a single archive file), and can sometimes be more readily compressed than individual files can.

You have several archive formats to choose from under Neutrino, including pax, and tar. Neutrino also supports cpio (*.cpio), but we recommend it only when the archive needs to be readable by other systems that use cpio archives.

Creating an archive
The simplest backup you can do on your system is to duplicate the files individually using cp or pax. For example, to duplicate a single file:

cp -t my_file backup_directoryor:

echo my_file | pax -rw backup_directoryTo back up an entire directory, type:

cp -Rt my_directory backup_directoryor:

find my_directory -print | pax -rw backup_directoryTo back up only certain files matching some criteria, use the find utility or other means of identifying the files to be backed up, and pipe the output to pax -rw, like this:

find my_directory -name '*.[ch]' | pax -rw backup_directory To combine individual files into a single archive, use tar or pax. These utilities take all the files that you give them and place them into one big contiguous file. You can use the same utilities to extract discrete files from the archives.


--------------------------------------------------------------------------------
The filesystem can't support archives -- or any other files -- that are larger than 2G.

--------------------------------------------------------------------------------

When you use pax as an archiver (pax -w mode), it writes tar-format archives. Your choice of which to use is based on the command-line syntax that works better for you, not the format of the archives, because the formats are identical. The pax utility was created as part of the POSIX standard to provide a consistent mechanism for archive exchange (pax stands for Portable Archive eXchange), thus avoiding conflict between variants of the tar utility that behave differently.

You can create archives of:

Single files (although there isn't much point in doing so with tar and pax). For example:
pax -wf my_archive.tar code.c
This command takes code.c and creates an archive (sometimes referred to as a "tarball") called my_archive.tar. The -wf options tell pax to write a file.

Multiple files -- to archive more than one file, pass more files on the end of the command line. For example:
pax -wf my_archive.tar code.c header.h readme.txt
Pax archives them all together resulting in the archive, my_archive.tar.

Directories -- just specify a directory name on the command line:
pax -wf my_archive.tar workspace
This command archives all the contents of workspace into my_archive.tar.

Partitions -- specify the directory name of the partition:
pax -wf my_archive.tar /fs/hd0-t79
This command archives all the contents of the t79 partition into one very large archive, my_archive.tar.

You can keep the archive on your local system, but we recommend that you keep a copy of it on a remote system; if the local system gets physically damaged, or the hard disk is corrupted, you'll lose a local archive.

Extracting from an archive
To extract from the archive, you can use pax with the -r option:

pax -rf my_archive.taror tar with the -x (extract), -v (verbose), and -f (filename) options:

tar -xvf my_archive.tar
--------------------------------------------------------------------------------
To view the contents of the archive without extracting them, use tar with the -t option instead of -x.

--------------------------------------------------------------------------------

Compressing an archive
An archive can be quite large -- especially if you archive the entire partition. To conserve space, you can compress archives, although it takes some time to compress on storage and decompress on retrieval.

Neutrino includes the following compressors and decompressors:

bzip2 and bunzip2
freeze and melt
gzip and gunzip
The best choice is usually gzip, because it's supported on many operating systems, while freeze is used mainly for compatibility with QNX 4 systems. There are also many third-party compressors.


--------------------------------------------------------------------------------
The gzip utility is licensed under the Gnu Public License (GPL), which is a consideration if you're going to distribute gzip to others as part of the backup solution you're developing.

--------------------------------------------------------------------------------

For example, to compress my_archive.tar to create a new file called my_archive.tar.gz, type:

gzip my_archive.tarThis file is much smaller than the original one, which makes it easier to store. Some of the utilities -- including gzip -- have options that let you control the amount of compression. Generally, the better the compression, the longer it takes to do.


--------------------------------------------------------------------------------
The default extension is .tar.gz, but you'll see others, such as .tgz. You can use the -S option to gzip to specify the suffix.

--------------------------------------------------------------------------------

Decompressing the archive
To decompress the archive, use the compressor's corresponding utility. In the case of a .gz or .tgz file, use gunzip:

gunzip my_archive.tar.gzor:

gunzip my_archive.tgzThese commands decompress the file, resulting in my_archive.tar. You can also use tar with the -z option to extract from the archive without decompressing it first:

tar -xzf my_archive.tgzStorage choices
CDs
You can back up to a CD by using a CD burner on the Neutrino system or by creating an ISO image and copying it to a system with a CD burner that can burn ISO images.

You can use cdrecord to burn CDs on a Neutrino system. To get this software, go to our website, http://www.qnx.com/.

In either case, you have to create an ISO image of the data that you want to burn to a CD. You can do this with mkisofs, a utility that's included with cdrecord.

Before you can create an ISO image, you need to arrange the files into the directory structure that you want to have on the CD. Then use mkisofs, like this:

mkisofs -l -f -r -joliet -quiet -V"My Label" -o my_iso_image.isoThis command creates an ISO image named my_iso_image.iso with the label, My Label, using the Joliet file format, allowing full 31-character filenames (-l), following all symbolic links when generating the filesystem (-f), and generating SUSP and RR records using the Rock Ridge protocol (-r).

Once you've created the ISO image, you can send the image to a system that can burn an ISO image or you can burn it using cdrecord:

cdrecord -v speed=2 dev=/dev/cd0 my_iso_image.isoThis command burns a CD at dual speed (2), using the CD burner called cd0, from the ISO image called my_iso_image.iso. For more information, see the documentation for cdrecord.


--------------------------------------------------------------------------------
For a list of supported CD drives, see the README file that comes with the cdrecord source code.

--------------------------------------------------------------------------------

Bootable CDs
You can also make the CD bootable, using cdrecord and its associated utilities, as follows:

1.Create a bootable floppy that calls the needed scripts and includes the needed binaries in the image.
2.Make an image of the floppy, using the dd utility. For example:
dd if=/dev/fd0 of=/floppy.img
3.Create a directory with all the needed binaries, in the layout that you want in your CD-ROM ISO image. For example:
mkdir iso_image
cp -Rc /bin iso_image/bin
cp -Rc /etc iso_image/etc
....
4.Make sure that the isocatalog is in /usr/share/cdburning on the system.
5.Create the ISO image using mkisofs, making sure to specify the catalog with the -c option. For example:
mkisofs -l -f -r -joliet -quiet -V"My Label" -b floppy.img \
-c /usr/share/cdburning/isocatalog -o my_iso_image.iso
6.Burn the ISO image to a CD.
Removable media
Other forms of removable media are also useful for backing up data. Neutrino supports LS-120, magnetic optical (MO drives), internal ZIP drives, and USB mass-storage devices. Each has its own benefits and weaknesses; it's up to you to determine which form of media is best for backing up your data. For instructions on how to install this hardware, see the Connecting Hardware chapter in this guide.

Backing up physical hard disks

--------------------------------------------------------------------------------
The instructions here are for copying from one hard disk to another of identical properties (size, make model). To make a copy of a drive that differs in size and make, contact technical support for the QNX_Drive_Copy utility.

--------------------------------------------------------------------------------

You can make identical images of hard drives under Neutrino, using simple utilities. This is called making a raw copy of the drive.

If you have an identical hard drive (manufacturer, size, model number), you can simply attach the drive to the system. Make sure you know which position the drive is set up as (e.g. EIDE Primary Slave).

Once you've attached the drive, boot the Neutrino system. The system should automatically detect the hard drive and create an entry in the /dev directory for it. The new entry should appear as /dev/hd1 if there are only two drives in the system. If there are more than two, then the drive could be hd1, hd2, and so on. In this case, use the fdisk to identify which drive is which. The new drive shouldn't have any partitions set up on it and should be blank.


--------------------------------------------------------------------------------
Be absolutely positive about the drives before continuing, because if you don't identify the drives correctly, you could copy the contents of the blank hard drive onto your original drive, and you'll lose all your data. There's no way to recover from this.

--------------------------------------------------------------------------------

Once you've identified the drives, type:

cp -V /dev/hd0 /dev/hd1where hd0 is the original hard disk, and hd1 is the new drive that you're copying to.

This command copies everything from the first drive, including partition tables, boot loaders, and so on, onto the second drive. To test that the copy was successful, remove the original drive and put the backup drive in its place, then boot the system from the backup drive. The system should boot into Neutrino and look the same as your original drive. Keep the backup in a safe location.

Ghost Images
Some Neutrino users have used ghost images for backups, but we don't recommend them. Partition information might not be restored properly, causing filesystems to not boot correctly. If you run fdisk again on the drive, the drive reports incorrect information, and fdisk writes incorrect data to the drive.

Remote backups
Remote backups are generally a much safer solution than storing a backup on a local system, because a remote server is generally more reliable -- as the saying goes, don't put all your eggs in one basket.

Depending on your situation, it might make sense to buy a good system with lots of server-grade hardware, and then buy regular systems to develop on. Make regular backups of your server.

CVS
Neutrino ships with a copy of the CVS (Concurrent Versions System) client utility. In order to use CVS, you need to have a CVS server (preferably one that your company administers). CVS lets you manage your source archives safely and remotely. For more details, see the Using CVS chapter in this guide.

Remote filesystems
Storing a second backup on a remote system is often a simple yet effective way to prevent the loss of data. For example, if you have a basic archive of your code in a separate directory on your local system, and then the hard disk breaks down for some unforeseen reason, you've lost your local backup as well. Placing a copy on a remote filesystem effectively lowers the chance of losing data -- we highly recommend it.


--------------------------------------------------------------------------------
If you place a file on a non-Neutrino filesystem, you might lose the file's permissions. Files under Neutrino (like other UNIX systems) have special file permissions (see Working with Files) that are lost if you store individual files on a Windows-based filesystem. If you create an archive (see "Archiving your data," above), the permissions are preserved.

--------------------------------------------------------------------------------

Other remote backups
There are other remote version systems (similar to CVS) that are available to Neutrino via third-party solutions. Many of them are free; search the Internet for the tools that are right for your company and project.

QNX 4 disk structure
If you ever have a problem with a QNX 4 filesystem, you'll need to understand how it stores data on a disk. This knowledge will help you recognize and possibly correct damage if you ever have to rebuild a filesystem. The <sys/fs_qnx4.h> header file contains the definitions for the structures that this section describes.

For an overall description of the QNX 4 filesystem, see the Working with Filesystems chapter.

Partition components
A QNX 4 filesystem may be an entire disk (in the case of floppies) or it may be one of many partitions on a hard disk. Within a disk partition, a QNX 4 filesystem contains the following components:

loader block
root block
bitmap blocks
root directory
other directories, files, free blocks, etc.

--------------------------------------------------------------------------------




--------------------------------------------------------------------------------

Components of a QNX 4 filesystem in a disk partition.

These structures are created when you initialize the filesystem with the dinit utility.

Loader block
The first physical block of a disk partition is the loader block. It contains the bootstrap code that the BIOS loads and then executes to load an OS from the partition. If a disk hasn't been partitioned (e.g. it's a floppy), this block is the first physical block on the disk.

Root block
The root block is the second block of a QNX 4 partition. It's structured as a standard directory and contains a label field and the inode information for these special files:

the root directory of the filesystem (usually /)
/.inodes
/.boot
/.altboot
The files /.boot and /.altboot contain images of the operating system that can be loaded by the QNX bootstrap loader.

Normally, the QNX loader loads the OS image stored in the /.boot file. But if the /.altboot file isn't empty, you can load the image stored in it. For more information, see the Controlling How Neutrino Starts chapter.

Bitmap blocks

Several consecutive blocks follow the root block. The bitmap blocks form the bitmap for the QNX 4 partition. One bit exists for each block on the partition; thus one bitmap block is used for every 4096 disk blocks (corresponding to 2M of disk *******.

If the value of a bit is zero, the corresponding block is unused. Unused bits at the end of the last bitmap block (for which there are no corresponding disk blocks) are turned on.

Bit assignments start with the least-significant bit of byte 0 of the first bitmap block -- which corresponds to QNX 4 block #1.

Root directory

The root directory follows the bitmap blocks. The root directory is a "normal" directory (see the "Directories" section), with two exceptions:

Both "dot" (.) and "dot dot" (..) are links to the same inode information, namely the root directory inode in the root block.
The root directory always has entries for the /.bitmap, /.inodes, /.boot, and /.altboot files. These entries are provided so programs that report information on filesystem usage see the entries as normal files.
The dinit utility creates this directory with initially enough room for 32 directory entries (4 blocks).

The root directory (/) contains directory entries for several special files that always exist in a QNX 4 filesystem. The dinit utility creates these files when the filesystem is first initialized.


--------------------------------------------------------------------------------




--------------------------------------------------------------------------------

Contents of the root directory, /.



File Description
/. A link to the / directory
/.. Also a link to the / directory
/.bitmap Represents a read-only file that contains a map of all the blocks on the disk, indicating which blocks are used.
/.inodes A normal file of at least one block on a floppy/RAM disk and 16 blocks on other disks, /.inodes is a collection of inode entries. The first entry is reserved and used as a signature/info area. The first bytes of the .inode file are set to IamTHE.inodeFILE.
/.longfilenames An optional file that stores information about files whose names are longer than 48 characters; see "QNX 4 filesystem" in Working with Filesystems.
/.boot Represents an OS image file that will be loaded into memory during the standard boot process. This file will be of zero length if no boot file exists.
/.altboot Represents an OS image file that will be loaded into memory during the alternate boot process. This file will be of zero length if no alternate boot file exists.

Directories

A directory is simply a file that has special meaning to the filesystem; the file contains a collection of directory entries.


--------------------------------------------------------------------------------




--------------------------------------------------------------------------------

A directory entry.

The bits in the i_status field indicate the type of the directory entry:

QNX4FS_FILE_LINK QNX4FS_FILE_USED Entry type
0 0 Unused directory entry
0 1 Normal, used directory entry
1 0 Link to an entry in /.inodes (which should be used)
1 1 Invalid

The first directory entry is always for the . ("dot") link and includes a directory signature ("I[heart-symbol]QNX"). The hexadecimal equivalent of the [heart-symbol] character is 0x03. This entry refers to the directory itself by pointing to the entry within the parent directory that describes this directory.

The second entry is always for the .. ("dot dot") link. This entry refers to the parent directory by pointing to the first block of the parent directory.

Every directory entry either defines a file or points to an entry within the /.inodes file. Inode entries are used when the filename exceeds 16 characters or when two or more names are linked to a single file. If you've enabled support for long filenames, the root directory of the filesystem also includes the .longfilenames file, which stores information about files whose names are longer than 48 characters.

The first extent (if any) of a file is described in the directory/inode entry. Additional file extents require a linked list of extent blocks whose header is also in the directory/inode entry. Each extent block can hold location information for up to 60 extents.

Links

Files with names greater than 16 characters, and files that are links to other files, are implemented with a special form of directory entry. These entries have the QNX4FS_FILE_LINK bit (0x08) set in the i_status field.

For these files, a portion of the directory entry is moved into the /.inodes file.


--------------------------------------------------------------------------------




--------------------------------------------------------------------------------

An inode entry.

If the filename is longer than 48 characters:

the l_fname field in the directory entry holds a 48-character truncated version of the name
the l_lfn_block field points to an entry in .longfilenames
Extent blocks

Extent blocks are used for any file that has more than a single extent. The i_xblk field in the directory entry points to one of these extent blocks, which in turn defines where the second and subsequent extents are to be found.

An extent block is exactly one 512-byte disk block with the following form:


--------------------------------------------------------------------------------




--------------------------------------------------------------------------------

An extent block.

Each extent block contains:

forward/backward pointers
a count of extents
a count of all the blocks in all the extents defined by this extent block
pointers and block counts for each extent
a signature (IamXblk)
The first extent block also contains a redundant pointer to the first file extent (also described within the directory/inode entry). This lets you recover all data in the file by locating this block alone.

Files

Files or file extents are groupings of blocks described by directory/inode entries; they have no structure imposed on them by the QNX 4 filesystem.

Most files in Neutrino have the following overall structure:


--------------------------------------------------------------------------------




--------------------------------------------------------------------------------

QNX 4 file structure.

File-maintenance utilities
If a crash occurs, you can use the following file-maintenance and recovery utilities:

fdisk
dinit
chkfsys
dcheck
zap
spatch
This section gives a brief description of these utilities; for more information, see the Utilities Reference.

fdisk
The fdisk utility creates and maintains the partition block on a hard disk. This block is compatible with other operating systems and may be maintained by other OS versions of fdisk (although ours has the advantage of recognizing QNX-specific information). If the partition loader is missing or damaged, fdisk can create it.


--------------------------------------------------------------------------------
We recommend that you keep a hard copy of the partition table information for every disk in your network.

--------------------------------------------------------------------------------

dinit
The dinit utility creates (but the QNX 4 filesystem maintains) the following:

loader block
root block
bitmap blocks
root directory
/.inodes file
/.longfilenames file
If something destroys the first few blocks of your filesystem, you can try to recover them by using the -r option to dinit and then running chkfsys. For more information, see dinit in the Utilities Reference.

chkfsys
The chkfsys utility is your principal filesystem-maintenance tool. This utility:

checks the directory structure of an entire disk partition, reports any inconsistencies, and fixes them, if possible
verifies overall disk block allocation
writes a new /.bitmap, upon your approval
The chkfsys utility assumes that the root block is valid. If the root block isn't valid, chkfsys complains and gives up -- you'll need to try restoring the root block with the dinit utility.

dcheck
The dcheck utility checks for bad blocks on a disk by attempting to read every block on the drive. When you specify the -m option, dcheck removes any bad blocks from the disk allocation bitmap (/.bitmap).

If it finds the file /.bad_blks, dcheck updates the bitmap and recreates the /.bad_blks file. You can run dcheck a few times to increase your chances of recognizing bad blocks and adding them to the /.bad_blks file.

zap
The zap utility lets root remove files or directories from the filesystem without returning the used blocks to the free list. You might do this, for example, if the directory entry is damaged, or if two files occupy the same space on the disk (an error).

Recovering a zapped file
If you zapped a file in error, it's sometimes possible to recover the zapped file using the zap utility with the -u option immediately after the deletion. You can recover a zapped file using zap under these conditions:

the directory entry for that (now deleted) file must not be reused
the disk blocks previously used by the file must not be reassigned to another file
spatch
You may sometimes find that files or directories have been completely lost due to disk corruption. If after running chkfsys, you know that certain key files or directories weren't recovered, then you might be able to use spatch to recover some or all of this data.

The spatch utility lets you browse the raw disk and patch minor problems. You can sometimes cure transient disk problems by reading and writing the failing block with spatch.


--------------------------------------------------------------------------------
Before using spatch, make sure you understand the details of a QNX 4 filesystem; see "QNX 4 disk structure" earlier in this chapter.

--------------------------------------------------------------------------------

Recovering disks and files

Using chkfsys
The chkfsys utility is your principal tool for checking and restoring a potentially damaged filesystem. It can identify and correct a host of minor problems as well as verify the integrity of the disk system as a whole.

Normally, chkfsys requires that the filesystem be idle and that no files be currently open on that device. You'll have to shut down any processes that have opened files or that may need to open files while chkfsys is running.

To run chkfsys on a mountpoint, type:

chkfsys mountpointThe utility scans the entire disk partition from the root down, building an internal copy of the bitmap and verifying the consistency of all files and directories it finds in the process.

When it has finished processing all files, chkfsys compares the internal bitmap to the bitmap on the disk. If they match, chkfsys is finished. If any discrepancies are found, chkfsys will -- upon your approval -- rewrite the bitmap with data consistent with the files it was able to find and verify.

In addition to verifying block allocation (bitmap), chkfsys attempts to fix any problems it finds during the scan. For example, chkfsys can:

"unbusy" files that were being written when a crash occurred
fix the file size in a directory entry to match the real data
When to run chkfsys
It's a good idea to run chkfsys as part of your regularly scheduled maintenance procedures -- this lets you verify that the data on your disk is intact. For example, you might consider running chkfsys on your network servers every time they boot. An automated check on the filesystem at boot time guarantees that chkfsys will attempt to fix any problems it finds during the scan. To automate this process, add chkfsys to the server's rc.local file (see Controlling How Neutrino Starts).

It's especially important to run chkfsys after a system crash, power outage, or unexpected system reboot so that you can identify whether any files have been damaged. The chkfsys utility checks the "clean" flag on the disk to determine whether the system was in a consistent state at the time.

The clean flag is stored on disk and is maintained by the system. The flag is turned off when the filesystem is mounted and is turned on when the filesystem is unmounted. When the clean flag is set, chkfsys assumes that the filesystem is intact. If chkfsys finds the clean flag off, it tries to fix the problem.

The chkfsys utility supports a -u option, which overrides a set clean flag and tells chkfsys to run unconditionally. You might want to override the clean flag when:

dcheck discovers bad blocks
you've intentionally deleted or zapped some files
you want to force a general sanity check
Using chkfsys on a live system
The chkfsys utility normally requires exclusive use of the filesystem to provide a comprehensive verification of the disk.


--------------------------------------------------------------------------------
There is some risk in running chkfsys on a live system -- both chkfsys and the filesystem are reading and possibly writing the same blocks on the disk.
If you do this, and chkfsys writes something, it sends a message to the filesystem to invalidate itself, and that makes the filesystem remount itself and go back to the disk to reread all data. This marks any open files as stale; you'll get an error of EIO whenever you read or write, unless you close and reopen the files. This can affect things such as your system log file.

Static changes, in place, on files or directories that the filesystem doesn't currently have opened will probably not cause problems.


--------------------------------------------------------------------------------

If you're running an application that can't afford downtime or you couldn't run chkfsys because files were open for updating, try to run chkfsys with the -f option:

chkfsys -f /dev/hd0t79This invokes a special read-only mode of chkfsys that can give you an idea of the overall sanity of your filesystem.

Recovering from a bad block in the middle of a file

Hard disks occasionally develop bad blocks as they age. In some cases, you might be able to recover most or even all the data in a file containing a bad block.

Some bad blocks are the result of power failures or of weak media on the hard disk. In these cases, sometimes simply reading then rewriting a block will "restore" the block for a short period of time. This may allow you to copy the entire file somewhere else before the block goes bad again. This procedure certainly can't hurt, and is often worth a try.

To examine the blocks within a file, use the spatch utility. When you get to a bad block, spatch should report an error, but it may have actually read a portion of "good" bytes from that block. Writing that same block back will often succeed.

At the same time, spatch will rewrite a correct CRC (Cyclic Redundancy Check) that will make the block good again (but with possibly incorrect data).

You can then copy the entire file somewhere else, and then zap the previously damaged file. To complete the procedure, you mark the marginal block as bad (by adding it to the /.bad_blks file), then run chkfsys to recover the remaining good blocks.

If this procedure fails, you can use the spatch utility to copy as much of the file as possible to another file, and then zap the bad file and run chkfsys.

What to do if your system will no longer boot

If a previously working Neutrino system suddenly stops working and will no longer boot, then one of the following may have occurred:

the hardware has failed or the data on the hard disk has been damaged
someone has either changed/overwritten the boot file or changed the system initialization file -- these are the two most common scenarios
The following steps can help you identify the problem. Where possible, corrective actions are suggested.

1.Try booting from CD or across the network.
If you have a network to boot over, try booting your machine over the network. Once the machine is booted, you'll need to log in as root.
If you don't have a network, boot from your installation CD. The filesystem will already be running in this case, and you'll be logged in as root.
2.Start the hard disk driver. For example, to start a driver for an Adaptec series 4 SCSI adapter, type:
devb-aha4 options &If you're using another type of driver, enter its name instead. For example:

devb-eide options qnx4 options &This should create a block special file called /dev/hd0 that represents the entire hard disk.

3.Run fdisk.
Running the fdisk utility will immediately give you useful information about the state of your hard disk.

The fdisk utility might report one of several types of problems:

Problem: Probable cause: Remedy:
Error reading block 1 Either the disk controller or the hard disk itself has failed. If the disk is good, replacing the controller card might let you continue using the disk. Otherwise, you'll have to replace the hard drive, reinstall Neutrino, and restore your files from backup.
Wrong disk parameters Your hardware has probably "lost" its information about this hard drive -- likely because the battery for the CMOS memory is running low. Rerunning the hardware setup procedure (or the programmable option select procedure on a PS/2) will normally clear this up. Of course, replacing the battery will make this a more permanent fix.
Bad partition information If the disk size is reported correctly by fdisk, but the partition information is wrong, then the data in block 1 of the physical disk has somehow been damaged. Use fdisk to recreate the correct partition information. It's a good idea to write down or print out a hard copy of the correct partition information in case you ever have to do this step.

4.Mount the partition and the filesystem.
At this point, you have verified that the hardware is working (at least for block 1) and that a valid partition is defined for Neutrino. You now need to create a block special file for the QNX 4 partition itself and to mount the block special file as a QNX 4 filesystem:

mount -e /dev/hd0
mount /dev/hd0t79 /hd This should create a volume called /dev/hd0t79. Depending on the state of the QNX 4 partition, the mount may or may not fail. If the partition information is correct, there shouldn't be any problem. Since the root (/) already exists (on a CD or on a remote disk on the network), we've mounted the local hard disk partition as a filesystem with the name /hd.

Your goal now would be to run the chkfsys utility on the disk to examine -- and possibly fix -- the filesystem.


--------------------------------------------------------------------------------
If you booted from CD and you don't suspect there's any damage to the filesystem on your hard disk (e.g. the system was unable to boot because of a simple error introduced in the boot file or system initialization file), you can see up a symbolic link to your hard disk partition in the process manager's in-memory prefix tree:
ln -sP /hd /If you run this command, you can skip the rest of this section.


--------------------------------------------------------------------------------

If the mount fails...
If the mount fails, the first portion of the QNX 4 partition is probably damaged (since the driver will refuse to mount what it considers to be a corrupted filesystem).

In this case, you can use the dinit utility to overlay enough good information onto the disk to satisfy the driver:

dinit -hr /dev/hd0t79The -r option tells dinit to rewrite:

the root block
the bitmap (with all blocks allocated)
the constant portions of the root directory
You should now be able to reissue the mount command and once again try to create a mountpoint for a QNX 4 filesystem called /hd.

After doing this, you'll need to rebuild the bitmap with chkfsys, even on a good partition.

At least a portion of your QNX 4 filesystem should now be accessible. You can use chkfsys to examine the filesystem and recover as much data as possible.

If the hard disk is mounted as /hd (e.g. the machine boots from CD), enter:

path_on_CD/chkfsys /hdIf the hard disk is mounted as / (e.g. a network boot), enter:

network_path/chkfsys /In either case:

If possible, you should run chkfsys from somewhere other than the filesystem that you're trying to recover.
Make note of any problems reported and allow chkfsys to fix as much as it can.
What you do next depends on the result of running chkfsys.

If the disk is unrecoverable
If, for any reason, your disk is completely unrecoverable, you might be able to use spatch (see above) to patch your files and directories. In some cases, you may need to reinstall Neutrino and restore your disk from your backup files.

If significant portions of the filesystem are irreparably damaged, or important files are lost, then restoring from backup might be your best alternative.

If the filesystem is intact
If your filesystem is intact, yet the machine still refuses to boot from hard disk, then either of the following is probably damaged:

the partition loader program in physical block 1
the Neutrino loader in the first block of the QNX 4 partition

To rewrite a partition loader, use fdisk:
fdisk /dev/hd0 loader

To rewrite the QNX loader, use dinit:
dinit -b /dev/hd0t79

You should now be able to boot your system.

[oilcrankinject]

I hope someone can use this info here. I am not too good with stuff like this.

[m_thompson]

Too bad we can't connect a USB keyboard and get a QNX shell on the nav screen. Then you could do a backup to a external USB disk.

[starboard]

At the end of the CIC info pdf, there are instructions for how to reset the CIC.

Are there consequences from resetting the CIC? Like lost data or lost settings, the end of life as we know it? What will happen?
I was able to get music into my system via bluetooth/pandora when I first bought the car but now it won't. Would love to get that back. 2011 E93 with CIC and premium audio system.