Generated by Consona Page 1/13

ID: 76560 : LightSpeed 3.X (Ultra, Plus, QXi) - Octane : Root Partition is almost full ( 98%)
: Follow resolution steps
Issue

Root Partition is almost full ( 98%) - customer is unaware of this condition and store log does not help.

Details:
VCT Root Partition is almost full ( 98%) -Customer is unaware of this condition and store log does not help. Once the Root partion
is full the System will reports file system is full to the customer.

[root@qehct1]# df -k

Filesystem 1K-blocks Used Available Use% Mounted on

/dev/sdb2 4182720 3982208 200512 96% /
/dev/sdb1 101086 4798 91069 6% /boot
none 1944112 0 1944112 0% /dev/shm
/dev/sdb9 9765248 272 9764976 1% /usr/interchange
/dev/sdb10 11717120 792 11716328 1% /data
/dev/sdb11 37670048 9633924 28036124 26% /usr/g
/dev/md0 143363584 100004448 43359136 70% /usr/g/sdc_image_pool

Troubleshooting

Disk partition being too full : Troubleshooting

Details:
Disk partition being too full

NOTE: The disk space examples in this solution are taken from several system types. The partition sizes and disk configurations may not
match the system you are working on.

ct01% df -k
Filesystem Type kbytes use avail %use Mounted on
/dev/root xfs 93352 25520 67832 28 /
/dev/dsk/dks0d1s6 xfs 3842144 2544252 1297892 67 /usr
/dev/dsk/dks0d1s7 xfs 3394208 2671724 922484 93 /usr/g <- Problem
/dev/dsk/dks0d2s0 xfs 8884320 8764692 119628 99 /usr/g/sdc_image_pool2 <-Remove exams
/dev/dsk/dks0d1s5 xfs 2070624 1949052 121572 95 /usr/g/sdc_image_pool

Example: 1
su - root
password: #bigguy
cd /usr/g/service/log
ls -al (and look for crashdumps, observe approx. 8.7 meg)
drwxr-xr-x 2 root sys 8756729May 6 20:19 crashdumps <------- Problem
cd /usr/g/service/log/crashdumps
drwxr-xr-x 2 root sys 129May 6 20:19 crashdumps/ <---------normal

Example: 2
ct01 1% su - root
password: #bigguy
ct01 1# cd /usr/g/service/log
ct01# ls -al | more
total 32
drwxrwxrwx 3 ctuser ctuser 24 Mar 5 12:07 ./
drwxrwxrwx 6 ctuser ctuser 12288 May 13 01:02 ../
drwxrwxrwx 12 ctuser ctuser 22134096 May 13 16:25 Resume/ <---- 22.1 meg
....many more files will display.......please ignore unless 10meg or greater
Isolated and found MANY files under /usr/g/service/log/Recon/Resume more than 10MB.
cd /usr/g/service/log/Recon/Resume
ls -al
/usr/g/service/log/Recon/Resume/Thu_Mar_13_16_12_28_EST_2003/sdc_trace-1-1
/usr/g/service/log/Recon/Resume/Thu_Mar_13_16_12_28_EST_2003/sdc_trace-1-5
/usr/g/service/log/Recon/Resume/Fri_Mar_14_12_06_30_EST_2003/sdc_trace-0-1
/usr/g/service/log/Recon/Resume/Fri_Mar_14_12_06_30_EST_2003/sdc_trace-0-5

© Consona
Generated by Consona Page 2/13
EXAMPLE of what a "normal" RESUME should look like
ct92 1# pwd
ct01% cd /usr/g/service/log/Recon/Resume
ct01% ls -al | more
total 32
drwxrwxrwx 3 ctuser ctuser 24 Mar 5 12:07 ./
drwxrwxrwx 6 ctuser ctuser 12288 May 13 01:02 ../

Example: 3
login as root
cd /var/adm
ls -al SYS* You may find SYSLOG over a Meg

Example: 4
If you find /usr/g at or close to 100% (e.g. 93%) there are probably core files on the
system. Perform the following and reboot:
ct01% cd /usr/g/service/log
ct01% ls -al | more
total 344736
drwxrwxrwx 6 ctuser ctuser 12288 May 13 01:02 ./
drwxrwxr-x 14 ctuser informix 4096 Mar 5 10:11 ../
-rw-rw-rw- 1 root ctuser 1164 May 13 07:01 .currentBoards
drwxrwxr-x 6 ctuser ctuser 4096 May 7 10:01 AfRecoveryLogs/
-rw-rw-rw- 1 root sys 11 May 13 01:03 Ascrub_time
-rw-rw-rw- 1 ctuser ctuser 8872 May 13 17:12 Das.stats
-rw-rw-rw- 1 ctuser ctuser 6632 May 13 17:12 GantryRev.stats
-rw-rw-rw- 1 ctuser ctuser 37312 May 13 17:12 Gcan.stats
-rw-rw-rw- 1 ctuser ctuser 1432 May 13 17:12 Hcan.stats
-rw-rw-rw- 1 ctuser ctuser 2992 May 13 17:12 MotorCurrent.stats
-rw-rw-rw- 1 ctuser ctuser 33855144 Mar 27 16:26 core..netscape.27Mar16:26 <-------- 33.8 Mb
-rw-rw-rw- 1 ctuser ctuser 3373656 May 7 09:52 core.afQueueMgr.07May09:52 <------- 33.8 Mb
-rw-rw-rw- 1 ctuser ctuser 27712 May 13 17:12 RcomScom.stats
drwxrwxrwx 3 ctuser ctuser 24 Mar 5 12:07 Recon/

Example: 5
Look for core files in /usr/g/insite/ProDiags/bin use same procedure as noted above .

Example: 6
Start to further isolate for LARGE files on the CPU (OC or SBC if QXi w/O2 or CTi ) with the issue.
cd to the partition with the problem:

Note and Caution: What you are looking for most of the time are core files or large log files. Most of the
time if the date for the file is the same as the last software load, that is not the problem file. You can always read a log file with a less or
more command. With the exception of core files, if you can’t read the file leave it alone.

