lp : drivers loaded but no devices found - [re-opened]

[Patriot]

Hmmm .....

Hi,

I have followed the step by step, but i get the same error message concerning the permission.

I can see that i still have an old cups directory named cups-old. Can it interact with the active one?
........

No, it doesn't use (or even look into) cups-old folder. It's only a backup reference. You can delete it if you don't need it anymore.

Based on your description above so far, the last thing that came to mind is filesystem corruption. Yes, a borked filesystem can prevent CUPS from printing .....

I've seen this happened mostly on full hdd installs (I had this problem twice myself many months ago. I don't use hdd installs anymore), seldom occurs on frugal installs but it can still happen. Since you mentioned that you can print from puppy430, then I suggest doing a fresh boot from puppy with pfix=ram and fsck your partition or savefile. If it's a minor thing then it should be fixable. If the corruption is beyond repair then you will need to rebuild your partition or savefile.


Rgds

[xav795]

Hi,

You are right, my pupsave is corrupted.
I dont know how i did it, but, even fsck can't read my pupsave.
In fact i have a problem with many files of my usb flash.
I was regularly using a dd command to backup my flash disk (in fat32) to a backupfile.dd on another partition in ext3 format, because i wanted to be able to copy more that 4Go.
Is there something wrong doing this way?
when i wanted to restore my backup i was doing a
dd if=/mnt/sdx/mybackup.dd of=/dev/sdy

But i could see recently that i was not able to mount my dd file.
I was getting this message when doing
mount -t vfat /mnt/sdd1/sauv_puppy2.dd /mnt/testfs -o loop
ount: wrong fs type, bad option, bad superblock on /dev/loop2,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

and dmesg
FAT: invalid media value (0x06)
VFS: Can't find a valid FAT filesystem on dev loop2.


Here is the result of fsck on my pupsave, saved on a ext3 partition.
# fsck /mnt/+mnt+sdd1+pup_save-xav.2fs
fsck 1.41.9 (22-Aug-2009)
e2fsck 1.41.9 (22-Aug-2009)
fsck.ext2: Is a directory while trying to open /mnt/+mnt+sdd1+pup_save-xav.2fs

The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

Is there a way to rebuild my pupsave?

Rgds

[Patriot]

Hmmm .....

Hi,

You are right, my pupsave is corrupted. ........

It looks pretty bad ... but it's not really your fault ... The worst that I had was a full hdd install that got corrupted in less than two weeks ... The shutdown process didn't do it real "gracefully" and tend to do it "quick-n-dirty" ...

I don't think directly fixing and re-using the pupsave is possible now ..... I suggest trying to copy out your important data (if you have any) and create a new save file .... and do fsck at least once a month ... once a week if you frequently boot up puppy ...

On my own systems, I love the simplicity of FAT32 partitions and ext2 pup_saves ... NTFS partitions is only used to store files larger than 4GB ... I've never had any unrecoverable corruption ever since ...

To make pup_save backups, the easiest way to preserve the settings would be to boot pfix=ram or use a different pup_save and copy the pup_save you want to somewhere else ...


Rgds

[xav795]

Hi,

I have restarted with a new puppy 4.12 (i am using a french version i am waiting for the french 4.3).

Thank you a lot, patriot for all the time you spent with my problems, i will save my pupsave more carefully with the options you told me about.

All my data are not losen, i could save most of all.
I will try to have a better strategy for saving my data.
I must improve my level of knowledge in how puppy works to understand what is inside a pupsave.2fs, a puppy412.sfs.
In fact, a technical book on puppy should be a nice present for christmas. I will search the forum and Barry's blog to get it.

Rds

[xav795]

Hi,

After my new start with a fresh french 4.12, i have noticed that after the installation of cups 1.3.11, i get a problem of permission, discussed above.

For the moment, the only thing that works is to first apply the commands you gave to me.

rm -fr /var/spool/cups
/etc/init.d/cups restart

