Apparently OPENsuse 11.3 has such a low level of sophistication that chokes trying to configure an HP LaserJet 5P. After printing a test page from the initial configuration dialog page OPENsuse enters spitup mode whenever any additional steps are taken. Trying to enter additional configuration information such as sharing parameters so badly confuses the system it looses all track of printer information. In response to any clickable option on the printer configuration page it request permission to restart the CUPS dameon. IF the YES option is selected the system displays a spinning busy icon then reports that no CUPS dameon was found. Select another configuration option the system again requests permission to restart the dameon - reports none was found. A life time could easily be wasted trying to get a printer to work.
Apparently the only viable option is not to run OPENsuse on systems with a printer connected to a local LPT port. This is re-enforced by noting that FEDORA 13 running on the same hardware, connected to the same printer with the same cable manages and shares the printer with the networks without hesitation or problems.
> Apparently the only viable option is not to run OPENsuse
that conclusion is as “right on” as anything else this first time
anti-openSUSEer wrote from an flexo.provo.novell.com IP…
disgruntled, maybe??
–
DenverD
CAVEAT: http://is.gd/bpoMD
[NNTP posted w/openSUSE 11.3, KDE4.5.5, Thunderbird3.0.11, nVidia
173.14.28 3D, Athlon 64 3000+]
“It is far easier to read, understand and follow the instructions than
to undo the problems caused by not.” DD 23 Jan 11
I did not run HPLIP specifically. I only used the printer configuration screens provided by the installation processes or from the YaST printer option.
Sorry to read of your problems with the HP LJ 5P. Until recently we had 2 HP printers at home with openSUSE-11.3: an HP Deskjet 5652 (connected to a local LPT port) and an HP-Premium All-In-One C390a connected via wireless (we have only one now, the C309a). Both HP printers ‘just worked’ . So I do not thnk this a general issue of HP printers being too advanced for openSUSE. :\ Far from it.
Glad to read this works in Fedora 13. Thats a great distribution, and I am a big Fedora fan.
Still, I am surprised this does not work in openSUSE for you. Could it be you have something wrong in your configuration? Could it be you installed an unofficial app/library for a 3rd party repository that has caused the problem ? What is the output of:
Please answer oldcpu’s query about cups and hplip packages installed, as well as the ‘zypper lr -d’ output. That will tell us which repo the packages came from. Mixing packages can cause issues (as mentioned in the link I provided).
Post the output of this troubleshooting tool (as regular user should be ok)
hp-check
That will tell us about the URI and backend configuration, (and a heap of other possibly relevant info). Now it saves this output to hp-check.log, and the report is lengthy, so you should cut and paste this to suse paste, (set ‘Delete after’ to ‘Never’ in that page), and paste the link to it here.
>
> I would be estatic if I could try the -hp-setup- option, if only it were
> available.
>
> Unfortunately the -restart cups dameon- and -no dameon found- tag team
> prevent access to -hp-setup-.
>
> During the installation sequences I have seen the -hp-setup- but I am
> apprehensive to try a 4’th install only to find -hp-setup- won’t work
> either.
Try removing the .hplip directory in your home folder before you try hp-
setup again. It causes some strange issues on one machine at the office
until you remove that folder and let hp-setup rebuild it. I never have
figured out what scrambles things.
I also have to manually change the driver hp-setup chooses for an old
hp4000t. Those old tanks had a number of subtly different features that
require specific drivers.
I finally have an operational printer. Thank all of you that have offered possible solutions to my headaches.
I may have been too aggressive during the installation phase of the first few attempts. During the first 3 installs I selected the options to download the additional and upgrade repositories. I also chose the options for installing the upgrades if available from the installation matrix. This seems to have caused subtle conflicts between some of the daemon.
During my last install I still chose to download the additional and upgrade repositories but did not choose the install upgrades if available options. I also passed on the opportunity to run the on-line upgrade during the later phases of the install. I waited until all phases of the install, initial start-up, and basic system setup were completed before I tried the printer.
After re-booting and testing that there were no other problems I tried the printer set-up from the YaST menu again. This time it was successful. It now works fine both as the local printer ans is successfully shared across my local LAN.