root> cd /
or
root> cd /usr/g
Now start a search for files that were created today or when the problem started and are fairly large.
SGI OC:root> ls -alR | sort +4 -n -r | grep "today's date" | more
e. g.: ls -alR | sort +4 -n -r | grep "Sep 13" | more
SBC: ONLY ( if QXi -w/O2 or CTi ) root> ls -alR | sort +3 -n -r | grep "today's date" | more
e. g.: ls -alR | sort +3 -n -r | grep "Sep 13" | more
Take a close look at the first few files that are displayed. These are the largest in your partition that were used or created when
you started getting this problem.
NOTE: Many times the problem may have occurred over a long period of time and performing the sort as shown above will often
miss the whole problem by limiting the search. You may have to expand your search if you do not find any large files created
today. Use the following commands to do a search for large files that is not date constrained:
SGI OC:root> ls -alR | sort +4 -n -r | more
e. g.: ls -alR | sort +4 -n -r | more
df -k
SBC: ONLY ( if QXi -w/O2 or CTi )
root> ls -alR | sort +3 -n -r | more
e. g.: ls -alR | sort +3 -n -r | more
Troubleshooting: Look for following file size check greater than 10MB throughout system and perform following below:
ct92 1# su - root
ct92 2# #bigguy

© Consona
Generated by Consona Page 3/13
ct92 3# find / -size +10000000c -print

Example: 7
For this problem : If QXi 1.x ( with sbc )
rsh sbc <enter>
cd /usr/g/service/log
ls -al prep*
note the size of file prep0_event_table.log
This file can be very large, in this example, 470 Mbyte
Example:
-rw-rw-rw- 1 ctuser ctuser 470367895Jul 30 11:36:15 prep0_event_table.log

The software never prunes this file so over time it can get huge.

Example: 8
OPTIONAL ( usually for QXi or CTi Only )

Found a 42 Mbyte root file in /usr/var/mail ( May be worth checking for this on LSPlus, LSUltra, LS16 )cd /usr/var/mail

ct01 13# ls -al

total 21784
drwxrwxr-x 3 root mail 52 Feb 7 14:30 .
drwxr-xr-x 23 root sys 4096 Apr 11 2001 ..
drwxrwxr-x 2 root mail 9 Apr 11 2001 :saved
-rw-rw---- 1 insite mail 582 Aug 16 14:19 insite
-rw-rw---- 1 root mail 11135942 Feb 7 14:30 root <=== On the system with the problem this file was 42 Meg

Example: 9
Look for /usr/var/cron/log

This file grows slowly over time and generally only causes a problem on scanners that have not had a LFC in several years.

Example: 10
Hung up images in the /usr/g/ctuser/film directory, and or the /usr/g/ctuser/film/AutoFilmComposer directory can cause the system
not to go into applications
{ctuser@wct1}[27] cd /usr/g/ctuser/film
{ctuser@wct1}[28]ls -al
total 77640
drwxrwxrwx 3 ctuser informix 4096 Sep 26 14:00 ./
drwxrwxr-x 20 ctuser informix 4096 Sep 26 12:21 ../
-rw-rw-rw- 1 ctuser ctuser 3 Sep 24 22:58 .mdappQueue
-rw-rw-rw- 1 ctuser ctuser 45 Sep 25 15:14 .saveState
-rw-rw-rw- 1 ctuser ctuser 68 Sep 13 13:55 9410_1.devinfo
drwxrwxrwx 2 ctuser informix 4096 Sep 26 13:40 AutoFilmComposer/
-rw-rw-rw- 1 ctuser ctuser 68 Sep 26 13:49 Konica.devinfo
-rw-r--r-- 1 root sys 3 Sep 21 19:48 LcConfigFile
-rwxrwxrwx 1 ctuser ctuser 819200 Sep 26 13:40 PRS.savestate*
-rw-rw-rw- 1 ctuser ctuser 68 Sep 25 14:15 camera.devinfo
-rwxrwxrwx 1 ctuser ctuser 5243768 Sep 21 18:21 img0a000U9*
-rwxrwxrwx 1 ctuser ctuser 5243768 Sep 21 18:22 img1a000U9*
-rwxrwxrwx 1 ctuser ctuser 2097656 Sep 21 18:41 img2a000U9*
-rwxrwxrwx 1 ctuser ctuser 5243768 Sep 21 18:58 img3a000U9*
-rwxrwxrwx 1 ctuser ctuser 5243768 Sep 21 19:00 img4a000U9*
-rwxrwxrwx 1 ctuser ctuser 5243768 Sep 21 19:02 img5a000U9*
-rwxrwxrwx 1 ctuser ctuser 5243768 Sep 21 19:02 img6a000U9*
-rwxrwxrwx 1 ctuser ctuser 5243768 Sep 21 19:02 img7a000U9*
-rw-rw-rw- 1 ctuser informix 38 Sep 26 14:00 lcam_spool_status
Notice the date of these img* files (they are not from today)

Do the same to look for hung images out of /usr/g/ctuser/film/AutoFilmComposer directory

{ctuser@wct1}[34] cd /usr/g/ctuser/film/AutoFilmComposer
{ctuser@wct1}[35]ls -al
total 592192
drwxrwxrwx 2 ctuser informix 4096 Sep 26 13:40 ./
drwxrwxrwx 3 ctuser informix 4096 Sep 26 14:00 ../
-rw-rw-rw- 1 ctuser ctuser 45 Sep 26 13:39 .saveState
-rw-rw-rw- 1 ctuser ctuser 68 Feb 1 2006 9410_1.devinfo
-rw-rw-rw- 1 ctuser ctuser 282 Sep 26 13:40 FCIdata20

© Consona
Generated by Consona Page 4/13
-rw-rw-rw- 1 ctuser ctuser 282 Sep 26 13:40 FCIdata21
-rw-rw-rw- 1 ctuser ctuser 282 Sep 26 13:40 FCIdata22
-rw-rw-rw- 1 ctuser ctuser 282 Sep 26 13:40 FCIdata23
-rw-rw-rw- 1 ctuser ctuser 282 Sep 26 13:40 FCIdata24
-rw-rw-rw- 1 ctuser ctuser 282 Sep 26 13:40 FCIdata25
-rw-rw-rw- 1 ctuser ctuser 282 Sep 26 13:40 FCIdata26
-rw-rw-rw- 1 ctuser ctuser 282 Sep 26 13:40 FCIdata27
-rw-rw-rw- 1 ctuser ctuser 296 Sep 26 13:40 FCIdata28
-rw-rw-rw- 1 ctuser ctuser 262144 Sep 26 13:40 FCImage20
-rw-rw-rw- 1 ctuser ctuser 262144 Sep 26 13:40 FCImage21
-rw-rw-rw- 1 ctuser ctuser 262144 Sep 26 13:40 FCImage22
-rw-rw-rw- 1 ctuser ctuser 262144 Sep 26 13:40 FCImage23
-rw-rw-rw- 1 ctuser ctuser 262144 Sep 26 13:40 FCImage24
-rw-rw-rw- 1 ctuser ctuser 262144 Sep 26 13:40 FCImage25
-rw-rw-rw- 1 ctuser ctuser 262144 Sep 26 13:40 FCImage26
-rw-rw-rw- 1 ctuser ctuser 262144 Sep 26 13:40 FCImage27
-rw-rw-rw- 1 ctuser ctuser 262144 Sep 26 13:40 FCImage28
-rw-rw-rw- 1 ctuser ctuser 68 Sep 26 13:12 Konica.devinfo
-rw-rw-rw- 1 ctuser ctuser 68 Sep 26 13:39 camera.devinfo
-rwxrwxrwx 1 ctuser ctuser 10486648 Sep 21 18:46 img0a000TT*
-rwxrwxrwx 1 ctuser ctuser 5243768 Jul 12 08:51 img0a000UQ*
-rwxrwxrwx 1 ctuser ctuser 5243768 Aug 9 05:55 img0a000Zr*
-rwxrwxrwx 1 ctuser ctuser 1572864 Jun 22 16:03 img0a000bX*
many more lines of images/films can be found here
Notice the dates of these img* files (they are not from today)

