Setting Photon Fonts from a telnet session

QNX USERS QNX6 - OS
#1

I have a client that tells me his Photon desktop and any GUI programs display nothing for all characters. Sloginfo tells me FontDesc is NULL.

What could have gone wrong? How can I restore it from a terminal session because we can not use the utilities such as fontadmin because there are no fonts?

I’ve been promoting how stable and reliable QNX is and something like this happens. Any idea how this could have happen? The user does not have acccess beyond my full-screen program, therfore it wasn’t from someone playing with the configuration. Must have been something during boot or shutdown. The power is abruptly turned-off without the shutdown sequence.

#2

This is somewhat mysterious. If you do not have files open for write when the power is turned off, there is no way for that event to have caused this. If you do have files open for write, it is possible that you have incrementally corrupted your hard drive, possibly creating cross links that ultimately have caused this problem. If you run chkfsys on startup, this should not happen.

A good way to investigate possibility would be to telnet in, stop any process that has a file open for write, and run chkfsys. If you see a lot of file fixing going on, you know this is a problem.

#3

Thank you for the fast response.

I’m aware of chkfsys during boot, but can not get it to run and fix automatically. I use “chkfsys -rsqp /”, but the -p option does not make it fixed without prompting. Do I have my options wrong?

The chkfsys would be great to add to my boot scripts if I could get it to work without use interaction, but my pressing problem is how to fix the fonts. I can’t run the GUI program (there are no characters displayed) therefore how can I repair the system short of rebuilding the disk?

#4

I use: chkfsys -P -r

Before worrying about how to fix this, find out what went wrong. Run chkfsys and see if there is disk corruption. If not, then I am on the wrong track. If there is corruption, once it is fixed you can evaluate what is missing. If the font directory is gone, you will have to copy it back. It might be better to rebuild the disk, since you may miss something otherwise.

#5

Thanks, the upper case P was the problem.

Another problem I ran into is how to run it on startup. If I put it into one of my normal startup scripts, it appears to the close the file because the remaing part of the script doesn’t run. Where do you recommend chkfsys run from?

O’yea I rebuild the OS image to fix the other problem.

#6

I run chkfsys from /etc/rc.d/rc.local. I want to back track a little. You posted this as a severe problem where your fonts were gone. I suggested that cumulative file corruption might be the cause. While chkfsys will repair things at startup, if you are getting corruption at all because of a power down, this suggests a problem. The QNX file system is fairly robust, but it is not magic. If you power down in the middle of an update, and it appears that your users are doing just that, then maybe you need to rethink what is going on. That is not to say that some systems need to work this way.

#7

Thanks again.

My system is a factory inspection machine, therefore the power can be turned off or disconnected anytime. When my program is running, there are no disk accesses to avoid this problem. I guess the issue is when is the OS accessing files. For sure during boot, therefore that is a time when power off can cause issues, but is there something else I can do to minimize the chance of file corruption?

#8

If you start the machine and do all your disk access at the start, then the only time you could potentially cause corruption would be during that startup period. Even this is unlikely because read access cannot cause a problem either. I would check to see if there are any log files open, eg. syslog.

#9

Yes read acccess can create problem, because when a read is performed the “last access” attribute of the file is updated. This can be disable with the proper option to the device driver.

#10

Mario,

Mario, I really doubt this could cause a problem.   This type of update would consist of the write of a sector over the same sector.   The only possibility then would be if the power fails at just the right moment when the head was flying over a sector.   I believe the electronics of hard drives are electrically buffered to prevent this.   The result would be corrupt data on the sector, not a corrupt file system, as the meta-data is separate.   In addition, the sector would get a CRC error, and would show up as a bad sector.   I haven't seen a bad sector on a good drive in more than 10 years.
#11

I just got another file corruption failure. This time the x86/runtime load wouldn’t get past all the dots in the alt boot prompt. It just hangs.

I should add the disk I’m using is an EDI Compact Flash device. I’ve never had file corruption problems through my two year development period until I deployed with hardware using Compact-Flash. Any thoughts? Could it be related to slow the very slow write times?