then i can print something without problem until my next reboot.
Each time a boot, i can't start printing someting without executing these two lines.

Rgds

[Patriot]

Hmmm .....

........
rm -fr /var/spool/cups
/etc/init.d/cups restart

then i can print something without problem until my next reboot.
Each time a boot, i can't start printing someting without executing these two lines.

On your next reboot, before doing the two lines above, please do this in a terminal :

ls -la /var/spool
ls -la /var/spool/cups

and do it again after executing the rm -fr & cups restart ... We'll be able to compare the difference, if any .....


Rgds

[xav795]

Hi,

There is something strange : Each time i reboot, i am getting files in /var/spool/cups, that i must delete, else, my future print job won't be done, because of the permission denied message.
(One thing i do at each reboot is to force filechecking with the option in syslinux.cfg : pfix=fsck,copy.)
Here are the steps :

0. I am starting with a fresh /var/spool/cups that is empty.

1. First i reboot
Executing the ls, i get :
# ls -la /var/spool
total 8
drwxr-xr-x 5 root root 4096 2009-11-09 14:05 .
drwxr-xr-x 24 root root 100 2009-11-02 20:17 ..
drwxr-xr-x 3 root root 25 2005-12-05 23:56 cron
drwx--x--- 4 root nobody 4096 2009-11-09 23:32 cups

# ls -la /var/spool/cups
total 228
drwx--x--- 4 root nobody 4096 2009-11-09 23:32 .
drwxr-xr-x 5 root root 4096 2009-11-09 14:05 ..
-rw------- 1 root nobody 729 2009-11-02 16:30 c00005
-rw------- 1 root nobody 910 2009-11-03 15:25 c00006
-rw------- 1 root nobody 746 2009-11-06 10:35 c00007
-rw------- 1 root nobody 746 2009-11-06 10:43 c00008
-rw------- 1 root nobody 872 2009-11-09 09:54 c00011
-rw------- 1 root nobody 746 2009-11-09 14:05 c00013
-rw------- 1 root nobody 746 2009-11-09 14:13 c00014
-rw-r----- 1 root nobody 185304 2009-11-03 15:25 d00006-001
drwxrwx--T 2 root nobody 4096 2009-11-09 14:13 tmp

2. I delete all and restart cups with
rm -fr /var/spool/cups
/etc/init.d/cups restart

3. Executing the ls again, i get :
# # ls -la /var/spool
total 0
drwxr-xr-x 6 root root 60 2009-11-10 09:36 .
drwxr-xr-x 26 root root 140 2009-11-02 20:17 ..
drwxr-xr-x 3 root root 25 2005-12-05 23:56 cron
drwx--x--- 3 root nobody 80 2009-11-10 09:36 cups
# ls -la /var/spool/cups
total 0
drwx--x--- 3 root nobody 80 2009-11-10 09:36 .
drwxr-xr-x 6 root root 60 2009-11-10 09:36 ..
drwxrwx--T 2 root nobody 40 2009-11-10 09:36 tmp

Rgds,

[samwathegreat]

I'm having an identical problem to xav795's.

I'm using the cups 1.3.11 pet, and everything works fine until I reboot. Then printing no longer works, and I begin getting permission denied errors. The only solution is to delete the /var/spool/cups directory, and restart cups.

I've tried a complete reinstall and the problem persists. I am not able to find any cause, as the permissions show up exactly the same before I delete the /var/spool/cups directory as it does when I restart cups and it gets re-created. How strange? This isn't a huge issue, as I seldom re-boot, however, if there is no logical explanation to why this is happening, could someone please help me write a script that will automaticly delete the /var/spool/cups directory BEFORE cups gets started by /etc/init.d/cups on each reboot?

I believe this could be my simplest solution, and since I'm not concerned with keeping a log of print history I don't see any potential problems with this.

Is anyone else having this problem?? It just doesn't make sense.

Thank You

[jpeps]