Example: 11
Problem is the sbc /usr/g/data_management/recovery partition is at 100%. Related FRU items are the O2 computer, Scandata
disk and VME power supply.
This problem is usually created by a power hit or power cycle of the console during data aquisition.
The command storelog will attempt to run automatically. It is supposed to remove these files but fails.
storelog will run but will not remove the contents of this directory due to a coding oversite in the purgeFileList.SBC file.

Some products have an SBC, most do not. This starts by going to the SBC, but you can skip that step if you do not have an SBC.

ctls% rsh sbc

{insite@mcls_sbc}[1] df
Filesystem Type blocks use avail %use Mounted on
/dev/root xfs 4346904 1073735 3273169 25 /
/dev/xlv/raw_data xfs 81920 688 81232 1 /raw_data
/dev/dsk/dks0d1s7 xfs 1679552 453728 1225824 28 /usr/g
/dev/dsk/dks0d1s3 xfs 2214080 2210576 3504 100 /usr/g/data_management
{insite@mcls_sbc}[2] cd /usr/g/data_*
{insite@mcls_sbc}[3] ls -l
total 376
drwxrwxr-x 2 root ctuser 39 Sep 21 01:06 ex19.BAYE.896698921.121068/
drwxrwxr-x 2 root ctuser 4096 Sep 21 01:14 ex245.MCLS.937876357.645977/
drwxrwxr-x 2 root ctuser 53 Sep 21 04:08 ex246.MCLS.937886877.742128/
drwxrwxr-x 2 root ctuser 53 Sep 21 04:12 ex247.MCLS.937887143.386172/
More output; Each directory is a different exam number
-rw-rw-r-- 1 root ctuser 0 May 7 09:01 info_file
drwxr-xr-x 2 ctuser ctuser 94208Sep 21 01:05 recovery/ {Note the size of this directory}
-rw-rw-r-- 1 root ctuser 0 Sep 22 08:47 sfm.shutdown.indicator

{insite@mcls_sbc}[5] cd recovery

{insite@mcls_sbc}[7] ls -l

total 1545000
-rw-rw-r-- 1 root ctuser 511992 Aug 17 22:18 936095364.552587.s5a1
-rw-rw-r-- 1 root ctuser 511992 Aug 20 10:26 936095364.587808.s1a1
-rw-rw-r-- 1 root ctuser 511992 Aug 20 10:26 936095364.635820.s1a2
much more output Note 0.5 meg per file
-rw-rw-r-- 1 root ctuser 511992 Sep 20 10:02 937875905.69205.s5a19
-rw-rw-r-- 1 root ctuser 511992 Sep 20 10:01 937875905.7400.s5a16
-rw-rw-r-- 1 root ctuser 511992 Sep 20 10:02 937875905.96559.s5a20

Example: 12
Check the IOS logs and prune the log file that is the problem.
cd /usr/g/ctuser/logfiles
ls -al

© Consona
Generated by Consona Page 5/13
drwxrwxr-x 2 ctuser informix 4096 Jan 16 07:49 ./
drwxrwxr-x 31 ctuser users 4096 May 11 18:26 ../
-rw-rw-rw- 1 ctuser users 8063 May 7 09:28 anonlog
-rw-rw-rw- 1 ctuser users2147483647May 11 18:26 arslog <-- The Problem
-rw-rw-rw- 1 ctuser users 2690554 May 11 18:40 browserlog
-rw-rw-rw- 1 ctuser users 5113409 May 11 18:26 dbrlog
-rw-rw-rw- 1 ctuser users 99877 May 11 18:26 dbwlog
-rw-rw-r-- 1 ctuser users 39270 May 11 11:09 dclimg
-rw-rw-rw- 1 ctuser users 9483 May 11 16:49 dcplog
-rw-rw-rw- 1 ctuser users 8288397 May 11 18:40 dcslog
-rw-rw-rw- 1 ctuser users 1650 Apr 7 13:59 epdlog
-rw-rw-rw- 1 ctuser users 244117 May 11 18:27 fclog
-rw-rw-rw- 1 ctuser users 81388 May 11 16:19 importimagelog
-rw-rw-rw- 1 ctuser users 1162766 May 11 18:27 imslog
-rw-r--r-- 1 informix informix 432 Jan 7 20:55 inst_startlog
-rw-rw-rw- 1 ctuser users 232190 May 11 18:27 netlog
-rw-rw-rw- 1 ctuser users 127342 May 11 18:26 ppslog
-rw-rw-rw- 1 ctuser users 11707393 May 11 18:27 prslog
-rw-rw-rw- 1 ctuser users 115398 May 11 18:27 sdclog
-rw-rw-rw- 1 ctuser users 626197 May 11 18:27 testclientlog

Example: 14
The /root directory is 99% full and all other directories look normal. When you use any of the standard search techniques for large files none
can be found. Root cause - intermittently when the logwatch cronjob task runs (daily at 0402 AM), it saves a copies of files from /var/log
which in turn fills up the /var/cache/logwatch directory. Search PSDB for logwatch to find resolution.

