After a long period of smooth sailing I suddenly encountered a CUPS problem. Why I have got it is uncertain, maybe as a result of a yum upgrade run. I had to reinstall FC 5 due to some disk trouble (possibly because a blown fuse cut the electricity supply to my desk) so I imagined that I would be interested in upgraded programs since I burned the FC5 distro.
I remove and reinstall the printer (which btw. is online, lights are up :-) ) and when sending a testpage to the printer i get the following message:
"There was a problem sending CUPS test page to laser1 queue (my chosen printer name)
/usr/bin/lpr connection refused
The following daemons are running: cupsd cups-config-daemon
I would be grateful to receive some help on this one.
Brgds PAR
PerAntonRønning wrote:
After a long period of smooth sailing I suddenly encountered a CUPS problem. Why I have got it is uncertain, maybe as a result of a yum upgrade run. I had to reinstall FC 5 due to some disk trouble (possibly because a blown fuse cut the electricity supply to my desk) so I imagined that I would be interested in upgraded programs since I burned the FC5 distro.
I remove and reinstall the printer (which btw. is online, lights are up :-) ) and when sending a testpage to the printer i get the following message:
"There was a problem sending CUPS test page to laser1 queue (my chosen printer name)
/usr/bin/lpr connection refused
The following daemons are running: cupsd cups-config-daemon
I would be grateful to receive some help on this one.
Brgds PAR
I had a problem like that. I had to delete the printer from the printer setup program and then re-load it with the same name and so forth. It fixed the problem.
Somebody in the thread at some point said:
I remove and reinstall the printer (which btw. is online, lights are up :-) ) and when sending a testpage to the printer i get the
I had a problem like that. I had to delete the printer from the printer setup program and then re-load it with the same name and so
He does mention that he did this. But he doesn't mention how the printer is connected to his machine. "Connection refused" usually means that something was alive at the IP address being touched but nothing was listening at the port being used. If the printer was a network printer, for example, he might have chosen the wrong protocol and be trying to touch, say, port 9100 when the printer is not listening there.
Have a look in the cups error log at /var/log/cups/error_log and see if there is more info, and confirm that cups is still running
ps -Af | grep cupsd
-Andy
Andy Green wrote:
Somebody in the thread at some point said:
I remove and reinstall the printer (which btw. is online, lights are up :-) ) and when sending a testpage to the printer i get the
I had a problem like that. I had to delete the printer from the printer setup program and then re-load it with the same name and so
He does mention that he did this. But he doesn't mention how the printer is connected to his machine. "Connection refused" usually means that something was alive at the IP address being touched but nothing was listening at the port being used. If the printer was a network printer, for example, he might have chosen the wrong protocol and be trying to touch, say, port 9100 when the printer is not listening there.
Have a look in the cups error log at /var/log/cups/error_log and see if there is more info, and confirm that cups is still running
ps -Af | grep cupsd
-Andy
I am so sorry :-[
There was no use to my message. He said he did what I suggested already. I was stupid to suggest it again. Sorry I was still asleep =-O
Hi Andy a minor extract of the error_log shows this: I [22/Aug/2007:12:42:00 +0200] Full reload is required. I [22/Aug/2007:12:42:00 +0200] Loaded MIME database from '/etc/cups': 33 types, 38 filters... I [22/Aug/2007:12:42:01 +0200] Loading job cache file "/var/cache/cups/job.cache"... I [22/Aug/2007:12:42:01 +0200] Full reload complete. I [22/Aug/2007:12:42:01 +0200] Listening to 127.0.0.1:631 on fd 0... E [22/Aug/2007:12:42:01 +0200] Unable to set ACLs on root certificate "/var/run/cups/certs/0" - Operation not supported
It seems to listen to 127.0.0.1:631, which should be lo. The last message tough "operation not supported" does not explain itself, at least not to me.
ps -Af | grep cupsd shows that the daemon is up and running. So I'm scratching my head a bit on this.
Brgs PAR
Andy Green wrote:
Somebody in the thread at some point said:
I remove and reinstall the printer (which btw. is online, lights are up :-) ) and when sending a testpage to the printer i get the
I had a problem like that. I had to delete the printer from the printer setup program and then re-load it with the same name and so
He does mention that he did this. But he doesn't mention how the printer is connected to his machine. "Connection refused" usually means that something was alive at the IP address being touched but nothing was listening at the port being used. If the printer was a network printer, for example, he might have chosen the wrong protocol and be trying to touch, say, port 9100 when the printer is not listening there.
Have a look in the cups error log at /var/log/cups/error_log and see if there is more info, and confirm that cups is still running
ps -Af | grep cupsd
-Andy
PerAntonRønning wrote:
Hi Andy a minor extract of the error_log shows this: I [22/Aug/2007:12:42:00 +0200] Full reload is required. I [22/Aug/2007:12:42:00 +0200] Loaded MIME database from '/etc/cups': 33 types, 38 filters... I [22/Aug/2007:12:42:01 +0200] Loading job cache file "/var/cache/cups/job.cache"... I [22/Aug/2007:12:42:01 +0200] Full reload complete. I [22/Aug/2007:12:42:01 +0200] Listening to 127.0.0.1:631 on fd 0... E [22/Aug/2007:12:42:01 +0200] Unable to set ACLs on root certificate "/var/run/cups/certs/0" - Operation not supported
It seems to listen to 127.0.0.1:631, which should be lo. The last message tough "operation not supported" does not explain itself, at least not to me. ps -Af | grep cupsd shows that the daemon is up and running. So I'm scratching my head a bit on this.
Brgs PAR
The "operation not supported" is an indication that selinux is not enabled. So CUPS could not set the Access Control List values. This will not stop CUPS from running. The "Listening to 127.0.0.1:631" says that the CUPS web interface is only available to the local machine, on port 631. You can not connect to it from another machine on the network. (This does not affect connecting to printers on your machine - that is another setting.)
Mikkel
On Wed, 2007-08-22 at 13:27 -0500, Mikkel L. Ellertson wrote:
PerAntonRønning wrote:
Hi Andy a minor extract of the error_log shows this: I [22/Aug/2007:12:42:00 +0200] Full reload is required. I [22/Aug/2007:12:42:00 +0200] Loaded MIME database from '/etc/cups': 33 types, 38 filters... I [22/Aug/2007:12:42:01 +0200] Loading job cache file "/var/cache/cups/job.cache"... I [22/Aug/2007:12:42:01 +0200] Full reload complete. I [22/Aug/2007:12:42:01 +0200] Listening to 127.0.0.1:631 on fd 0... E [22/Aug/2007:12:42:01 +0200] Unable to set ACLs on root certificate "/var/run/cups/certs/0" - Operation not supported
It seems to listen to 127.0.0.1:631, which should be lo. The last message tough "operation not supported" does not explain itself, at least not to me. ps -Af | grep cupsd shows that the daemon is up and running. So I'm scratching my head a bit on this.
Brgs PAR
The "operation not supported" is an indication that selinux is not enabled. So CUPS could not set the Access Control List values. This will not stop CUPS from running. The "Listening to 127.0.0.1:631" says that the CUPS web interface is only available to the local machine, on port 631. You can not connect to it from another machine on the network. (This does not affect connecting to printers on your machine - that is another setting.)
Mikkel
Maybe this was already indicated. Is the printer attached to the machine or is it a network printer? If the latter then the error is in cupsd.conf. -- ======================================================================= Things are more like they are today than they ever were before. -- Dwight Eisenhower ======================================================================= Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net
Aaron Konstam wrote:
On Wed, 2007-08-22 at 13:27 -0500, Mikkel L. Ellertson wrote:
PerAntonRønning wrote:
Hi Andy a minor extract of the error_log shows this: I [22/Aug/2007:12:42:00 +0200] Full reload is required. I [22/Aug/2007:12:42:00 +0200] Loaded MIME database from '/etc/cups': 33 types, 38 filters... I [22/Aug/2007:12:42:01 +0200] Loading job cache file "/var/cache/cups/job.cache"... I [22/Aug/2007:12:42:01 +0200] Full reload complete. I [22/Aug/2007:12:42:01 +0200] Listening to 127.0.0.1:631 on fd 0... E [22/Aug/2007:12:42:01 +0200] Unable to set ACLs on root certificate "/var/run/cups/certs/0" - Operation not supported
It seems to listen to 127.0.0.1:631, which should be lo. The last message tough "operation not supported" does not explain itself, at least not to me. ps -Af | grep cupsd shows that the daemon is up and running. So I'm scratching my head a bit on this.
Brgs PAR
The "operation not supported" is an indication that selinux is not enabled. So CUPS could not set the Access Control List values. This will not stop CUPS from running. The "Listening to 127.0.0.1:631" says that the CUPS web interface is only available to the local machine, on port 631. You can not connect to it from another machine on the network. (This does not affect connecting to printers on your machine - that is another setting.)
Mikkel
Maybe this was already indicated. Is the printer attached to the machine or is it a network printer? If the latter then the error is in cupsd.conf.
--
Things are more like they are today than they ever were before. -- Dwight Eisenhower ======================================================================= Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net
The printer is attached directly to the PC, it is not a network printer. BRGDS PAR
Mikkel L. Ellertson wrote:
PerAntonRønning wrote:
Hi Andy a minor extract of the error_log shows this: I [22/Aug/2007:12:42:00 +0200] Full reload is required. I [22/Aug/2007:12:42:00 +0200] Loaded MIME database from '/etc/cups': 33 types, 38 filters... I [22/Aug/2007:12:42:01 +0200] Loading job cache file "/var/cache/cups/job.cache"... I [22/Aug/2007:12:42:01 +0200] Full reload complete. I [22/Aug/2007:12:42:01 +0200] Listening to 127.0.0.1:631 on fd 0... E [22/Aug/2007:12:42:01 +0200] Unable to set ACLs on root certificate "/var/run/cups/certs/0" - Operation not supported
It seems to listen to 127.0.0.1:631, which should be lo. The last message tough "operation not supported" does not explain itself, at least not to me. ps -Af | grep cupsd shows that the daemon is up and running. So I'm scratching my head a bit on this.
Brgs PAR
The "operation not supported" is an indication that selinux is not enabled. So CUPS could not set the Access Control List values. This will not stop CUPS from running. The "Listening to 127.0.0.1:631" says that the CUPS web interface is only available to the local machine, on port 631. You can not connect to it from another machine on the network. (This does not affect connecting to printers on your machine - that is another setting.)
Mikkel
I don't have a real network, just a backup PC connected through an eth card. I do not need to print from other PC's, so what you say may imply that this should work by the look of it? Regarding SElinux - /etc/selinux/config contains: # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=enforcing # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted # SETLOCALDEFS= Check local definition changes SETLOCALDEFS=0
As to checking if SElinux is enabled the command (listed in my FC5 "bible") $/usr/sbin/sestatus -v gives as output:
SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 21 Policy from config file: targeted
Process contexts: Current context: user_u:system_r:unconfined_t Init context: system_u:system_r:init_t /sbin/mingetty system_u:system_r:getty_t
File contexts: Controlling term: user_u:object_r:devpts_t /etc/passwd system_u:object_r:etc_t /etc/shadow system_u:object_r:shadow_t /bin/bash system_u:object_r:shell_exec_t /bin/login system_u:object_r:login_exec_t /bin/sh system_u:object_r:bin_t -> system_u:object_r:shell_exec_t /sbin/agetty system_u:object_r:getty_exec_t /sbin/init system_u:object_r:init_exec_t /sbin/mingetty system_u:object_r:getty_exec_t /usr/sbin/sshd system_u:object_r:sshd_exec_t /lib/libc.so.6 system_u:object_r:lib_t -> system_u:object_r:lib_t /lib/ld-linux.so.2 system_u:object_r:lib_t -> system_u:object_r:ld_so_t
... so SElinux seems to be enabled. BUT: In my security level configuration I don't find an entry for "printer" or "printing", should I expect such an entry?
Perhaps I need to reinstall CUPS - which would be the best download site ?
PerAntonRønning wrote:
Mikkel L. Ellertson wrote:
PerAntonRønning wrote:
Hi Andy a minor extract of the error_log shows this: I [22/Aug/2007:12:42:00 +0200] Full reload is required. I [22/Aug/2007:12:42:00 +0200] Loaded MIME database from '/etc/cups': 33 types, 38 filters... I [22/Aug/2007:12:42:01 +0200] Loading job cache file "/var/cache/cups/job.cache"... I [22/Aug/2007:12:42:01 +0200] Full reload complete. I [22/Aug/2007:12:42:01 +0200] Listening to 127.0.0.1:631 on fd 0... E [22/Aug/2007:12:42:01 +0200] Unable to set ACLs on root certificate "/var/run/cups/certs/0" - Operation not supported
It seems to listen to 127.0.0.1:631, which should be lo. The last message tough "operation not supported" does not explain itself, at least not to me. ps -Af | grep cupsd shows that the daemon is up and running. So I'm scratching my head a bit on this.
Brgs PAR
The "operation not supported" is an indication that selinux is not enabled. So CUPS could not set the Access Control List values. This will not stop CUPS from running. The "Listening to 127.0.0.1:631" says that the CUPS web interface is only available to the local machine, on port 631. You can not connect to it from another machine on the network. (This does not affect connecting to printers on your machine - that is another setting.)
Mikkel
I don't have a real network, just a backup PC connected through an eth card. I do not need to print from other PC's, so what you say may imply that this should work by the look of it? Regarding SElinux - /etc/selinux/config contains: # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=enforcing # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted # SETLOCALDEFS= Check local definition changes SETLOCALDEFS=0
As to checking if SElinux is enabled the command (listed in my FC5 "bible") $/usr/sbin/sestatus -v gives as output:
SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 21 Policy from config file: targeted
Process contexts: Current context: user_u:system_r:unconfined_t Init context: system_u:system_r:init_t /sbin/mingetty system_u:system_r:getty_t
File contexts: Controlling term: user_u:object_r:devpts_t /etc/passwd system_u:object_r:etc_t /etc/shadow system_u:object_r:shadow_t /bin/bash system_u:object_r:shell_exec_t /bin/login system_u:object_r:login_exec_t /bin/sh system_u:object_r:bin_t -> system_u:object_r:shell_exec_t /sbin/agetty system_u:object_r:getty_exec_t /sbin/init system_u:object_r:init_exec_t /sbin/mingetty system_u:object_r:getty_exec_t /usr/sbin/sshd system_u:object_r:sshd_exec_t /lib/libc.so.6 system_u:object_r:lib_t -> system_u:object_r:lib_t /lib/ld-linux.so.2 system_u:object_r:lib_t -> system_u:object_r:ld_so_t
... so SElinux seems to be enabled. BUT: In my security level configuration I don't find an entry for "printer" or "printing", should I expect such an entry?
--- OPPPS! It must have been too late in the evening. I was referring to the firewall section (tab) of the config screen not the SElinux tab. Printing appears under SELinux. So, this seems to be a real puzzle, perhaps I have to reinstall FC5. (I am a bit conservative when it comes to new versions, I want them to be tested out a bit first, so I wait with FC7. Anyone thinking this is too conservative?)
On Thu, 2007-08-23 at 11:00 +0200, PerAntonRønning wrote:
PerAntonRønning wrote:
Mikkel L. Ellertson wrote:
PerAntonRønning wrote:
Hi Andy a minor extract of the error_log shows this: I [22/Aug/2007:12:42:00 +0200] Full reload is required. I [22/Aug/2007:12:42:00 +0200] Loaded MIME database from '/etc/cups': 33 types, 38 filters... I [22/Aug/2007:12:42:01 +0200] Loading job cache file "/var/cache/cups/job.cache"... I [22/Aug/2007:12:42:01 +0200] Full reload complete. I [22/Aug/2007:12:42:01 +0200] Listening to 127.0.0.1:631 on fd 0... E [22/Aug/2007:12:42:01 +0200] Unable to set ACLs on root certificate "/var/run/cups/certs/0" - Operation not supported
It seems to listen to 127.0.0.1:631, which should be lo. The last message tough "operation not supported" does not explain itself, at least not to me. ps -Af | grep cupsd shows that the daemon is up and running. So I'm scratching my head a bit on this.
Brgs PAR
The "operation not supported" is an indication that selinux is not enabled. So CUPS could not set the Access Control List values. This will not stop CUPS from running. The "Listening to 127.0.0.1:631" says that the CUPS web interface is only available to the local machine, on port 631. You can not connect to it from another machine on the network. (This does not affect connecting to printers on your machine - that is another setting.)
Mikkel
I don't have a real network, just a backup PC connected through an eth card. I do not need to print from other PC's, so what you say may imply that this should work by the look of it? Regarding SElinux - /etc/selinux/config contains: # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=enforcing # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted # SETLOCALDEFS= Check local definition changes SETLOCALDEFS=0
As to checking if SElinux is enabled the command (listed in my FC5 "bible") $/usr/sbin/sestatus -v gives as output:
SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 21 Policy from config file: targeted
Process contexts: Current context: user_u:system_r:unconfined_t Init context: system_u:system_r:init_t /sbin/mingetty system_u:system_r:getty_t
File contexts: Controlling term: user_u:object_r:devpts_t /etc/passwd system_u:object_r:etc_t /etc/shadow system_u:object_r:shadow_t /bin/bash system_u:object_r:shell_exec_t /bin/login system_u:object_r:login_exec_t /bin/sh system_u:object_r:bin_t -> system_u:object_r:shell_exec_t /sbin/agetty system_u:object_r:getty_exec_t /sbin/init system_u:object_r:init_exec_t /sbin/mingetty system_u:object_r:getty_exec_t /usr/sbin/sshd system_u:object_r:sshd_exec_t /lib/libc.so.6 system_u:object_r:lib_t -> system_u:object_r:lib_t /lib/ld-linux.so.2 system_u:object_r:lib_t -> system_u:object_r:ld_so_t
... so SElinux seems to be enabled. BUT: In my security level configuration I don't find an entry for "printer" or "printing", should I expect such an entry?
--- OPPPS! It must have been too late in the evening. I was referring to the firewall section (tab) of the config screen not the SElinux tab. Printing appears under SELinux. So, this seems to be a real puzzle, perhaps I have to reinstall FC5. (I am a bit conservative when it comes to new versions, I want them to be tested out a bit first, so I wait with FC7. Anyone thinking this is too conservative?)
I do. How about disabling selinux and see if printing starts working. In the environment you describe I don't see that selinux is doing that much for you.
As to the error below it is really mysterious.
E [22/Aug/2007:12:42:01 +0200] Unable to set ACLs on root certificate
"/var/run/cups/certs/0" - Operation not supported
/var/run/cups/certs/0 is r--r---- on my machine. Setting the ACL on such a file seems hard to say the least.
--
======================================================================= ... it is easy to be blinded to the essential uselessness of them by the sense of achievement you get from getting them to work at all. In other words... their fundamental design flaws are completely hidden by their superficial design flaws. -- The Hitchhiker's Guide to the Galaxy, on the products of the Sirius Cybernetics Corporation. ======================================================================= Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net
Aaron Konstam wrote:
On Thu, 2007-08-23 at 11:00 +0200, PerAntonRønning wrote:
PerAntonRønning wrote:
Mikkel L. Ellertson wrote:
PerAntonRønning wrote:
Hi Andy a minor extract of the error_log shows this: I [22/Aug/2007:12:42:00 +0200] Full reload is required. I [22/Aug/2007:12:42:00 +0200] Loaded MIME database from '/etc/cups': 33 types, 38 filters... I [22/Aug/2007:12:42:01 +0200] Loading job cache file "/var/cache/cups/job.cache"... I [22/Aug/2007:12:42:01 +0200] Full reload complete. I [22/Aug/2007:12:42:01 +0200] Listening to 127.0.0.1:631 on fd 0... E [22/Aug/2007:12:42:01 +0200] Unable to set ACLs on root certificate "/var/run/cups/certs/0" - Operation not supported
It seems to listen to 127.0.0.1:631, which should be lo. The last message tough "operation not supported" does not explain itself, at least not to me. ps -Af | grep cupsd shows that the daemon is up and running. So I'm scratching my head a bit on this.
Brgs PAR
The "operation not supported" is an indication that selinux is not enabled. So CUPS could not set the Access Control List values. This will not stop CUPS from running. The "Listening to 127.0.0.1:631" says that the CUPS web interface is only available to the local machine, on port 631. You can not connect to it from another machine on the network. (This does not affect connecting to printers on your machine - that is another setting.)
Mikkel
I don't have a real network, just a backup PC connected through an eth card. I do not need to print from other PC's, so what you say may imply that this should work by the look of it? Regarding SElinux - /etc/selinux/config contains: # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=enforcing # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted # SETLOCALDEFS= Check local definition changes SETLOCALDEFS=0
As to checking if SElinux is enabled the command (listed in my FC5 "bible") $/usr/sbin/sestatus -v gives as output:
SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 21 Policy from config file: targeted
Process contexts: Current context: user_u:system_r:unconfined_t Init context: system_u:system_r:init_t /sbin/mingetty system_u:system_r:getty_t
File contexts: Controlling term: user_u:object_r:devpts_t /etc/passwd system_u:object_r:etc_t /etc/shadow system_u:object_r:shadow_t /bin/bash system_u:object_r:shell_exec_t /bin/login system_u:object_r:login_exec_t /bin/sh system_u:object_r:bin_t -> system_u:object_r:shell_exec_t /sbin/agetty system_u:object_r:getty_exec_t /sbin/init system_u:object_r:init_exec_t /sbin/mingetty system_u:object_r:getty_exec_t /usr/sbin/sshd system_u:object_r:sshd_exec_t /lib/libc.so.6 system_u:object_r:lib_t -> system_u:object_r:lib_t /lib/ld-linux.so.2 system_u:object_r:lib_t -> system_u:object_r:ld_so_t
... so SElinux seems to be enabled. BUT: In my security level configuration I don't find an entry for "printer" or "printing", should I expect such an entry?
--- OPPPS! It must have been too late in the evening. I was referring to the firewall section (tab) of the config screen not the SElinux tab. Printing appears under SELinux. So, this seems to be a real puzzle, perhaps I have to reinstall FC5. (I am a bit conservative when it comes to new versions, I want them to be tested out a bit first, so I wait with FC7. Anyone thinking this is too conservative?)
I do. How about disabling selinux and see if printing starts working. In the environment you describe I don't see that selinux is doing that much for you.
As to the error below it is really mysterious.
E [22/Aug/2007:12:42:01 +0200] Unable to set ACLs on root certificate
"/var/run/cups/certs/0" - Operation not supported
/var/run/cups/certs/0 is r--r---- on my machine. Setting the ACL on such a file seems hard to say the least.
I did disable selinux, rebooted the machine, but nothing changed. So, this may be due to some CUPS problem. This is something I have never done before - should I remove and then download and reinstall the whole thing? Next thing may be to reinstall FC5 from the bottom and up. THAT I've done before :-)
Brgds PAR
On Thu, 2007-08-23 at 15:33 +0200, PerAntonRønning wrote:
I do. How about disabling selinux and see if printing starts working.
In the environment you describe I don't see that selinux is doing
that
much for you.
As to the error below it is really mysterious.
E [22/Aug/2007:12:42:01 +0200] Unable to set ACLs on root
certificate
"/var/run/cups/certs/0" - Operation not supported
/var/run/cups/certs/0 is r--r---- on my machine. Setting the ACL on
such
a file seems hard to say the least.
I did disable selinux, rebooted the machine, but nothing changed. So, this may be due to some CUPS problem. This is something I have never done before - should I remove and then download and reinstall the whole thing? Next thing may be to reinstall FC5 from the bottom and up. THAT I've done before :-)
Brgds PAR
Well everyone has given it a shot and failed so I guess going back to FC5 is an option. It does no good to say that cups works in f7. But I guess we have run out of suggestions, Just for laughs you could file a bugzilla including that strange error message and see if nay one among the cups developers can recognize its meaning.
On Thu, 2007-08-23 at 15:33 +0200, PerAntonRønning wrote:
I did disable selinux, rebooted the machine, but nothing changed. So, this may be due to some CUPS problem. This is something I have never done before - should I remove and then download and reinstall the whole thing? Next thing may be to reinstall FC5 from the bottom and up. THAT I've done before :-)
But, without knowing what the cause was, you might encounter it again. How many times do you want to re-install the whole OS?
Removing CUPS will be a bit difficult, it's deemed to be a core component. You could try manually removing the current configuration files, and then doing a rpm freshen to re-install CUPS over the top.
But noticing that you're running FC5, you'd be hard pressed to get a result from making a bugzilla entry, unless someone can recognise the condition as being a user error (i.e. something that you can change, rather than requiring a change to CUPS). FC5 is no longer supported.
Tim wrote:
On Thu, 2007-08-23 at 15:33 +0200, PerAntonRønning wrote:
I did disable selinux, rebooted the machine, but nothing changed. So, this may be due to some CUPS problem. This is something I have never done before - should I remove and then download and reinstall the whole thing? Next thing may be to reinstall FC5 from the bottom and up. THAT I've done before :-)
But, without knowing what the cause was, you might encounter it again. How many times do you want to re-install the whole OS?
Removing CUPS will be a bit difficult, it's deemed to be a core component. You could try manually removing the current configuration files, and then doing a rpm freshen to re-install CUPS over the top.
But noticing that you're running FC5, you'd be hard pressed to get a result from making a bugzilla entry, unless someone can recognise the condition as being a user error (i.e. something that you can change, rather than requiring a change to CUPS). FC5 is no longer supported.
Point taken, I do not want frequent reinstalls. Here is the chain of events: 1) Blown fuse, powercut. 2) Reboot, but could not mount disk. Probably corrupted tables or somethiong like that. 3) Using rescue CD - but I did not find a way out of the mess by means of that, and I had no Internet connecion, so there was nobody to ask. 4) Reinstalling FC 5 5) Hoping to come up to speed with current software versions by running $yum upgrade which I was under the impression would take care of that. This may have been a grave mistake 6) CUPS problems started after 5).
For this reason I wonder if I have any choice but reinstalling FC 5, even if it is not supported any more.
What about FC 7? I have what I think must be a hardware problem, since it has occured under SuSe, Mandrake, Madriva and now FC 5: Screen freeze. The PC blocks out keyboard and mouse, and anything that moved on the screen freezes. I have no clue as to why, or what triggers it, and nobody on this list or the Mandriva newbie list had either. So: Hardware trouble. Before reinstalling I used to ssh from my old backup PC and run killall -9 Xorg, then I could log on again and everything was up and running. But now when the freeze happens the network connection is also reset, so I cannot get access to the PC from the backup PC. Yet another reason why I may have to reinstall. I am contemplating buying a new machine, hoping that I will say goodbye to this problem. But earlier it was easy to get around it, I just run the whole machine through the backup PC, using ssh connections. Thus I could focus on productive programming instead of error corrections. But all that has changed now, even if I use ssh -X localhost I have trouble in starting GUI applications. So this is relatively "deep shit".
PAR
On Fri, 2007-08-24 at 13:16 +0200, PerAntonRønning wrote:
What about FC 7? I have what I think must be a hardware problem, since it has occured under SuSe, Mandrake, Madriva and now FC 5: Screen freeze. The PC blocks out keyboard and mouse, and anything that moved on the screen freezes. I have no clue as to why, or what triggers it, and nobody on this list or the Mandriva newbie list had either. So: Hardware trouble.
That does sound ominous. Do you know why the fuse blew? Perhaps you had some mains trouble at that time, and some damage occured to your computer.
Though it could be co-incidental, and now might be the time to dissassemble the PC, clean out the heatsinks, check that all the plugs and sockets are firm (disconnect and reconnect them), likewise with the daughter cards. If you still have freezing problems with different OSs, then that does point to there being some kind of hardware fault that'll need a replacement to fix.
Tim wrote:
On Fri, 2007-08-24 at 13:16 +0200, PerAntonRønning wrote:
What about FC 7? I have what I think must be a hardware problem, since it has occured under SuSe, Mandrake, Madriva and now FC 5: Screen freeze. The PC blocks out keyboard and mouse, and anything that moved on the screen freezes. I have no clue as to why, or what triggers it, and nobody on this list or the Mandriva newbie list had either. So: Hardware trouble.
That does sound ominous. Do you know why the fuse blew? Perhaps you had some mains trouble at that time, and some damage occured to your computer.
Though it could be co-incidental, and now might be the time to dissassemble the PC, clean out the heatsinks, check that all the plugs and sockets are firm (disconnect and reconnect them), likewise with the daughter cards. If you still have freezing problems with different OSs, then that does point to there being some kind of hardware fault that'll need a replacement to fix.
The fuse: Sorry , I was not clear on that. It was not in the PC, it was in the house. When turning on a lamp, the lightbulb went out with a "bang" and caused a short circuiting. This does not happen often, but this time it did happen, and there was this domino effect.
I am not very good at tinkering with the machine (you would not like to to leave the servicing of your car to me either). I have done minor things, but nothing major. Also, I have no equipment, no instruments by which I could measure or test things. I suspected my NVIDIA-card, since there was a screen freeze, but I am not sure of that. I think this problem requires a more intimate knowledge of hardware than I have. Brgds PAR
Tim wrote:
Though it could be co-incidental, and now might be the time to dissassemble the PC, clean out the heatsinks, check that all the plugs and sockets are firm (disconnect and reconnect them), likewise with the daughter cards. If you still have freezing problems with different OSs, then that does point to there being some kind of hardware fault that'll need a replacement to fix.
I have tried to lay a trap. On my backup machine's ssh link to the main computer I started "top", showing which programs are using most resources. After some time the machine froze (it was left idle, only connected to the internet via Firefox), and the program at the top when it froze was "updateb". I did Gooogle for updateb and I found that this is a cron job, that maybe has caused trouble for others as well (I found a discussion on the Linux Thinkpad Mailing List). Does anyone here have any experience with this? The posting suggested to disable the updatep program, but I am not sure whether there will be other side-effects of this. Anyone know?
I also got a tip from a friend of mine, who runs MAC. He also had a similar kind of instability, and after running a memory analysis program he discovered faulty memory. Anyone else having similar experiences?
Brgds PAR
On Sun, 2007-08-26 at 12:03 +0200, PerAntonRønning wrote:
I have tried to lay a trap. On my backup machine's ssh link to the main computer I started "top", showing which programs are using most resources. After some time the machine froze (it was left idle, only connected to the internet via Firefox), and the program at the top when it froze was "updateb".
That's not conclusive, though. Firefox is as good a candidate as any for being the downfall of your PC, probably even more so.
I did Gooogle for updateb and I found that this is a cron job, that maybe has caused trouble for others as well (I found a discussion on the Linux Thinkpad Mailing List). Does anyone here have any experience with this? The posting suggested to disable the updatep program, but I am not sure whether there will be other side-effects of this. Anyone know?
Updatedb makes the database used by the locate command (see the the mlocate.cron file in /etc/cron.daily). You can disable it, and lose that functionality. Mine uses minimal resources, though I recall it being a bit of a drag on a seriously underpowered PC that I used to have. It does trawl through almost the entire drive, so if you have any issues with your hard drive, it could be getting stuck thanks to that.
There's also a chance that there's a misconfiguration, and it's trying to access things it should leave alone. I recall reading something about there being a problem there, and you can prune off some paths and/or file systems in the /etc/updatedb.conf file. I'm fairly sure that it should be ignoring /proc/ and /sys/ but mine's not explicitly configured to do so.
I also got a tip from a friend of mine, who runs MAC. He also had a similar kind of instability, and after running a memory analysis program he discovered faulty memory. Anyone else having similar experiences?
I can't say that I have, but you can run memtest86+ to test your menu. It's available on the install discs, just boot it, and run it for quite some time. You want to go through at least a couple of iterations of the tests. If you get an error message, you've got a problem. It could be the RAM, or what's using it (all the bits between it and the CPU, including the CPU). Ignore such errors at your peril. Memory usage is something that you need zero errors with.
Tim wrote:
On Sun, 2007-08-26 at 12:03 +0200, PerAntonRønning wrote:
I have tried to lay a trap. On my backup machine's ssh link to the main computer I started "top", showing which programs are using most resources. After some time the machine froze (it was left idle, only connected to the internet via Firefox), and the program at the top when it froze was "updateb".
That's not conclusive, though. Firefox is as good a candidate as any for being the downfall of your PC, probably even more so.
I did Gooogle for updateb and I found that this is a cron job, that maybe has caused trouble for others as well (I found a discussion on the Linux Thinkpad Mailing List). Does anyone here have any experience with this? The posting suggested to disable the updatep program, but I am not sure whether there will be other side-effects of this. Anyone know?
Updatedb makes the database used by the locate command (see the the mlocate.cron file in /etc/cron.daily). You can disable it, and lose that functionality. Mine uses minimal resources, though I recall it being a bit of a drag on a seriously underpowered PC that I used to have. It does trawl through almost the entire drive, so if you have any issues with your hard drive, it could be getting stuck thanks to that.
There's also a chance that there's a misconfiguration, and it's trying to access things it should leave alone. I recall reading something about there being a problem there, and you can prune off some paths and/or file systems in the /etc/updatedb.conf file. I'm fairly sure that it should be ignoring /proc/ and /sys/ but mine's not explicitly configured to do so.
I also got a tip from a friend of mine, who runs MAC. He also had a similar kind of instability, and after running a memory analysis program he discovered faulty memory. Anyone else having similar experiences?
I can't say that I have, but you can run memtest86+ to test your menu. It's available on the install discs, just boot it, and run it for quite some time. You want to go through at least a couple of iterations of the tests. If you get an error message, you've got a problem. It could be the RAM, or what's using it (all the bits between it and the CPU, including the CPU). Ignore such errors at your peril. Memory usage is something that you need zero errors with.
The reason why I left Firefox connected was that I suspected that it might be a candidate. But it did not show up high on the list. Funny thing is that there has been no freeze now for quite some time now, so the memory trail may be a better one to follow. As to memtest86: I installed FC5 from 5 CD's ( i did no have a DVD burner at the time, but I have one now, since CD seems to be history), I have been looking around a bit, but I have not found out where memtest is located. If I boot up from disk 1/5 I expect to be lead through the installation process instead, and that is not what I want. I cannot remember having seen anything pertaining memtesting when booting up from 1/5. But I know that I have to boot from this program since the OS cannot run, but I would very much like some hint as to where it is located, and how to tell BIOS that this is the boot program. (BIOS is set to boot from CD before HD). Sorry if this is naive question, but this is absolutely not everyday stuff for me. Apart from that, I learn a lot posting questions to this list, so thanks for all good help.
Brgds PAR
On Sunday 26 August 2007 15:03:14 PerAntonRønning wrote:
Tim wrote:
On Sun, 2007-08-26 at 12:03 +0200, PerAntonRønning wrote:
[snip]
you can run memtest86+ to test your menu.
[snip]
I cannot remember having seen anything pertaining memtesting when booting up
yum install memtest86+
Garry T. Williams wrote:
On Sunday 26 August 2007 15:03:14 PerAntonRønning wrote:
Tim wrote:
On Sun, 2007-08-26 at 12:03 +0200, PerAntonRønning wrote:
[snip]
you can run memtest86+ to test your menu.
[snip]
I cannot remember having seen anything pertaining memtesting when booting up
yum install memtest86+
Done, it went smootly. Am I now supposed to burn a DVD for this program, and boot from that DVD? That's the way I have understood this mechanism, my friend told me that memtest writes to the memory locations and read from them again and makes a comparison. I suppose there would be a system halt if I just started the installed memtest from disk under Linux.
Brgds PAR
On Sunday 26 August 2007 16:26:52 PerAntonRønning wrote:
Garry T. Williams wrote:
yum install memtest86+
Done, it went smootly. Am I now supposed to burn a DVD for this program, and boot from that DVD?
Now run memtest-setup. That will add the memory test to your grub menu. Mine looks like this after running memtest-setup:
title Memtest86+ (1.70) root (hd0,0) kernel /memtest86+-1.70 ro root=LABEL=/ rhgb quiet
Garry T. Williams wrote:
On Sunday 26 August 2007 16:26:52 PerAntonRønning wrote:
Garry T. Williams wrote:
yum install memtest86+
Done, it went smootly. Am I now supposed to burn a DVD for this program, and boot from that DVD?
Now run memtest-setup. That will add the memory test to your grub menu. Mine looks like this after running memtest-setup:
title Memtest86+ (1.70) root (hd0,0) kernel /memtest86+-1.70 ro root=LABEL=/ rhgb quiet
[root@localhost par]# memtest-setup bash: memtest-setup: command not found
whereis memtest does not reveal the whereabouts of memtest either. Is it installed under another name? The install does not give info about that. Brgds PAR
PerAntonRønning [pa-ronn@online.no] wrote:
Garry T. Williams wrote:
On Sunday 26 August 2007 16:26:52 PerAntonRønning wrote:
Garry T. Williams wrote:
yum install memtest86+
Done, it went smootly. Am I now supposed to burn a DVD for this program, and boot from that DVD?
Now run memtest-setup. That will add the memory test to your grub menu. Mine looks like this after running memtest-setup:
title Memtest86+ (1.70) root (hd0,0) kernel /memtest86+-1.70 ro root=LABEL=/ rhgb quiet
[root@localhost par]# memtest-setup bash: memtest-setup: command not found
whereis memtest does not reveal the whereabouts of memtest either. Is it installed under another name? The install does not give info about that. Brgds PAR
You need to run that as root.
QuackHacker@hotpop.com wrote:
PerAntonRønning [pa-ronn@online.no] wrote:
Garry T. Williams wrote:
Now run memtest-setup. That will add the memory test to your grub menu. Mine looks like this after running memtest-setup:
title Memtest86+ (1.70) root (hd0,0) kernel /memtest86+-1.70 ro root=LABEL=/ rhgb quiet
[root@localhost par]# memtest-setup bash: memtest-setup: command not found
whereis memtest does not reveal the whereabouts of memtest either. Is it installed under another name? The install does not give info about that. Brgds PAR
You need to run that as root.
From the # prompt, it looks like he is running as root.
[root@mikkel etc]# type memtest-setup memtest-setup is /usr/sbin/memtest-setup
So it gets installed, at least on a FC6 system...
Mikkel
Mikkel L. Ellertson wrote:
QuackHacker@hotpop.com wrote:
PerAntonRønning [pa-ronn@online.no] wrote:
Garry T. Williams wrote:
Now run memtest-setup. That will add the memory test to your grub menu. Mine looks like this after running memtest-setup:
title Memtest86+ (1.70) root (hd0,0) kernel /memtest86+-1.70 ro root=LABEL=/ rhgb quiet
[root@localhost par]# memtest-setup bash: memtest-setup: command not found
whereis memtest does not reveal the whereabouts of memtest either. Is it installed under another name? The install does not give info about that. Brgds PAR
You need to run that as root.
From the # prompt, it looks like he is running as root.
[root@mikkel etc]# type memtest-setup memtest-setup is /usr/sbin/memtest-setup
So it gets installed, at least on a FC6 system...
Yes, it came through. I run 5 full passes and got error count =0, but is 5 passes ususally enough?
Brgds PAR
"There is a devil astray in the computer, constantly firing a loose cannon on deck. Hear ye! hear ye! The d[a]emons must be driven out! :-)
PerAntonRønning: [about memtest results]
Yes, it came through. I run 5 full passes and got error count =0, but is 5 passes ususally enough?
Probably is a good enough indicator.
Tim wrote:
PerAntonRønning: [about memtest results]
Yes, it came through. I run 5 full passes and got error count =0, but is 5 passes ususally enough?
Probably is a good enough indicator.
Yes. Yesterday I went out and let another memory test run, and when I came home it had completed 13 passes, still with error count = 0. I suppose that the error count is not re-initialized to 0 every time a new pass starts, since every new pass occupies the same statistics line on the screen, at least in my version of memtest. Q:Does memtest produce a log file? At least I don't find one in /var/log, but then again, I gurss a logfile would not be possible since the file system is not mounted.
In conclusion, I guess my memory chips are OK. Could there be a bus problem, or something up that alley? Is there some way of testing she screen card in a similar manner? I still hesitate to believe that all the Linux distros that I have tried produce the same screen freeze condition.
I am seriously planning for FC7, I have located the FC7 version of "The Bible" (Christopher Negus - published on Wiley: "Fedora X and Red Hat Enterprise Linux X-1, X=5,6,7,---) , this has been a quote good and comprehensive FC5 manual. Does anyone have a better suggestion, by the way?
Brgds PAR
On Tue, 2007-08-28 at 09:27 +0200, PerAntonRønning wrote:
Yesterday I went out and let another memory test run, and when I came home it had completed 13 passes, still with error count = 0. I suppose that the error count is not re-initialized to 0 every time a new pass starts, since every new pass occupies the same statistics line on the screen, at least in my version of memtest.
If it finds errors, you'd get a log of them running down the screen. A line for each pass of each test that found an error.
In conclusion, I guess my memory chips are OK. Could there be a bus problem, or something up that alley? Is there some way of testing she screen card in a similar manner?
You can try running the simple VESA driver instead of the one for your particular graphics set. You'll have none of the features, and only low resolution, but if you just want to leave the PC running for a while to see what happens, that hardly matters.
I still hesitate to believe that all the Linux distros that I have tried produce the same screen freeze condition.
Wonky power supplies are another thing to point the finger at.
Tim wrote:
On Tue, 2007-08-28 at 09:27 +0200, PerAntonRønning wrote:
Yesterday I went out and let another memory test run, and when I came home it had completed 13 passes, still with error count = 0. I suppose that the error count is not re-initialized to 0 every time a new pass starts, since every new pass occupies the same statistics line on the screen, at least in my version of memtest.
If it finds errors, you'd get a log of them running down the screen. A line for each pass of each test that found an error.
In conclusion, I guess my memory chips are OK. Could there be a bus problem, or something up that alley? Is there some way of testing she screen card in a similar manner?
You can try running the simple VESA driver instead of the one for your particular graphics set. You'll have none of the features, and only low resolution, but if you just want to leave the PC running for a while to see what happens, that hardly matters.
I still hesitate to believe that all the Linux distros that I have tried produce the same screen freeze condition.
Wonky power supplies are another thing to point the finger at.
Oh yes, thank you. I never thought of that. I think my hard drives are OK, so I have been entertaining the idea of replacing the motherboard/screen card, quite simply. And now perhaps the power supply.
Brgds PAR
On Sunday 26 August 2007 17:44:55 PerAntonRønning wrote:
[root@localhost par]# memtest-setup bash: memtest-setup: command not found
whereis memtest does not reveal the whereabouts of memtest either. Is it installed under another name? The install does not give info about that.
Don't know what's going on there. But here:
$ rpm -ql memtest86+ /boot/memtest86+-1.70 /sbin/new-memtest-pkg /usr/sbin/memtest-setup /usr/share/doc/memtest86+-1.70 /usr/share/doc/memtest86+-1.70/README $ which memtest-setup /usr/sbin/memtest-setup $
(I place /usr/sbin in my path as a normal user.)
Garry T. Williams wrote:
On Sunday 26 August 2007 16:26:52 PerAntonRønning wrote:
Garry T. Williams wrote:
yum install memtest86+
Done, it went smootly. Am I now supposed to burn a DVD for this program, and boot from that DVD?
Now run memtest-setup. That will add the memory test to your grub menu. Mine looks like this after running memtest-setup:
title Memtest86+ (1.70) root (hd0,0) kernel /memtest86+-1.70 ro root=LABEL=/ rhgb quiet
Mine became a bit different, but this is FC 5. Problem was that /usr/sbin/ was not in the $PATH, and there must also have been some slipup on my part when running yum install. It looks like this:
title Memtest86+ (1.65) root (hd0,0) kernel /memtest86+-1.65 ro root=/dev/VolGroup00/LogVol00 rhgb quiet I will now try this by booting up.
Thanks, all. Brgds PAR
On Mon, 2007-08-27 at 10:20 +0200, PerAntonRønning wrote:
Garry T. Williams wrote:
On Sunday 26 August 2007 16:26:52 PerAntonRønning wrote:
Garry T. Williams wrote:
yum install memtest86+
Done, it went smootly. Am I now supposed to burn a DVD for this program, and boot from that DVD?
Now run memtest-setup. That will add the memory test to your grub menu. Mine looks like this after running memtest-setup:
title Memtest86+ (1.70) root (hd0,0) kernel /memtest86+-1.70 ro root=LABEL=/ rhgb quiet
Mine became a bit different, but this is FC 5. Problem was that /usr/sbin/ was not in the $PATH, and there must also have been some slipup on my part when running yum install. It looks like this:
title Memtest86+ (1.65) root (hd0,0) kernel /memtest86+-1.65 ro root=/dev/VolGroup00/LogVol00 rhgb quiet I will now try this by booting up.
Thanks, all. Brgds PAR
The question tht want answered is, after I run memtest do I still have an operating system left on the disk? If I don't how does putting a entry in grub.conf help me? -- ======================================================================= In this world some people are going to like me and some are not. So, I may as well be me. Then I know if someone likes me, they like me. ======================================================================= Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net
Aaron Konstam wrote:
The question tht want answered is, after I run memtest do I still have an operating system left on the disk? If I don't how does putting a entry in grub.conf help me?
The contents of the hard drive are not affected by running memtest. It test RAM, not the hard drive. Putting an entry in the grub menu just gives you an easy way to launch memtest. Remember, memtest has to be run by itself - think of it as a limited operating system that only does one thing - test the memory system of your system. It can show errors in good RAM if you have other problems that cause memory errors. For example, it may show errors if you have the BIOS set wrong for your memory, even though the memory itself is fine.
Mikkel
Aaron Konstam wrote:
On Mon, 2007-08-27 at 10:20 +0200, PerAntonRønning wrote:
Garry T. Williams wrote:
On Sunday 26 August 2007 16:26:52 PerAntonRønning wrote:
Garry T. Williams wrote:
yum install memtest86+
Done, it went smootly. Am I now supposed to burn a DVD for this program, and boot from that DVD?
Now run memtest-setup. That will add the memory test to your grub menu. Mine looks like this after running memtest-setup:
title Memtest86+ (1.70) root (hd0,0) kernel /memtest86+-1.70 ro root=LABEL=/ rhgb quiet
Mine became a bit different, but this is FC 5. Problem was that /usr/sbin/ was not in the $PATH, and there must also have been some slipup on my part when running yum install. It looks like this:
title Memtest86+ (1.65) root (hd0,0) kernel /memtest86+-1.65 ro root=/dev/VolGroup00/LogVol00 rhgb quiet I will now try this by booting up.
Thanks, all. Brgds PAR
The question tht want answered is, after I run memtest do I still have an operating system left on the disk? If I don't how does putting a entry in grub.conf help me?
It worked like this: When booting (I use KDE) I have a few seconds to access the boot menu before Linux is started. After having installed memtest86+, this program appears as an entry in the boot menu. Instead of selecting Linux, one will instead select mentest , and then the program starts immediately, without loading the OS.
Then you let it run some passes to see what happens, and by pressing Esc you go back to booting, and this time you start Linux.
Brgds PAR
Garry T. Williams:
yum install memtest86+
PerAntonRønning:
Done, it went smootly. Am I now supposed to burn a DVD for this program, and boot from that DVD?
If it hasn't already installed an entry in the boot menu, then as root, type in memtest86 (hit tab to complete, in case there's a + on the end), and hit enter. Then reboot, and pick it from the boot menu.
You can check what's in the boot menu, without having to reboot, by reading the /etc/grub.conf file while you're the root user.
On Sun, 2007-08-26 at 21:03 +0200, PerAntonRønning wrote:
As to memtest86: I installed FC5 from 5 CD's ( i did no have a DVD burner at the time, but I have one now, since CD seems to be history), I have been looking around a bit, but I have not found out where memtest is located.
On the first screen there's prompts about what you can do, including pressing some F keys to see more information. On one of those screens, it tells you to type in memtest86 (or memtest86+, I can't remember), and away it goes.
You can run this from any install disc, it doesn't have to be the same Linux release. It's a standalone program that's run from the CD. You can, also, install it to a hard drive through yum, which adds it to your bootmenu. But it's not worth the bother of doing that for a once off test.
On Sunday 26 August 2007 06:03:22 PerAntonRønning wrote:
Tim wrote:
[snip]
and the program at the top when it froze was "updateb".
[snip]
The posting suggested to disable the updatep program, but I am not sure whether there will be other side-effects of this. Anyone know?
The updatedb program updates the database used by the locate(1) command. Disabling its running in cron will only result in incomplete results when you run the locate command. Nothing more.
I also got a tip from a friend of mine, who runs MAC. He also had a similar kind of instability, and after running a memory analysis program he discovered faulty memory.
That is a far more likely cause.
On Fri, 2007-08-24 at 11:14 +0930, Tim wrote:
On Thu, 2007-08-23 at 15:33 +0200, PerAntonRønning wrote:
I did disable selinux, rebooted the machine, but nothing changed. So, this may be due to some CUPS problem. This is something I have never done before - should I remove and then download and reinstall the whole thing? Next thing may be to reinstall FC5 from the bottom and up. THAT I've done before :-)
But, without knowing what the cause was, you might encounter it again. How many times do you want to re-install the whole OS?
Removing CUPS will be a bit difficult, it's deemed to be a core component. You could try manually removing the current configuration files, and then doing a rpm freshen to re-install CUPS over the top.
But noticing that you're running FC5, you'd be hard pressed to get a result from making a bugzilla entry, unless someone can recognise the condition as being a user error (i.e. something that you can change, rather than requiring a change to CUPS). FC5 is no longer supported.
I thought his problem was om f7 not fc5 which works for him.
======================================================================= Lack of capability is usually disguised by lack of interest. ======================================================================= Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net
On Fri, 2007-08-24 at 09:56 -0500, Aaron Konstam wrote:
I thought his problem was om f7 not fc5 which works for him.
I read him talking about re-installing FC5, and being hesitent to use FC7. See: Message-ID: 46CD4CB1.6070701@online.no
Somebody in the thread at some point said:
Hi Andy a minor extract of the error_log shows this: I [22/Aug/2007:12:42:00 +0200] Full reload is required. I [22/Aug/2007:12:42:00 +0200] Loaded MIME database from '/etc/cups': 33 types, 38 filters... I [22/Aug/2007:12:42:01 +0200] Loading job cache file "/var/cache/cups/job.cache"... I [22/Aug/2007:12:42:01 +0200] Full reload complete. I [22/Aug/2007:12:42:01 +0200] Listening to 127.0.0.1:631 on fd 0... E [22/Aug/2007:12:42:01 +0200] Unable to set ACLs on root certificate "/var/run/cups/certs/0" - Operation not supported
It seems to listen to 127.0.0.1:631, which should be lo. The last message tough "operation not supported" does not explain itself, at least not to me. ps -Af | grep cupsd shows that the daemon is up and running. So I'm scratching my head a bit on this.
You mention in your original post
"/usr/bin/lpr connection refused"
I assume you mean by this that if you run lpr by hand you get "connection refuced"... what happens if you run lpq? Can you check that the symlinks go through alternatives like this?
# ll /usr/bin/lpq lrwxrwxrwx 1 root root 27 2007-03-06 08:54 /usr/bin/lpq -> /etc/alternatives/print-lpq # ll /etc/alternatives/print-lpq lrwxrwxrwx 1 root root 17 2007-08-21 11:46 /etc/alternatives/print-lpq -> /usr/bin/lpq.cups # ll /usr/bin/lpq.cups -rwxr-xr-x 1 root root 13820 2007-08-09 16:53 /usr/bin/lpq.cups
-Andy
Karl, thank you. The problem is that I did remove the printer, then I added it again, but it still could not get in contact with CUPS. No printing takes effect, not only the testpage. I also have trouble starting system-config-printer, and any efforts to do printer management is rejected. So I wonder if there is something wrong with my CUPS, but I have never done any installation or configuration of CUPS before, so there I am a novice.
Brgds PAR
Karl Larsen wrote:
PerAntonRønning wrote:
After a long period of smooth sailing I suddenly encountered a CUPS problem. Why I have got it is uncertain, maybe as a result of a yum upgrade run. I had to reinstall FC 5 due to some disk trouble (possibly because a blown fuse cut the electricity supply to my desk) so I imagined that I would be interested in upgraded programs since I burned the FC5 distro.
I remove and reinstall the printer (which btw. is online, lights are up :-) ) and when sending a testpage to the printer i get the following message:
"There was a problem sending CUPS test page to laser1 queue (my chosen printer name)
/usr/bin/lpr connection refused
The following daemons are running: cupsd cups-config-daemon
I would be grateful to receive some help on this one.
Brgds PAR
I had a problem like that. I had to delete the printer from the printer setup program and then re-load it with the same name and so forth. It fixed the problem.
Do you get an error when you run /sbin/service cups restart? Check /var/log/messages. On one of my computers, I am getting an error about can't read cupsd.conf and the printer daemon is not starting (see my other posting). I can start cupsd manually, however. -- Wade Hampton
On 8/22/07, PerAntonRønning pa-ronn@online.no wrote:
Karl, thank you. The problem is that I did remove the printer, then I added it again, but it still could not get in contact with CUPS. No printing takes effect, not only the testpage. I also have trouble starting system-config-printer, and any efforts to do printer management is rejected. So I wonder if there is something wrong with my CUPS, but I have never done any installation or configuration of CUPS before, so there I am a novice.
Brgds PAR
Karl Larsen wrote:
PerAntonRønning wrote:
After a long period of smooth sailing I suddenly encountered a CUPS problem. Why I have got it is uncertain, maybe as a result of a yum upgrade run. I had to reinstall FC 5 due to some disk trouble (possibly because a blown fuse cut the electricity supply to my desk) so I imagined that I would be interested in upgraded programs since I burned the FC5 distro.
I remove and reinstall the printer (which btw. is online, lights are up :-) ) and when sending a testpage to the printer i get the following message:
"There was a problem sending CUPS test page to laser1 queue (my chosen printer name)
/usr/bin/lpr connection refused
The following daemons are running: cupsd cups-config-daemon
I would be grateful to receive some help on this one.
Brgds PAR
I had a problem like that. I had to delete the printer from the printer setup program and then re-load it with the same name and so forth. It fixed the problem.
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Hi Wade, this is what happes:
[root@localhost par]# /sbin/service cups restart Stopping cups: [ OK ] Starting cups: [ OK ]
No clue - it seems.
Brgds PAR
Wade Hampton wrote:
Do you get an error when you run /sbin/service cups restart? Check /var/log/messages. On one of my computers, I am getting an error about can't read cupsd.conf and the printer daemon is not starting (see my other posting). I can start cupsd manually, however. -- Wade Hampton
On 8/22/07, PerAntonRønning pa-ronn@online.no wrote:
Karl, thank you. The problem is that I did remove the printer, then I added it again, but it still could not get in contact with CUPS. No printing takes effect, not only the testpage. I also have trouble starting system-config-printer, and any efforts to do printer management is rejected. So I wonder if there is something wrong with my CUPS, but I have never done any installation or configuration of CUPS before, so there I am a novice.
Brgds PAR
Karl Larsen wrote:
PerAntonRønning wrote:
After a long period of smooth sailing I suddenly encountered a CUPS problem. Why I have got it is uncertain, maybe as a result of a yum upgrade run. I had to reinstall FC 5 due to some disk trouble (possibly because a blown fuse cut the electricity supply to my desk) so I imagined that I would be interested in upgraded programs since I burned the FC5 distro.
I remove and reinstall the printer (which btw. is online, lights are up :-) ) and when sending a testpage to the printer i get the following message:
"There was a problem sending CUPS test page to laser1 queue (my chosen printer name)
/usr/bin/lpr connection refused
The following daemons are running: cupsd cups-config-daemon
I would be grateful to receive some help on this one.
Brgds PAR
I had a problem like that. I had to delete the printer from the printer setup program and then re-load it with the same name and so forth. It fixed the problem.
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
PerAntonRønning wrote:
Karl, thank you. The problem is that I did remove the printer, then I added it again, but it still could not get in contact with CUPS. No printing takes effect, not only the testpage. I also have trouble starting system-config-printer, and any efforts to do printer management is rejected. So I wonder if there is something wrong with my CUPS, but I have never done any installation or configuration of CUPS before, so there I am a novice.
Brgds PAR
Karl Larsen wrote:
PerAntonRønning wrote:
After a long period of smooth sailing I suddenly encountered a CUPS problem. Why I have got it is uncertain, maybe as a result of a yum upgrade run. I had to reinstall FC 5 due to some disk trouble (possibly because a blown fuse cut the electricity supply to my desk) so I imagined that I would be interested in upgraded programs since I burned the FC5 distro.
I remove and reinstall the printer (which btw. is online, lights are up :-) ) and when sending a testpage to the printer i get the following message:
"There was a problem sending CUPS test page to laser1 queue (my chosen printer name)
/usr/bin/lpr connection refused
The following daemons are running: cupsd cups-config-daemon
I would be grateful to receive some help on this one.
Brgds PAR
I had a problem like that. I had to delete the printer from the printer setup program and then re-load it with the same name and so forth. It fixed the problem.
Sorry but in my experience re-loading the printer has always fixed the problem. Your problem is more serious and may take some serious changes in cups or supporting software.
On Wed, 2007-08-22 at 12:37 +0200, PerAntonRønning wrote:
After a long period of smooth sailing I suddenly encountered a CUPS problem. Why I have got it is uncertain, maybe as a result of a yum upgrade run. I had to reinstall FC 5 due to some disk trouble (possibly because a blown fuse cut the electricity supply to my desk) so I imagined that I would be interested in upgraded programs since I burned the FC5 distro.
I remove and reinstall the printer (which btw. is online, lights are up :-) ) and when sending a testpage to the printer i get the following message:
"There was a problem sending CUPS test page to laser1 queue (my chosen printer name)
/usr/bin/lpr connection refused
The following daemons are running: cupsd cups-config-daemon
I would be grateful to receive some help on this one.
The advice to check the messages in /var/log/cups error_log and access_log is the way to go.
But I would also stop cups-config-daemon from running. It causes problems. -- ======================================================================= McEwan's Rule of Relative Importance: When traveling with a herd of elephants, don't be the first to lie down and rest. ======================================================================= Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net