create new tag
view all tags

Linux Changes, August 2005

This page is for sharing experiences and tips to do with the August 2005 update of the Linux machines to Fedora Core 3.

CUPS Printing Queue Problems

Apparently we are experiencing a problem with the cups printer driver for our HP 4050 printers. Currently we have two Shake and Chaucer. The problem manifests itself during certain PDF print jobs. All PDF printing does not fail but on the documents that do it is always reproducible. The symptoms are as follows:
  • print job never prints or causes a jam in the middle of the job.
  • a printer error is displayed on the printer's LED display (79.00FE printer error)
  • when the printer is power cycled it appears to be online but will not print.

Unfortunately at the moment adminstrative intervention is required to free the queue and put the printer back online. We are trying to find a solution A.S.A.P. This model printer has been discontinued by HP and support in not readily available.

In a pinch your PDF job will print on Dali but we request you use this only if absolutely necessary until this problem is resolved as consumables on the color printer Dali are considerably more expensive.

-- DaveCostello - 14 Sep 2005

Update: Possible Workarounds

Adobe Acrobat 7 may be tickling a bug in the 4050 printers. We have had mild success printing the suspect PDF's on a solaris machine (lung.cs.rochester.edu) which has an old version 4.0 acroread. Using pdf2ps to convert to postscript worked but some pages seemed to have some unwanted noise on some of the fonts. And surprisingly xpdf seems to print the suspect pdf files cleanly without trouble on the HP4050.

-- DaveCostello - 15 Sep 2005


Linux Adobe Acrobat 7 initiated print jobs of certain pdf files (not all pdf files) to Shake or Chaucer (HP4050 printers) are definitely the jobs that are causing the trouble. Adobe has traditionally left their linux version of the reader as a "we'll get to it eventually..." free download. The Linux version has until recently been several versions behind the other desktop operating system versions. The most recent linux version download does not eliminate the problem nor does swapping cups drivers for those printers. If your job get's stuck you may have luck submitting it via xpdf.

-- DaveCostello - 14 Oct 2005


It is not only Acrodat that can create such (maybe faulty) ps from some pdf. I just found a pdf that converted by xpdf to ps produces the exact same problem. Also, the same ps causes this problem even if directly sent to the printer (with netcat). So, it seems that it is not cups fault. For the moment, the only way I found to print this file was to go back and forth between ps and pdf a couple of times: from the pdf save a ps (with xpdf) then use ps2pdf and go back to pdf, then again, convert it into ps with xpdf. In my case that did the job.

-- FabrizioMorbini - 11 Nov 2005

PDFs in mozilla