If you're seeing the extra files like xav795, it's most likely some file corruption issue (on my system, they're only in tmp)

edit: or bug?

[samwathegreat]

Thanks for the reply jpeps

It would seem to me that this problem is un-related to corrupted file system, since both xav795 and myself have completely started from scracth (and a new puppy). I have completely re-formatted my drive and started over, even though I had no reason to believe that my filesystem was corrupted. First thing I did afterwards was install cups 1.3.11 pet and proceed with trying to get cups to work.

Nonetheless, the problem has persisted for both both of us, continuing to get the dreaded "Unable to open file "/var/spool/cups/xxx" - Permission denied" error, and no print output.

Since removing the /var/spool/cups directory & subsequently restarting cups makes everything work fine until reboot (and since there doesn't seem to be a solution available), I've come up with the following work-around:

#####EDIT! 2-8-10 DO NOT USE THIS SCRIPT! See my post below#####

Create a new file in /etc/init.d lets call it "fixcups"
Copy this code into the new file:
#!/bin/sh
# Fixcups
# Script to remove cups spool directory on shutdown
if [ "$1" = "start" ]
then
echo -n "doing nothing"
exit
fi

if [ "$1" = "stop" ]
then
echo -n "removing cups spool directory"
rm -fr /var/spool/cups
exit
fi

echo "Useage: `basename "$0"` [start|stop]"



Since puppy runs everything in init.d with "start" when the computer boots, you will see that this script does absolutely nothing at startup.

At shutdown, however, puppy runs everything in init.d with the directive "stop", so the script removes the cups spool directory at shutdown. How convenient! At the next boot, cups will start, and immediately re-build the /var/spool/cups directory, and printing will work without permission denied errors.

Why not create a startup script that removes the /var/cups/spool directory and also restarts cups at boot? Because I'm not sure what order the files in init.d get executed....it wouldn't be good to "restart cups" before cups even starts, right? With my solution, there -shouldn't- be any side-effects, since we're just removing a directory that will get rebuilt at the next boot.

I hope this helps someone else out.

Thanks everyone for the help.

[jpeps]

Kind of weird it's saving jobs anyway, if /etc/cups/cupsd.conf has "PreserveJobHistory Off". After deleting the few jobs in tmp on my system, it didn't add any new ones after printing some test jobs from Geany.

[xav795]

Hi jpeps,

I just tried these options in /etc/cups/cupsd.conf,
PreserveJobHistory Off
PreserveJobFiles Off

I then deleted the files within this folder
rm -fr /var/spool/cups
and restarted cups
/etc/init.d/cups restart

Printing a document then work, but like each time, even without the option in cupsd.conf

So i restarted toutoulinux , (french 4.1.2 pupplet.)

The /var/spool/cups directory is still containing files, it's seems to be the history, and i can't print without doing a clean of these old files.

So i am still using these commands , like samwathegreat, when i want to print for the first time after booting :
rm -fr /var/spool/cups
/etc/init.d/cups restart
It works well but this is not clean because files in this folder are growing.
There is a purge somewhere that does not work.

[jpeps]

Also setting "AutoPurgeJobs Yes" and "MaxJobs 1" and then restarting cups doesn't work either?

[samwathegreat]

Ok so the shutdown script did have some unwanted side effects....caused a problem loading cups at the next boot.

Here is my FINAL solution, this one is tested confirmed working great. Simply edit the /etc/init.d/cups file:

Find the section of the script for start:

case $1 in
start | restart | reload)
if $IS_ON cups; then
if test "$pid" != ""; then
kill -HUP $pid
else
rm -fr /var/spool/cups
prefix=/
exec_prefix=/usr
/usr/sbin/cupsd
if test $? != 0; then
$ECHO_FAIL
$ECHO "cups: unable to $1 scheduler."
exit 1
fi
fi
$ECHO_OK
$ECHO "cups: ${1}ed scheduler."


and add the line

rm -fr /var/spool/cups

right before prefix=/


This solution removes the spool directory RIGHT before cups gets started. I've checked the logs, and there are no side effects, and printing works right away.

Good Luck!

[samwathegreat]

Update:

The modified startup script continues to work flawlessly

For anyone who is interested in finding out why this has to be done, I've found something interesting:

If the modified startup script is not used, at the next boot, we will receive the dreaded "Unable to open file "/var/spool/cups/xxx" - Permission denied" error - the problem xav and I have been experiencing.

What i've noticed is that when it doesn't work, the job will appear in the "jobs" section of cups under the user "anonyomous", or "nobody" or my windows username if I'm tryint to print through samba. Nothing gets printed, and cups shows status as stopped with the permission denied error. Also, -everything- that you try to print shows up in the status and does not go away.

However!, after running:

rm -fr /var/spool/cups
/etc/init.d/cups restart

1) everything in jobs disappears (naturally...we just deleted the spool directory)
2) anything that I print actually DOES print
3) EVERYTHING that I print (whether through lpn, cups test page, or windows samba client) shows up in the cups "jobs" page showing user "root" None of them show "nobody" or "anonoymous"!

