5:37 a.m.
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
6:29 a.m.
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.
--
Karl F. Larsen, AKA K5DI
Linux User
#450462 http://counter.li.org.
6:45 a.m.
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
9:22 a.m.
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
--
Karl F. Larsen, AKA K5DI
Linux User
#450462 http://counter.li.org.
1:12 p.m.
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
1:27 p.m.
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
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting a bad thing?
4:11 p.m.
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(a)sbcglobal.net
5:06 p.m.
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(a)sbcglobal.net
The printer is attached directly to the PC, it is not a network printer.
BRGDS
PAR
5:04 p.m.
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 ?
4 a.m.
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?)
5:48 a.m.
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
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
>>>
>>> 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?)
>> "/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(a)sbcglobal.net
8:33 a.m.
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
4:32 p.m.
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.
--
Aaron Konstam <akonstam(a)sbcglobal.net>
8:44 p.m.
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@bigblack ~]$ uname -ipr
2.6.22.1-41.fc7 i686 i386
Using FC 4, 5, 6 & 7, plus CentOS 5. Today, it's FC7.
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
6:16 a.m.
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
10:44 p.m.
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@bigblack ~]$ uname -ipr
2.6.22.1-41.fc7 i686 i386
Using FC 4, 5, 6 & 7, plus CentOS 5. Today, it's FC7.
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
2:25 a.m.
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
5:03 a.m.
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
5:22 a.m.
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@bigblack ~]$ uname -ipr
2.6.22.1-41.fc7 i686 i386
Using FC 4, 5, 6 & 7, plus CentOS 5. Today, it's FC7.
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
2:03 p.m.
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
2:51 p.m.
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 --- +1 678 656-4579
3:26 p.m.
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
3:51 p.m.
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 --- +1 678 656-4579
4:44 p.m.
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
4:57 p.m.
PerAntonRønning [pa-ronn(a)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.
5:54 p.m.
QuackHacker(a)hotpop.com wrote:
PerAntonRønning [pa-ronn(a)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
--
Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!
5:28 a.m.
Mikkel L. Ellertson wrote:
QuackHacker(a)hotpop.com wrote:
> PerAntonRønning [pa-ronn(a)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! :-)
11:04 p.m.
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@bigblack ~]$ uname -ipr
2.6.22.1-41.fc7 i686 i386
Using FC 4, 5, 6 & 7, plus CentOS 5. Today, it's FC7.
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
2:27 a.m.
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
3:56 a.m.
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@bigblack ~]$ uname -ipr
2.6.22.1-41.fc7 i686 i386
Using FC 4, 5, 6 & 7, plus CentOS 5. Today, it's FC7.
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
5:03 a.m.
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
6:06 p.m.
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 --- +1 678 656-4579
3:20 a.m.
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
8:45 a.m.
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(a)sbcglobal.net
9:45 a.m.
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
--
Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!
10:21 a.m.
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
6:55 p.m.
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.
--
[tim@bigblack ~]$ uname -ipr
2.6.22.1-41.fc7 i686 i386
Using FC 4, 5, 6 & 7, plus CentOS 5. Today, it's FC7.
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
6:51 p.m.
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.
--
[tim@bigblack ~]$ uname -ipr
2.6.22.1-41.fc7 i686 i386
Using FC 4, 5, 6 & 7, plus CentOS 5. Today, it's FC7.
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
5:30 a.m.
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.
--
Garry T. Williams --- +1 678 656-4579
9:56 a.m.
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(a)sbcglobal.net
10:40 p.m.
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(a)online.no>
--
[tim@bigblack ~]$ uname -ipr
2.6.22.1-41.fc7 i686 i386
Using FC 4, 5, 6 & 7, plus CentOS 5. Today, it's FC7.
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
4:24 a.m.
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
6:58 a.m.
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.
8:07 a.m.
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(a)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(a)redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
1:15 p.m.
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(a)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(a)redhat.com
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
>
>
9:27 a.m.
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.
--
Karl F. Larsen, AKA K5DI
Linux User
#450462 http://counter.li.org.
8:46 a.m.
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(a)sbcglobal.net
6122
days inactive
6128
days old
46 comments
9 participants
participants (9)
-
Aaron Konstam -
Andy Green -
Garry Williams -
Karl Larsen -
Mikkel -
Per Anton Rønning -
QuackHacker＠hotpop.com -
Tim -
Wade Hampton