On one of my now-rare forays back onto linux, I discovered that the Acrobat (acroread) plug-in is not installed/enabled by default. I found that running the following did the trick:
Quit and restart mozilla/firefox. Type about:plugins into your address bar to verify if you like (there used to be a menu item for this, but I can't find it anymore).

If you don't trust installers, you can instead do the following by hand:

  cp -p /usr/staff/lib/Acrobat-7.0/Browser/intellinux/nnpdf.so ~/.mozilla/plugins
You may need to create your plugins directory first.

-- GeorgeFerguson - 13 Jan 2006

The problem described below is related to the mozplugger package that was installed as part of the original FC3 upgrade. It is incompatible with Adobe Acrobat 7.0 acroread. We had found this immediately after the initial upgrade and the simple solution was to simply remove the uneccessary mozplugger package. Unfortunately it appears the package was not removed universally and was not removed from the install scripts for new installs and so the problem we thought we had already resolved remained. I have seen to it that the mozplugger package is now uninstalled from all workstations and is no longer in the install scripts so as to not reintroduce the trouble on new installs. You should not have to take any action to repair this yourself as we have found removal of mozplugger restores pdf viewing capability.

We apologize for the confusion. Please feel free to drop a line to labstaff if you notice similar functionality issues in the future. In this case it would have alerted us sooner that the fix had not propogated as we thought it had.

-- DaveCostello - 01 Sep 2005

If you use mozilla instead of firefox, you may have noticed that following links to PDFs just brings up a blank window. Finding the fix to this problem was very painful (involving strace and the third and fourth pages of various google queries), so I thought I'd post it here. Simply type:

$ killall -9 mozilla                                                               
$ rm ~/.mozilla/pluginreg.dat                                                   
$ cp ~post/.netscape/mozpluggerrc ~/.netscape                                   
$ mozilla &

The restarted mozilla will correctly use acroread to display PDFs. Please don't ask me why you have to do something in the .netscape directory.

-- MattPost - 01 Sep 2005

Post Upgrade Login Failures FYI

Recently a handful of people have had trouble logging in after the Fedora 3 upgrades. In some cases the user could actually login okay but desktop controls and apps didn't work properly. In all of these recent cases the trouble was eventually traced back to incorrect or obsolete settings in the user's .cshrc file. In virtually all of these cases the user had copied commands into their login scripts that they didn't fully understand. This is always a bad idea for obvious reasons. That said, if you experience post upgrade login failure or instability and want to eliminate your highly customized .cshrc file as a cause, try replacing your .cshrc file with this one-liner:


# This line loads CS default settings
  source /usr/staff/lib/defaults/system.cshrc

-- DaveCostello - 18 Aug 2005

Console Login

I found that I could no longer login from the console on my office machine. I get a helpful dialog to the effect that "Your session seems to have lasted less than 10 seconds. Perhaps there's some problem." Indeed. How about some suggestions short of my going through all my dot-files (which, after all, were working fine before the changes)?

temporary workaround

This happened to me before the upgrade, and after notifying staff about it, I received a note saying they had made a change to the system.cshrc file which, when changed, allowed me to login again. I suspect this is a similar problem.

In the meantime, you can start an X session from the console that uses KDE like this:

1. create a file ~/.xinitrc with the following lines in it:

exec startkde

2. go to the console by typing CTRL-ALT-F1 and login.

3. type startx -- :1 &. Your X session will start.

4. after it loads, go back to the console (CTRL-ALT-F1) and logout (your X session will remain running).

5. go back to your X session by typing CTRL-ALT-F8 (alternately, you can skip step 4 and use ps to find the pid of your console shell and kill it directly).

Once the problem is fixed, simply remove your ~/.xinirc file and login per usual. The regular xdm login screen is always reachable by typing CTRL-ALT-F7.

-- MattPost - 05 Aug 2005


I found that the RSA host key had changed after my office machine was upgraded. This results in a particularly nasty warning message from ssh, to the effect that:
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.

One solution is to delete the offending key(s) from your ~/.ssh/known_hosts file. Perhaps someone knows a nicer tool/command to fix this.

We are recommending removing ~/.ssh/known_hosts altogether and building a new one as you reconnect to department machines. This may be related to the fact there has been a clean install rather than an "rh9 upgrade" install. The clean install process has stability advantages over the "upgrade" type especially when jumping several versions. If you are really opposed to that the message described above will tell you the offending line number. You can delete just that line to reset for that one host.

-- DaveCostello - 04 Aug 2005

X Forwarding (Updated)

There have been some security changes to the default ssh configuration in Fedora Core 3. One apparently is to NOT forward X11 by default. We will explore the security implications and config options and advise you soon. For now you can forward X via ssh by explicitly invoking the -X argument.

-- DaveCostello - 04 Aug 2005

Since the upgrade, you are probably getting errors similar to the following when ssh'ing:

$ ssh node0
Last login: Fri Aug  5 15:39:39 2005 from a22.cs.rochester.edu
X Error of failed request:  BadAccess (attempt to access private resource denied)
  Major opcode of failed request:  102 (X_ChangeKeyboardControl)
  Serial number of failed request:  7
  Current serial number in output stream:  11
X Error of failed request:  BadAccess (attempt to access private resource denied)
  Major opcode of failed request:  102 (X_ChangeKeyboardControl)
  Serial number of failed request:  8
  Current serial number in output stream:  11
X Error of failed request:  BadAccess (attempt to access private resource denied)
  Major opcode of failed request:  102 (X_ChangeKeyboardControl)
  Serial number of failed request:  9
  Current serial number in output stream:  11

This is a result of the openssh upgrade, which adds some security measures to X11 forwarding. The solution to ridding yourself of these error messages is to add the line

ForwardX11Trusted yes

to your ~/.ssh/config file. X applications will then forward just fine. If you still have trouble, make sure you don't have an inadvertent emacs alias to emacs -nw, and if that doesn't work, use the -Y flag to ssh.

-- MattPost - 05 Aug 2005


Emacs/Lisp behavior should be restored to pre-upgrade functionality. The URCS site-lisp symlink is active again.

-- DaveCostello - 18 Aug 2005

It appears that running lisp in emacs is completely broken. Pending a better solution, you can do the following in .emacs:

(load "/usr/staff/share/emacs/site-lisp/site-init-URCS.lisp")
This will bring in other site customizations such as auctex. If you want Just the ilisp stuff, you'll have to cut it out of the site-init-URCS.lisp file.

Running lisp (either lisp, a.k.a. cmucl, or acl) seems to be ok.

Identifying Linux Distribution

Just as a matter of trivia, does anyone how to reliably determine what linux distro is installed? As you probably know, uname -a gives you just the linux kernel release number. I'm looking for a command that will say "Fedora Core 3" or something like that. Magic incantations involving looking for files that are unlikely to be in other distros would be a hack.

If there's nothing, perhaps it makes sense for us to mod the /etc/motd message to identify this.

-- GeorgeFerguson - 04 Aug 2005

"cat /etc/issue |head -1" should do the trick.

-- BoHu - 04 Aug 2005

Thanks. That does have the information I was looking for, although the following doesn't inspire confidence in this mechanism:

sofia % man issue
No manual entry for issue
sofia % cat /etc/issue
Fedora Core release 3 (Heidelberg)
Kernel \r on an \m

sofia % man -k issue
issue                (5)  - pre-login message and identification file
issue.net [issue]    (5)  - identification file for telnet sessions
sofia % man 5 issue
No entry for issue in section 5 of the manual
Needless to say the file doesn't exist in OSX (or other Unix that I am familiar with).

-- GeorgeFerguson - 04 Aug 2005

For Redhat/Fedora distros: cat /etc/redhat-release

-- DaveCostello - 04 Aug 2005


xbiff doesn't seem to be included in the new distribution. If you want to run it, feel free to execute from ~scherer/bin.

Fonts with LaTex

Courier fonts don't show up correctly in the new system. Best workaround I've found is to copy the old PostScript Type 1 fonts into your local .fonts/ directory. Since ~/.fonts is now added to your default font path, this makes it all work.

On the other hand, remote logins don't seem to include this path, so the only remaining option for this case is to copy the font files directly into the directory from which you are compiling your LaTex document. (Yuck!). See ~scherer/writing/exchanger to grab a minimal set of font files and the indices that work with them:

. fonts.dir

. fonts.scale

. n022003l.pfb

. n022004l.pfb

. n022023l.pfb

. n022024l.pfb

temporary workaround

I think you can avoid copying the fonts by setting DVIPSHEADERS=$HOME/.fonts: and GS_LIB=$HOME/.fonts

...but why the system fonts don't work I don't know... -- DanGildea - 07 Aug 2005

Tunneling X from Sync/Swym

...doesn't seem to be working right now. Hopefully, this will be resolved shortly. Only workaround I know of is to use emacs with the -nw flag to edit in-place instead of in a separate window.

-- BillScherer - 04 Aug 2005

@see X Forwarding under the SSH heading above.

-- DaveCostello - 04 Aug 2005

The updated X Forwarding section above provides a fix for this problem.

-- MattPost - 05 Aug 2005

I'm still not able to use emacs except with -nw after trying the things above.

-- BillScherer - 09 Aug 2005

Interestingly, this now works correctly again. Anyone have any idea what changed?

-- BillScherer - 09 Sep 2005

...and now it's failing again. (In fact, it started failing again a day ofter my previous post.) I haven't touched any of my configuration options, so something very strange is going on here. Am I the only one having this trouble?

- BillScherer - 17 Sep 2005

Topic revision: r1 - 2006-01-13 - GeorgeFerguson
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding URCS? Send feedback