So it seems that after a reboot, cups writes anything that gets printed into the spool directory with that user's username (e.g. nobody, anonymous), BUT once you delete the spool directory & restart cups (and cups re-builds the spool directory and "repairs permissions") any printed files get written to the spool directory as user "root"

This seems to be the key - it looks to me like at each reboot, cups writes print jobs to the spool directory as "nobody, etc.", and subsequently, the necessary filters aren't able to read the file because of permissions mismatch. After executing our "fix", everything gets written as root, so the filters are able to process the print jobs without errors.

I've also noticed that this bug doesn't seem to affect post-script printers because there is no filtering to be done.

It also doesn't seem to affect windows samba clients, printing to a non-postscript printer when you use the proper windows driver for your printer, and set it to "print directly to printer" (raw). I'm guessing that once again, this is because the file doesn't need to pass through any filters, cups simply sends the raw data to the printer, and it prints fine.

It only seems to affect non-postscript printers when printing anything from a linux box, including the cups "print test page" (because it has to pass through the appropriate filters).

If anyone is interested, the printer I'm using is a canon MP-240, and I'm using "Patriot"s Canon MP-240 Puppy pet package (from 3.00 source) from http://www.murga-linux.com/puppy/viewtopic.php?t=47444

After viewing the cups error log in debug mode, I see that the printing process gets stopped when cups tries to pass the job through the "pstops" filter - the log shows "Unable to open file "/var/spool/cups/xxx" - Permission denied" THE SAME error that we see on the cups "printer" page.

So it has something to do with how cups writes the print jobs to /var/spool/cups & who "owns" the file. Seems that if it's not root, the filters can't read it.

Nonetheless, the modified startup script fixes the problem so I'm happy (and I can print!!)

[samwathegreat]

Also, I want to point out that with the fix from my above post, I am NOT having xav's problem with the spool directory still containing files. Everything gets removed - I've also noticed that NOW (after using fix), cups automaticly deletes the processed/completed jobs after a few minutes. I can look in /var/spool/cups OR the Cups jobs page (show completed jobs), and they both show empty. Before, everything just piled up in there, so seems to have fixed this problem as well.

[Patriot]

Hmmm .....

This /var/spool/cups folder issue reminds me of one old cups-1.1.23 problem I had a long time ago ... I moved it to tmp to make it work ...

I guess its time to start poking into cups again soon ... Ok, guys, can't make any promises when it'll happen but I'll look into the spool folder issue again later and see what its about ...


Rgds

[xav795]

Also setting "AutoPurgeJobs Yes" and "MaxJobs 1" and then restarting cups doesn't work either?

jpeps,

I then have only one job in the folder, but it does not print anymore, i still have the permission denied error message.

Rgds

[jpeps]

Did you change it to root root? (eg, chown the cups directory)

[jpeps]

Did you change it to root root? (eg, chown /cups/*)