Note on storelog it should be run as a last resort. If the site is having trouble, valuable troubleshooting information can be lost,
understanding that at times it may be the only recourse FINAL SUMMARY: After completion and executionof ALL possible Examples :
( All stated percentages are approximate )( See df -k to see disk capacity after any or all Examples completed. If all else does not recover
system to boot or exhibits disk space insufficient error: * Perform complete APPS LFC to correct ( last resort ) , perform LFC

Resolution

Check and remove problem files to open disk space - pcra

Details:

Here are a list of Resolutions to follow to check and remove problem files to correct disk space issues and the disk full error on boot up.

It is the Service person's responsibility to use the appropriate documentation when performing and verifying service.
Refer to DOC0994473 - PCRN61578 for removing problem files, which can be found online in My-Workshop.
Links to any needed documentation is found in the Product concepts as an attachment called "ProductDocumentLinks"

NOTE: The disk space examples in this solution are taken from several system types. The partition sizes and disk configurations may not
match the system you are working on.

ct01% df -k
Filesystem Type kbytes use avail %use Mounted on
/dev/root xfs 93352 25520 67832 28 /
/dev/dsk/dks0d1s6 xfs 3842144 2544252 1297892 67 /usr
/dev/dsk/dks0d1s7 xfs 3394208 2671724 922484 93 /usr/g <- Problem
/dev/dsk/dks0d2s0 xfs 8884320 8764692 119628 99 /usr/g/sdc_image_pool2 <-Remove exams
/dev/dsk/dks0d1s5 xfs 2070624 1949052 121572 95 /usr/g/sdc_image_pool

Resolution: 1
su - root
password: #bigguy
cd /usr/g/service/log
ls -al (and look for crashdumps, observe approx. 8.7 meg)
drwxr-xr-x 2 root sys 8756729 May 6 20:19 crashdumps
cd /usr/g/service/log/crashdumps
rm * > make sure you are in crashdumps directory <
df > this took me from 93% usr/g to 65% usr/g <
drwxr-xr-x 2 root sys 129 May 6 20:19 crashdumps/ <---------normal

Resolution: 2
© Consona
Generated by Consona Page 6/13
ct01 1% su - root
password: #bigguy
ct01 1# cd /usr/g/service/log
ct01# ls -al | more
total 32
drwxrwxrwx 3 ctuser ctuser 24 Mar 5 12:07 ./
drwxrwxrwx 6 ctuser ctuser 12288 May 13 01:02 ../
drwxrwxrwx 12 ctuser ctuser 22134096 May 13 16:25 Resume/ <---- 22.1 meg
....many more files will display.......please ignore unless 10meg or greater
Isolated and found MANY files under /usr/g/service/log/Recon/Resume more than 10MB.
cd /usr/g/service/log/Recon/Resume
ls -al
/usr/g/service/log/Recon/Resume/Thu_Mar_13_16_12_28_EST_2003/sdc_trace-1-1
/usr/g/service/log/Recon/Resume/Thu_Mar_13_16_12_28_EST_2003/sdc_trace-1-5
/usr/g/service/log/Recon/Resume/Fri_Mar_14_12_06_30_EST_2003/sdc_trace-0-1
/usr/g/service/log/Recon/Resume/Fri_Mar_14_12_06_30_EST_2003/sdc_trace-0-5
Remove the recon resume files as follows:
as root
ct92 5# cd /usr/g/service/log/Recon/Resume
ct92 6# pwd
/usr/g/service/log/Recon/Resume <======Verify you are in right Directory path
ct92 7# ls -al
drwxrwxrwx 2 ctuser ctuser 4096 Mar 20 15:24 Fri_Mar_14_12_06_30_EST_2003
drwxrwxrwx 2 ctuser ctuser 4096 Mar 20 15:42 Thu_Mar_13_16_12_28_EST_2003
drwxrwxrwx 2 ctuser ctuser 4096 Mar 20 12:09 Thu_Mar_20_12_09_23_EST_2003
drwxrwxrwx 2 ctuser ctuser 4096 Mar 20 15:44 Tue_Mar_18_09_31_02_EST_2003
***Caution **** The Remove command is very powerful. The -r switch (recursive) will allow the removal of a directory and all the
contents of the directory. The filename can be wild carded (*) to only remove directories from a certain date. For example
"Tue_Mar_18*" will only remove directories created March 18th. It is recommend you remove the oldest files first and leave the
latest unless you know for sure no one is troubleshooting recon problems. By using the -i switch (interactive), the system will ask
the operator for confirmation before removing the files.
ct92 8# rm -r -i Tue*
ct92 9# rm –r –i Fri*
Continue to remove each day of the week until all are removed.
ANOTHER EXAMPLE of what a "normal" RESUME should look like after rm command is used
ct92 1# pwd
ct01% cd /usr/g/service/log/Recon/Resume
ct01% ls -al | more
total 32
drwxrwxrwx 3 ctuser ctuser 24 Mar 5 12:07 ./
drwxrwxrwx 6 ctuser ctuser 12288 May 13 01:02 ../

Resolution: 3
login as root
cd /var/adm
ls -al SYS* You may find SYSLOG over a Meg
If over a Meg
echo > SYSLOG ( This will empty the file without have to remove it. )
or
rm SYSLOG
touch SYSLOG
chmod 644 SYSLOG
ct01% ls -al SYS*
-rw-r--r-- 1 root sys 19462 May 13 17:53 SYSLOG
-rw-r--r-- 1 root sys 7639 May 12 14:42 SYSLOG.0
-rw-r--r-- 1 root sys 6149 May 11 07:22 SYSLOG.1
-rw-r--r-- 1 root sys 7207 May 11 00:00 SYSLOG.2
-rw-r--r-- 1 root sys 6955 May 9 14:38 SYSLOG.3
-rw-r--r-- 1 root sys 7489 May 8 13:28 SYSLOG.4
-rw-r--r-- 1 root sys 9244 May 7 12:27 SYSLOG.5
-rw-r--r-- 1 root sys 21429 May 7 00:00 SYSLOG.6
-rw-r--r-- 1 root sys 7782 May 5 22:20 SYSLOG.7

Resolution: 4
If you find /usr/g at or close to 100% (e.g. 93%) there are probably core files on the
system. Perform the following and reboot:
ct01% cd /usr/g/service/log
ct01% ls -al | more
total 344736
drwxrwxrwx 6 ctuser ctuser 12288 May 13 01:02 ./
drwxrwxr-x 14 ctuser informix 4096 Mar 5 10:11 ../
-rw-rw-rw- 1 root ctuser 1164 May 13 07:01 .currentBoards

© Consona
Generated by Consona Page 7/13
drwxrwxr-x 6 ctuser ctuser 4096 May 7 10:01 AfRecoveryLogs/
-rw-rw-rw- 1 root sys 11 May 13 01:03 Ascrub_time
-rw-rw-rw- 1 ctuser ctuser 8872 May 13 17:12 Das.stats
-rw-rw-rw- 1 ctuser ctuser 6632 May 13 17:12 GantryRev.stats
-rw-rw-rw- 1 ctuser ctuser 37312 May 13 17:12 Gcan.stats
-rw-rw-rw- 1 ctuser ctuser 1432 May 13 17:12 Hcan.stats
-rw-rw-rw- 1 ctuser ctuser 2992 May 13 17:12 MotorCurrent.stats
-rw-rw-rw- 1 ctuser ctuser 33855144 Mar 27 16:26 core..netscape.27Mar16:26 <-------- 33.8 meg
-rw-rw-rw- 1 ctuser ctuser 3373656 May 7 09:52 core.afQueueMgr.07May09:52 <------- 33.8 meg
-rw-rw-rw- 1 ctuser ctuser 27712 May 13 17:12 RcomScom.stats
drwxrwxrwx 3 ctuser ctuser 24 Mar 5 12:07 Recon/
pwd
/usr/g/service/log
rm core*

Resolution: 5
Remove core files from /usr/g/insite/ProDiags/bin use same procedure as noted above .
/usr/g disk space went from 93% to 70% after removal
This was 33.8 Meg of core files

Resolution: 6
Note and Caution: What you are looking for most of the time are core files or large log files. Most of the time
if the date for the file is the same as the last software load, that is not the problem file. You can always read a log file with a less or more
command. With the exception of core files, if you can’t read the file leave it alone.

Start to further isolate for LARGE files on the CPU (OC or SBC if QXi w/O2 or CTi ) with the issue.
cd to the partition with the problem:
root> cd /
or
root> cd /usr/g
Now start a search for files that were created today or when the problem started and are fairly large.
SGI OC:root> ls -alR | sort +4 -n -r | grep "today's date" | more
e. g.: ls -alR | sort +4 -n -r | grep "Sep 13" | more
SBC: ONLY ( if QXi -w/O2 or CTi ) root> ls -alR | sort +3 -n -r | grep "today's date" | more
e. g.: ls -alR | sort +3 -n -r | grep "Sep 13" | more
Take a close look at the first few files that are displayed. These are the largest in your partition that were used or created when
you started getting this problem.
NOTE: Many times the problem may have occurred over a long period of time and performing the sort as shown above will often
miss the whole problem by limiting the search. You may have to expand your search if you do not find any large files created
today. Use the following commands to do a search for large files that is not date constrained:
SGI OC:root> ls -alR | sort +4 -n -r | more
e. g.: ls -alR | sort +4 -n -r | more
df -k
SBC: ONLY ( if QXi -w/O2 or CTi )
root> ls -alR | sort +3 -n -r | more
e. g.: ls -alR | sort +3 -n -r | more
You can freely remove large core files. Caution Note: Core files are in the name format of "core.[a process name or
number]". They are usually of a size greater than a few megabyte. The system has many files that have the word "core"
in the name that are not core files. If it is in a library or a drivers folder, it is not a core file. Files that start with CT55_* are
the RATGOLD files. Deleting them will cause a Load From Cold. Large files that have been on the system since the last
software load are not the problem. The problem files are usually Core, TAR files or LOG files.
Linux software: Look for following file size check greater than 10MB throughout system and perform following below:
ct92 1# su - root
ct92 2# #bigguy
ct92 3# find / -size +10000000c -printorfind /usr/g -size +10000000c -print |more
Here are two examples of core files that are not in /usr/g/service/log

/usr/g/service/SHM/Listen/core.15022
/usr/g/ctuser/terra/core.26759

To remove the files first change directory to the folder the files are located in then use this command

rm -f [file name] (rm -f = remove with out asking)

Example: cd /usr/g/ctuser/terra; rm core.2*

Resolution: 7
For this problem : If QXi 1.x ( with sbc )
rsh sbc <enter>

© Consona
Generated by Consona Page 8/13
cd /usr/g/service/log
ls -al prep*
note the size of file prep0_event_table.log
This file can be very large, in this example, 470 Mbyte
Example:
-rw-rw-rw- 1 ctuser ctuser 470367895 Jul 30 11:36:15 prep0_event_table.log
su - root <enter>
password [ #bigguy ] <enter> <-----------------------------Change to root
cd /usr/g/service/log <---------------------------Change back to the directory where you found the large file
rm prep0_event_table.log <enter> <-------------------------- Remove the file.
^D or exit to close the connection to the SBC
Then reboot the system.

Resolution: 8
OPTIONAL ( usually for QXi or CTi Only )
Found a 42 Mbyte root file in /usr/var/mail ( May be worth checking for this on LSPlus, LSUltra, LS16 )

cd /usr/var/mail

ct01 13# ls -al

total 21784
drwxrwxr-x 3 root mail 52 Feb 7 14:30 .
drwxr-xr-x 23 root sys 4096 Apr 11 2001 ..
drwxrwxr-x 2 root mail 9 Apr 11 2001 :saved
-rw-rw---- 1 insite mail 582 Aug 16 14:19 insite
-rw-rw---- 1 root mail 11135942 Feb 7 14:30 root <=== On the system with the problem this file was 42 Meg
echo > root ( echo will empty the file without having to remove it )
or
rm root
touch root
chgrp mail root

Resolution: 9
It is also safe to remove
/usr/var/cron/log
This file grows slowly over time and generally only causes a problem on scanners that have not had a LFC in several years.
This solution was found on a CTi 4.x system but is safe to use on ANY unix/irix based system.

Resolution: 10
Hung up images in the /usr/g/ctuser/film directory, and or the /usr/g/ctuser/film/AutoFilmComposer directory can cause the system
not to go into applications
After removing these hung images the system was then able to be brought into applications.
{ctuser@wct1}[27] cd /usr/g/ctuser/film
{ctuser@wct1}[28] ls -al
total 77640
drwxrwxrwx 3 ctuser informix 4096 Sep 26 14:00 ./
drwxrwxr-x 20 ctuser informix 4096 Sep 26 12:21 ../
-rw-rw-rw- 1 ctuser ctuser 3 Sep 24 22:58 .mdappQueue
-rw-rw-rw- 1 ctuser ctuser 45 Sep 25 15:14 .saveState
-rw-rw-rw- 1 ctuser ctuser 68 Sep 13 13:55 9410_1.devinfo
drwxrwxrwx 2 ctuser informix 4096 Sep 26 13:40 AutoFilmComposer/
-rw-rw-rw- 1 ctuser ctuser 68 Sep 26 13:49 Konica.devinfo
-rw-r--r-- 1 root sys 3 Sep 21 19:48 LcConfigFile
-rwxrwxrwx 1 ctuser ctuser 819200 Sep 26 13:40 PRS.savestate*
-rw-rw-rw- 1 ctuser ctuser 68 Sep 25 14:15 camera.devinfo
-rwxrwxrwx 1 ctuser ctuser 5243768 Sep 21 18:21 img0a000U9*
-rwxrwxrwx 1 ctuser ctuser 5243768 Sep 21 18:22 img1a000U9*
-rwxrwxrwx 1 ctuser ctuser 2097656 Sep 21 18:41 img2a000U9*
-rwxrwxrwx 1 ctuser ctuser 5243768 Sep 21 18:58 img3a000U9*
-rwxrwxrwx 1 ctuser ctuser 5243768 Sep 21 19:00 img4a000U9*
-rwxrwxrwx 1 ctuser ctuser 5243768 Sep 21 19:02 img5a000U9*
-rwxrwxrwx 1 ctuser ctuser 5243768 Sep 21 19:02 img6a000U9*
-rwxrwxrwx 1 ctuser ctuser 5243768 Sep 21 19:02 img7a000U9*
-rw-rw-rw- 1 ctuser informix 38 Sep 26 14:00 lcam_spool_status
Notice the date of these img* files (they are not from today)
To remove these files type the following
{ctuser@wct1}[30] find . -name "img*" | xargs rm -rf
This command could take some time to complete, depending on the number of images removed. Have patience and wait until the
prompt returns.
Do the same to remove hung images out of /usr/g/ctuser/film/AutoFilmComposer directory
{ctuser@wct1}[34] cd /usr/g/ctuser/film/AutoFilmComposer

© Consona
Generated by Consona Page 9/13
{ctuser@wct1}[35] ls -al
total 592192
drwxrwxrwx 2 ctuser informix 4096 Sep 26 13:40 ./
drwxrwxrwx 3 ctuser informix 4096 Sep 26 14:00 ../
-rw-rw-rw- 1 ctuser ctuser 45 Sep 26 13:39 .saveState
-rw-rw-rw- 1 ctuser ctuser 68 Feb 1 2006 9410_1.devinfo
-rw-rw-rw- 1 ctuser ctuser 282 Sep 26 13:40 FCIdata20
-rw-rw-rw- 1 ctuser ctuser 282 Sep 26 13:40 FCIdata21
-rw-rw-rw- 1 ctuser ctuser 282 Sep 26 13:40 FCIdata22
-rw-rw-rw- 1 ctuser ctuser 282 Sep 26 13:40 FCIdata23
-rw-rw-rw- 1 ctuser ctuser 282 Sep 26 13:40 FCIdata24
-rw-rw-rw- 1 ctuser ctuser 282 Sep 26 13:40 FCIdata25
-rw-rw-rw- 1 ctuser ctuser 282 Sep 26 13:40 FCIdata26
-rw-rw-rw- 1 ctuser ctuser 282 Sep 26 13:40 FCIdata27
-rw-rw-rw- 1 ctuser ctuser 296 Sep 26 13:40 FCIdata28
-rw-rw-rw- 1 ctuser ctuser 262144 Sep 26 13:40 FCImage20
-rw-rw-rw- 1 ctuser ctuser 262144 Sep 26 13:40 FCImage21
-rw-rw-rw- 1 ctuser ctuser 262144 Sep 26 13:40 FCImage22
-rw-rw-rw- 1 ctuser ctuser 262144 Sep 26 13:40 FCImage23
-rw-rw-rw- 1 ctuser ctuser 262144 Sep 26 13:40 FCImage24
-rw-rw-rw- 1 ctuser ctuser 262144 Sep 26 13:40 FCImage25
-rw-rw-rw- 1 ctuser ctuser 262144 Sep 26 13:40 FCImage26
-rw-rw-rw- 1 ctuser ctuser 262144 Sep 26 13:40 FCImage27
-rw-rw-rw- 1 ctuser ctuser 262144 Sep 26 13:40 FCImage28
-rw-rw-rw- 1 ctuser ctuser 68 Sep 26 13:12 Konica.devinfo
-rw-rw-rw- 1 ctuser ctuser 68 Sep 26 13:39 camera.devinfo
-rwxrwxrwx 1 ctuser ctuser 10486648 Sep 21 18:46 img0a000TT*
-rwxrwxrwx 1 ctuser ctuser 5243768 Jul 12 08:51 img0a000UQ*
-rwxrwxrwx 1 ctuser ctuser 5243768 Aug 9 05:55 img0a000Zr*
-rwxrwxrwx 1 ctuser ctuser 1572864 Jun 22 16:03 img0a000bX*
many more lines of images/films can be found here
Notice the dates of these img* files (they are not from today)
{ctuser@wct1}[37] find . -name "img*" | xargs rm -rf
This command could take some time to complete, depending on the number of images removed. Have patience and wait until the
prompt returns.

Resolution: 11
If the product does not have an SBC, skip to the df command

ctls% rsh sbc

{insite@mcls_sbc}[1] df
Filesystem Type blocks use avail %use Mounted on
/dev/root xfs 4346904 1073735 3273169 25 /
/dev/xlv/raw_data xfs 81920 688 81232 1 /raw_data
/dev/dsk/dks0d1s7 xfs 1679552 453728 1225824 28 /usr/g
/dev/dsk/dks0d1s3 xfs 2214080 2210576 3504 100 /usr/g/data_management
{insite@mcls_sbc}[21] su -
Password:
mcls_sbc 1# pwd
mcls_sbc 2# cd /usr/g/data_management/recovery
mcls_sbc 3# pwd
/usr/g/data_management/recovery
mcls_sbc 4# rm *
Arguments too long If you get this message then you will have to remove the files in chunks. Example below will change
the 93x number to the exam numbers on your unit.
mcls_sbc 5# rm 936* <These 2 commands limit the command string length by using unique characters>
mcls_sbc 6# rm 937* <Use the ls command and use 3 or more unique characters as displayed on your system>
mcls_sbc 7# ls
mcls_sbc 8# pwd
/usr/g/data_management/recovery
mcls_sbc 9# ls -l
total 0
mcls_sbc 11# df -k
Filesystem Type kbytes use avail %use Mounted on
/dev/root xfs 2173452 536860 1636592 25 /
/dev/xlv/raw_data xfs 40960 344 40616 1 /raw_data
/dev/dsk/dks0d1s7 xfs 839776 226864 612912 28 /usr/g
/dev/dsk/dks0d1s3 xfs 1107040 332696 774344 31 /usr/g/data_management {Note the normal partition size}
mcls_sbc 12# pwd
/usr/g/data_management/recovery
mcls_sbc 13# cd ..
mcls_sbc 14# ls -l

© Consona
Generated by Consona Page 10/13
drwxrwxr-x 2 root ctuser 39 Sep 21 01:06 ex19.BAYE.896698921.121068
drwxrwxr-x 2 root ctuser 4096 Sep 21 01:14 ex245.MCLS.937876357.645977
Much more output
drwxrwxr-x 2 root ctuser 4096 Sep 22 10:15 ex276.MCLS.937995170.384866
drwxrw--- 2 root ctuser 4096 Sep 21 20:04 ex50301.MCLS.937943549.578719
drwx---- 2ctuser 4096 Sep 22 08:25 ex50304.MCLS.937987146.39535
-rw-rw-r-- 1 root ctuser 0 May 7 09:01 info_filedrwxr-xr-x 2 ctuser ctuser 9 Sep 22 10:49 recovery {note the size of a normal
empty directory}
-rw-rw-r-- 1 root ctuser 0 Sep 22 08:47 sfm.shutdown.indicator

Resolution: 12
Check the IOS logs and prune the log file that is the problem.
cd /usr/g/ctuser/logfiles
ls -al
drwxrwxr-x 2 ctuser informix 4096 Jan 16 07:49 ./
drwxrwxr-x 31 ctuser users 4096 May 11 18:26 ../
-rw-rw-rw- 1 ctuser users 8063 May 7 09:28 anonlog
-rw-rw-rw- 1 ctuser users 2147483647 May 11 18:26 arslog <-- The Problem
-rw-rw-rw- 1 ctuser users 2690554 May 11 18:40 browserlog
-rw-rw-rw- 1 ctuser users 5113409 May 11 18:26 dbrlog
-rw-rw-rw- 1 ctuser users 99877 May 11 18:26 dbwlog
-rw-rw-r-- 1 ctuser users 39270 May 11 11:09 dclimg
-rw-rw-rw- 1 ctuser users 9483 May 11 16:49 dcplog
-rw-rw-rw- 1 ctuser users 8288397 May 11 18:40 dcslog
-rw-rw-rw- 1 ctuser users 1650 Apr 7 13:59 epdlog
-rw-rw-rw- 1 ctuser users 244117 May 11 18:27 fclog
-rw-rw-rw- 1 ctuser users 81388 May 11 16:19 importimagelog
-rw-rw-rw- 1 ctuser users 1162766 May 11 18:27 imslog
-rw-r--r-- 1 informix informix 432 Jan 7 20:55 inst_startlog
-rw-rw-rw- 1 ctuser users 232190 May 11 18:27 netlog
-rw-rw-rw- 1 ctuser users 127342 May 11 18:26 ppslog
-rw-rw-rw- 1 ctuser users 11707393 May 11 18:27 prslog
-rw-rw-rw- 1 ctuser users 115398 May 11 18:27 sdclog
-rw-rw-rw- 1 ctuser users 626197 May 11 18:27 testclientlog
Any of the above IOS log files may be pruned as follows:
echo > arslog
The echo command will reset the log file to 0 and keep all permissions, owner & group.
Or a better comand to use so the last few weeks of information is not lost:
cd ~ctuser/logfiles;tail -n 900 arslog>ar;mv -f ar arslog;chmod 666 arslog;
This will create a file that has the last 900 lines from the old log, just in case someone needs it.
Just change arslog in the above commands to which ever log that needs to be trimed.
Other Examples:
cd ~ctuser/logfiles;tail -n 900 dcslog>dcs;mv -f dcs dcslog;chmod 666 dcslog;
cd ~ctuser/logfiles;ls -l; tail -n 900 prslog>prs;mv -f prs prslog;chmod 666 prslog;

Note on storelog it should be run as a last resort. If the site is having trouble, valuable troubleshooting information can be lost,
understanding that at times it may be the only recourse FINAL SUMMARY: After completion and executionof ALL possible Resolutions
: ( All stated percentages are approximate )( See df -k to see disk capacity after any or all resolutions completedIf all else does not recover
system to boot or exhibits disk space insufficient error: * Perform complete APPS LFC to correct ( last resort ) , perform LFC

Resolution: 13
login as root
su -
password
then
df
see which partition is fullest and cd to that file
e.g. :
opultra 1# df
Filesystem Type blocks use avail %use Mounted on
/dev/root xfs 183472 47622 135850 26 /
/dev/dsk/dks0d1s6 xfs 6244992 2057464 4187528 33 /usr
/dev/dsk/dks0d1s7 xfs 6220416 6037200 183216 98 /usr/g <= to full***
/dev/dsk/dks0d2s0 xfs 17767824 15264480 2503344 86 /usr/g/sdc_image_pool2
/dev/dsk/dks0d1s5 xfs 4139648 3731696 407952 91 /usr/g/sdc_image_pool <= customer controlled if not courpt.
then change to the over full directory
cd /usr/g
then
find . -size +10000000c -print

© Consona
Generated by Consona Page 11/13
see whcih files can be removed
EG:
cores that have dates in their name (lots of examples):
core..netscape.13Jun12:52
core..netscape.21Mar12:55
core.afViewer.200626Apr.211655
core.avViewer1.200613Apr.210555
core.avViewer1.200616May.155542
core.avViewer1.200623Mar.223421
core.ice.expect.08Feb16:22
core.ice.expect.08Mar16:19
core.ice.expect.11Aug16:27
core.ice.expect.11Oct16:21
core.ice.expect.15Nov16:09
core.ice.expect.17Jan16:33
core.ice.expect.17Mar16:12
core.ice.expect.21Nov16:20
core.ice.expect.22Feb16:15
core.ice.expect.26Jan16:39
core.ice.expect.28Mar16:27
core.ice.expect.31Jul16:40
core.of.08Feb10:57
core.of.14May15:31
core.of.19Feb08:33
core.of.21Jul13:31
core.of.23Oct09:48
or these files types of files:
/usr/g/bin/ProtocolErr.log
./service/tools/added_tools/IMG_GEN/BAYE_19_1_1_896698921_121068
./service/tools/added_tools/IMG_GEN/BAYE_19_7_1_896698921_121068
./service/tools/added_tools/IMG_GEN/B20A_414_5_1_990016355_545164
./service/tools/added_tools/IMG_GEN/CT55_209_2_1_1032537439_551470
./service/tools/added_tools/IMG_GEN/CT55_209_4_1_1032537439_551470
./service/tools/added_tools/IMG_GEN/CT55_209_5_1_1032537439_551470
./service/tools/added_tools/IMG_GEN/CT55_209_6_1_1032537439_551470
after doing
rm -rf filename
on the bad files do a
df
after each one to see which files get you to bellow 90% to start.
It is recommended that all these files be removed.

Resolution: 14:
Cause: On 07MW software
The / directory is 96% full or more. All other directories look normal. When you use any of the standard search techniques for
large files none can be found. Root cause - intermittently when the logwatch cronjob task runs (daily at 0402 AM), it saves a copie
of files from /var/log which in turn fills up /var/cache/logwatch
Solution:
Remove all the files in /var/cache/logwatch using the following commands logged in as root. This can be done with the system at
applications.
[root@ct001]# cd /var/cache
[root@ct001]# rm -rf logwatch >>> removes logwatch directory and all its contents
[root@ct001]# mkdir logwatch >>> creates the logwatch directory
Note: You may also see this on systems running 06MW software. On those systems the directory used is
/var/spool/clientmqueue

Resolution: 15
/dev/sda3 5315296 5315276 20 100% / <--root at 100%

cd /var/log

ls -al

-rw------- 1 root root 430067712 Jul 5 17:06 gehc_security

-rw------- 1 root root 434026867 Jul 3 04:00 gehc_security.1

-rw-r--r-- 1 root root 327425129 Jul 12 05:41 messages

When above mentioned 9 digit size 3 #'s files were reduced in size

© Consona
Generated by Consona Page 12/13
echo > gehc_security
echo > gehc_security.1
echo > messages

Or reduce them by a significant amount using the prune command:

cd /var/log;tail -n 1000 gehc_security > gehc_sec;chmod 600 gehc_sec;mv -f gehc_sec gehc_security;

cd /var/log;tail -n 1000 gehc_security.1 > gehc_sec;chmod 600 gehc_sec;mv -f gehc_sec gehc_security.1;

Resolution: 16
Have found another File area that gets hugh with Gigabyte files on a GOC6 system.
This was caused because the System creates these tmp files when a USB drive is installed on the HP host. They get orphaned
when the USB cable or drive is removed without ending the program.
cd /USB/service_usb_data/SFfiles
[insite@ct03 SFfiles]$ ls -al
total 1658352
drwxrwxrwx 2 ctuser users 453 Apr 14 17:30 ./
drwxrwxrwx 3 ctuser users 20 Mar 3 18:37 ../
-rw-rw-rw- 1 ctuser users 82702337 Apr 14 17:29 iq.CT03.1672.1.1.scan
-rw-rw-rw- 1 ctuser users 82702337 Apr 14 17:29 iq.CT03.1672.1.2.scan
-rw-rw-rw- 1 ctuser users 19320321 Apr 14 17:30 iq.CT03.1672.2.10.scan
-rw-rw-rw- 1 ctuser users 19320321 Apr 14 17:30 iq.CT03.1672.2.11.scan
-rw-rw-rw- 1 ctuser users 19320321 Apr 14 17:29 iq.CT03.1672.2.1.scan
-rw-rw-rw- 1 ctuser users 19320321 Apr 14 17:29 iq.CT03.1672.2.2.scan
-rw-rw-rw- 1 ctuser users 19320321 Apr 14 17:29 iq.CT03.1672.2.3.scan
-rw-rw-rw- 1 ctuser users 19320321 Apr 14 17:29 iq.CT03.1672.2.4.scan
-rw-rw-rw- 1 ctuser users 19320321 Apr 14 17:30 iq.CT03.1672.2.5.scan
-rw-rw-rw- 1 ctuser users 19320321 Apr 14 17:30 iq.CT03.1672.2.6.scan
-rw-rw-rw- 1 ctuser users 19320321 Apr 14 17:30 iq.CT03.1672.2.7.scan
-rw-rw-rw- 1 ctuser users 19320321 Apr 14 17:30 iq.CT03.1672.2.8.scan
-rw-rw-rw- 1 ctuser users 19320321 Apr 14 17:30 iq.CT03.1672.2.9.scan
-rw-rw-rw- 1 ctuser users 102617089 Mar 3 18:37 iq.CT03.977.1.1.scan
-rw-rw-rw- 1 ctuser users 102617089 Mar 3 18:38 iq.CT03.977.1.2.scan
-rw-rw-rw- 1 ctuser users 1114965505 Mar 3 18:38 iq.CT03.977.2.1.scan <-Large File

Can Delete all these files in this directory.

Remove Files
rm -i iq.CT03.977* or rm -i iq.CT03.*
Disk Query
[insite@ct03 ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 6.3G 5.0G 1.3G 81% /
/dev/sda1 99M 9.4M 85M 10% /boot
/dev/shm 7.9G 0 7.9G 0% /dev/shm
/dev/sda6 9.4G 544K 9.4G 1% /usr/interchange
/dev/sda7 106G 19G 87G 18% /usr/g
/dev/sdb5 137G 48G 90G 35% /usr/g/sdc_image_pool

Modality / Product

CT/e, CT Prospeed AI/FI Irix or Linux

LightSpeed 3.X (Ultra, Plus, QX/i) - Octane

Component

* 308I.2_H3.1M5
* V/R 6.03

Keywords

LSPlus LSUltra QXi LSPlus LSUltra QXi 2281177 2281177-3 2341104 2341104-2 2341104-3 2341104-4 B7858GD B7858LD lightspeed3.x
LightSpeedplus Warp3 308i.2_H3.1M5 enough space usr/g ark JSC
Hispeed NXi Hispeed LXI Hispeed FXi Hispeed Np CT ProSpeed AI CT ProSpeed FI enough space usr/g ark JSC

© Consona
 Generated by Consona Page 13/13
Error Code Description

Disk Space is Low message appears when rebooting saying , Call GE Service.

Details:
While scanning or booting up to applications, a Pop Up GUI appears saying:
1. Software Problem Detected on System.
2. Disk Space is Low.
3. See Error Log for which partition is causing the problem.
4. Complete current processes and shutdown system.
5. Call GE Service.

Last Modified Date:06-05-2014 ID:67670

© Consona